Times A Wastin’!!!!

One thing I love about Agile is the amount of time spent in meetings.  Lots.

On many teams we instituted a “no-afternoon” meeting rule too.  There are stats that will tell you even a single IM interruption will take up to 25 minutes to recover from (you’d better look that up).  These days our Shift Foremen really like to see our green light on and ask us “is it done yet, is it done yet??”  Imagine how much time is wasted.

Well honestly I (OK Gary-O just came on — “here in my car . . . “)  uh uh honestly the one thing I can prove now, this moment, is the waste alot of organizations go through with these meetings due to poorly prepared management.  And right now I work for one of those.

Very plainly, the meetings are always late, and usually run over more tham the time alotted and solve very little.  Weekly, we have at least one big meeting with several DBA’s, a few developers and a few QA.  This manager’s meetings always run late, 15 minutes minimum.    So, eight people times 15 minutes is two hours wasted per week for the big meeting.

Then, there’s the daily and that’s usually late and overruns.  Since this meeting doesn’t start on the hour, most of a half hour is a wash.  Anyway, every day another 15 over/under times eight people = 10 hours a week.

Conservatively, 12 hours a week is wasted by this manager.  In month, that’s 48 hours.    If  this person is  there 50 weeks — the waste is 15 weeks of peoples’ time, almost 4 months.    Doing “Agile.”  And that’s not counting all the extra things that happen due to the daily interruptions.  We aren’t talking about team bonding etc.  We are talking a person who is poorly prepared, runs late, runs over, and is disrespectful of others’ time.

Now, most of the Huge Company, Incs. hire mouth breathers that need to be told exactly what to do.  Also, the only place a lot of incompetents can hide is in the large hiring crowd of Huge Company, Inc.    So time suck is unavoidable just by the stereotypes.

Wow.  So next time you buy that . . . whatever . . . imagine if 30% of the cost was due to a manager living the fast paced life of time suck.

Top Down “Agile” — Another Story

Last year I was working at Huge Company, Inc. and they were trying to implement some agile.  I was brought in as one of those stack lead developers — domain, UI, smile, do a jig etc.  But soon I found myself leading two development/qa teams and kinda of a nightmare on my hands — top-down agile.

You see what would happen was this:  we (doing scrum method) would add our agreed stories to our sprint, start working, and about halfway through a big wig would come in and tell us to drop everything for one of their quickie projects.  This happened several times and we could never get our sprint goals done.  Worse, all the big wigs were going to agile training and still missing the whole point; and none of the task people were getting any training at all.  I wasn’t even allowed to set up our own training time if I wanted.  And we couldn’t get resuources like even regular meetings rooms — at times we’d scrum in stairwells.

What do you do if you are ordered to march agile, but they won’t let you actually do agile? Well this isn’t anything new — it has happened with all the project management styles I’ve been through in all Huge Company, Incs. I’ve been at.  Agile — does not offer a solution for this it is only a software building technique and that is all.

Well, if you are doing waterfall, rup, any ISO style or any other equivalent of agile you know you are up a creek and here’s what I do:

  • Allow the leadership who is putting your team into these situations to be accountable for their decisions.
  • Wait it out.  Unfortunately many times, especially with non-selfevident methods like agile, no matter what you say nothing will change until others get it themselves.  People have a funny propensity for continued thinking in a box and you just have to wait.
  • Don’t struggle and argue,  don’t complain.  Give the paycheck writers what they want.  They may not want timely good software.
  • Since you probably know that they really do want timely good software, do what you can in prep.
  • Don’t work overtime for crappy underplanned goals.  Failure at the start of agile is imperative for gathering velocity metrics.
  • Learn how to report to the big wigs in the agile tool, set up someone, usually the scrum master, as the cock-block to  management and let the task people get their stuff done.
  • Don’t let your life go.  Don’t work huge overtime.   For some reason modern agile put its roots like XP in the crapper — don’t do it.  Everything you do outside of work contributes also to who you are at work.   It’s important.
  • Track EVERYTHING.  For instance, your starting sprint snapshots.  Make sure all docs are in a version controlled repository even if you have to give the BA’s access to a folder in your code repository to do it.
  • Be innovative.  Most times the control freaks will try to get in your way but just do it; developers are creators.
  • Again — be patient, do what you can, and wait it out.
  • You can always quit too, if its driving you nuts.  I know a QA/build master guy who was ‘totally agile” and it drove him nuts so much that all the developers weren’t doing TDD 100% of the time he had to quit — and he was happier.
  • If you really feel strongly about, say “we need Hudson” then mock it up on a system and make a power point and show them the ROI.  If they don’t bite on it, present it to a weekly group and use it on your resume, Knowledge is always win-win.
  • Patience.
  • Be happy.

The bottom line is, yes, its all about the money and the target of agile tooling and methodology today is not the people who will carry it out but instead the people who are going to pay for the enterprise licensing.   Its just reality.

Here’s my recent example.  We just changed radically changed domains on a 10 year old code base;  its an DMU design (down middle up) — and the objects in the app do not in any way reflect the new database.  We were forced to bastardize the objects to deliver functionality based on what the sales people and management promised.

I ran the numbers — all the indexes, metrix, class relationship charts, analyzed stories and bugs  etc.  showing how brittle our domain code was and the dangers were were in (to change one class meant a physical change 100 other classes; giant huge SQL queries etc.).  The architect and management wouldn’t buy it.

So — all’s I could do was wait.  They had to see it to believe it.  And they are.  I didn’t get my panties in a wad, I wasn’t trying to introduce the newest version of “whatever” — just do a badly needed oil change.

The hardest and most important quality for creative developers to learn is patience. There is many times a bigger picture than what’s sitting in your IDE, right or wrong.  Just be patient, and keep your own box open for improvement.

A Neat Coding Trick: Add a Property Instead of a Parameter

If you’ve ever had to work on a legacy application with a HUGE code base, you might get faced with this situation:

Manager: “Hey journeyman can you fix this address on this page so that it knows to take a system configuration?”

Journeyman:  “Sure, give me a second for an estimate.”

You find the code:

public class AddressService {

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           if (yourFormat == 1) { /* do this format */ }
           else { /* do this format */ }
           return addressString;
         }
 }

Now go in and track down the code to change .   Hmm interesting function called getFormattedAddress().  Let’s see, before I touch it do a code search in Eclipse : used in 147 places!!!!!  Ugh . . .

You shan’t dare change the function call in ALL those places, nightmare, just for one of the calls.

So here’s one way to do avoid this messy situation:

  1. Add a new property, yourConfig, with getters and setters.
  2. Override the function getFormattedAddress so that it takes your new parameter
  3. Set that parameter in the overriding function.
  4. Modify the original function to check the parameter, using a default if the value is empty.
  5. Call the original function form the overriding function
  6. Don’t forget to reset the default value!

Something like this:

public class AddressService {
      private String yourConfig = "";

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           String localConfig = 
                   (getYourConfig == "") ? "default" : getYourConfig();
           setYourConfig("");   
           if (yourFormat == 1) { /* do this format +localConfig */ }
           else { /* do this format + localConfig */ }
           return addressString;
         }
     public String getFormattedAddress(Datasource ds, int yourFormat, String inYourConfig) {
           setYourConfig(inYourConfig);
           return getFormattedAddress(ds,yourFormat);
     }

    public String setYourConfig(String inStr) {this.yourConfig = inStr;}
    public void getYourConfig() {return this.yourConfig;}

}
Now you can call the function from either its original state, or, pass in a config.

Defaults: Hibernate Lazy; JPA Eager

Now this is interesting.

We were trying to debug some Hibernate rich objects we had converted from hbm files to annotations, and the objects were blowing up.  One of our more expertish developers with some Hibernate experience insisted that default fetching was lazy.  We decided to accept that as the word and left certain objects with their hbms attributing their failure to annotations not doing something mysterious correctly.

Well, I started to write some unit and integration tests on one of the newer annotated objects and was stubbing the data out with HSQL.  I noticed that there were errors in running the tests of the nature of  failure to hydrate objects.  It smelled like eager fetching. 

So I made the fetching on the many-to-one relationships explicity lazy in an annotation.  I couldn’t believe it.  Searching through the documentation I found this.  Who would have thought that Hibernate and JPA have taken two different approaches!

Fetch strategies and types

In native Hibernate, many-to-one association are lazy by default.
This means that selecting a list of objects with an HQL query will not
initialize the objects at the other end of the many-to-one association.
In JPA the default fetch type is eager (i.e. non-lazy), with separate
selects. This means that any JPAQL query for an entity that has
many-to-one associations in it will result in an N+1 SELECTS problem
even if those associations are not used. To eliminate the unnecessary
queries, simply set the fetch type to LAZY using:

<font color="#000066"><i> @ManyToOne(fetch=FetchType.LAZY)
</i></font>

Then, in any JPA query the association can be eagerly fetched using left join fetch.

A Simple PL/SQL Tokenizer

DECLARE
   tokenString      VARCHAR2 (256) := ‘Jim,Jerry,Jordan’;
   tokenLength      NUMBER := 0;
   tokenDelimiter   VARCHAR2 (1) := ‘,’;
   tokenChar        VARCHAR2 (1) := ”;
   tokenIzed        VARCHAR (30) := ”;
BEGIN
   SELECT LENGTH (tokenString) INTO tokenLength FROM DUAL;

   FOR i IN 1 .. tokenLength
   LOOP
      SELECT SUBSTR (tokenString, i, 1) INTO tokenChar FROM DUAL;

      IF tokenChar = tokenDelimiter OR i = tokenLength
      THEN
         IF i = tokenLength
         THEN
            tokenIzed := tokenIzed || tokenChar;
         END IF;
          –> DO YOUR INTERESTING STUFF HERE
         DBMS_OUTPUT.PUT_LINE (tokenIzed);
         tokenIzed := ”;
      ELSE
         tokenIzed := tokenIzed || tokenChar;
      END IF;
   END LOOP;
END;

Tech Republic: Spamaholics

I read articles on Tech Republic from time to time. They’re . . . . OK. But I don’t remember signing up for this kind of email notification. You’d think a self proclaimed tech site would show a little more ethical behavior. Just goes to show you, their opinions are motivated. Here’s my recent inbox. WTF.

Tech SpamPublic

ORACLE: Batch Commits

I had to write an Oracle script template for work to kind of create a guideline for our developers since we are getting inputs from ourselves, DBA standards, and business requirements from our BA’s and customers.

Anyway, one thing they wanted was batch commits . . . so I wrote this quick little piece:

It creates a temp table, populates it, and puts a DBMS_OUTPUT line for whatever number I set the commit at . . . pretty self explanatory.

CREATE   GLOBAL  TEMPORARY TABLE temp_Cursor_Count  (
testNumber Number(10)
) ON COMMIT PRESERVE ROWS;
commit;

DECLARE

curVariable Number;

cursorCount Number(10) := 0;
cursorCommit Number(10) := 1000;
cursorMod Number(10) := 1;

CURSOR tt is
select * from temp_Cursor_Count;

begin

–populate temp table
For i in 1..9999
Loop
insert into temp_Cursor_Count(testNumber) values (i);
end loop;
commit;

FOR record_tt IN tt LOOP
–INITIALIZE Cursor values
curVariable      :=record_tt.testNumber;

cursorCount := cursorCount + 1;

select MOD(cursorCount,cursorCommit) into cursorMod from dual;

if cursorMod=0 then
–Normally this is where your COMMIT would occur.
DBMS_OUTPUT.PUT_LINE(cursorCount);
end if;

END LOOP;
end;

truncate table temp_Cursor_Count;
commit;
drop table temp_Cursor_Count;
commit;

TDD: Design for the Conditions

I am not a proponent of TDD, but I will admit it has its place.  And sometimes that place is not to use it, if the ultimate outcome will be of less value to the purpose of your software.

Some reasons not to use TDD if the conditions warrant are:

  • More code is higher risk for bugs.  Bottom line.
  • More expensive.  TDD translates into stories/function points/developer time.  I don’t care what anyone says, I still like TAD a little better to get repeatable regressive costs over time.

Use TDD if you are designing things that will benefit from it.  Don’t if it will not.

Object Design?

TDD is a design pattern, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.  The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.  I mean, if they are TRULY doing TDD that’s what they would do.

Timeboxing is Agile’s David

Its an interesting experiment to me; I do refactors and look for patterns.  Then I pull them out if needed.  Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”  If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.  Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.

I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.  I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.

A Use Case Where TDD would Fail – SUV Analogy

I am actually using TDD do do some PL/SQL conversion scripts right now.   I have to do it old school; and its taking time.  Sometimes I just write the conditions.  Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).  I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.

Talking with a friend I came up with this real-life analogy of where TDD would fail.

TDD thinks it addresses quality but one thing it introduces is possible defects  due to itself.   You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.  For example, it would absolutely be worth it if designing space shuttle software.  And, you had an unlimited budget.

But here’s an analogy where it would fail:

Suppose you are designing an SUV for extreme conditions.  In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.

The designers decide that testing of everything is very important.  So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:  you unscrew something and get a physical look.  Basically, a test has become part of the design.

But now the cylinder head is weakened because of the test.  You have introduced a few failure conditions:  possible weakened gasket that will let in contamination and cause engine failure.

  • In the wet condition this may be worth while.  Sludge buildup and moisture may be something causes buildup and there would be value to check the state of the cylinder periodically to make sure you don’t need to run a cleaning process, etc.
  • But in the hot condition, the gasket could keep failing and contaminants could be introduced via the testing port.  The strategy is just follow a maintenance schedule (TAD – test after), which you would have done anyway, because everyone has to do maintenance.

It’s just a hypothetical but there are a ton of other things in our life just like this.  Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.  The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.  Do vehicles really last any longer?  I’d argue that they do not.  TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.

I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:  “TDD: do it only if necessary.

Folder or Path as a Drive Letter on Windows XP

I was creating a setup of PortableApps on my XP machine with some of the great stuff you can port around in that framework: Open Office, VLC etc. without installing them into the OS. I didn’t have a USB drive with me, and thought hey, maybe I can just make a virtual drive from a folder and load the apps into that (I’ve done this using Cygwin in my development environment).

So I started digging through the commands and found SUBST. It associates a path with a drive letter.

Just open up a command line and type in the following syntax:


subst (virtual drive letter): (actual path)

So, for instance, say I want to mount a folder “\\atlas\shrugged” from a network drive as drive letter “q:” on my local –

subst q: \\atlas\shrugged

And a local folder as “x:” –

subst x: C:\journeyman

Disconnecting the virtual drives is simple enough, use the “/d” flag for delete:

subst x: /d

I haven’t found a ton of use cases for this yet, but it’s a nice little command line tool for any automated tasks you might think of someday.

Funny enough, when I was going through the PortableApps setup it now allows you to install to a folder — as I remember the older versions needed a drive — chuckle. 🙂

Updating Eclipse Projects From Java 1.5 to Java 1.6

When you are updating from jdk 1.5 to jdk 1.6 in Eclipse 3.5, make sure you hit all of these  touchpoints:
  • On your machine, install jdk 1.6 and change your environment path variables to point to the 1.6 directories.
  • In Eclipse, Under Windows->Preferences->Java->Installed JREs make sure jdk 1.6 is  added, and select it.
  • In Eclipse, Under Windows->Preferences->Java->Build Path->Classpath Variables make sure jdk 1.6 is added for JRE_LIB and JRE_SRC.
  • In Eclipse, Under Windows->Preferences->Java->Compiler set compliance level to 1.6.
  • In Eclipse, Under Windows->Preferences->Ant->Runtime set classpath variables 1.6.
  • Update your JBoss server/web server to use the 1.6 runtime.
  • In each project, change the compiler, the classpaths, the facets, and the runtimes for your servers (as applicable) to use jdk 1.6.

Then you should be good to go.  Build using both the Eclipse and the Ant methods to test . . . remember, the Hudson build server (or any build process) uses the ant scripts so if you check in the app with broken scripts you’ve checked in a bug!