Sometimes your inadequacies hit you over your head. I got a call on my cell phone about 4:00 today. The developer on the other end asked if there was anything for him to do. I had to answer no, and I’m fighting so many fires I don’t have time to stop and help him figure out what to do. Lucky for me he’s conscientious and just taking the day off tomorrow. I’ve been a manager several years now, but I still find delegation difficult in many circumstances.

Once again this development anti-pattern reared up and bit me. I lost the good part of an afternoon because I didn’t get around to insisting that every project be build-able from it’s ant build script in any environment.

The problem all started at lunchtime. Pretty much my entire development team is in some sort of training this week, but some of them are just in the next building over. It turns out that one of my contentious developers stopped by his desk on his lunch break and worked on his current project, though nothing was checked into CVS. He then deployed the war to the development integration box and went back to class. Unfortunately the WAR developed a nasty issue pretty much right away and since one of our mainframe developers is using it to test the integration to the mainframe we had a problem.

I don’t really believe in pulling a developer out of class unless it’s a true emergency so I vowed to deal with it between bites of a microwave burrito. Two hours later I was hunting for my fourth dependent jar. As it turns out this project only builds on two developer’s desktops. There are tons of dependent jars that are just supposed to be magically installed in JBoss’s default library directory. It only took about half an hour to find the ones I was missing on my machine, but I kept getting failures from our cruisecontrol box. Turns out I have so much extra stuff installed that it was finding what it needed, but on a base install with a base JBoss it didn’t have nearly enough.

I really, really dislike non-self contained projects. And I despise hunting down dependencies just to get an application to compile. After the jars got resolved another hour later it turns out theirs some properties file that appears to be nowhere in CVS. I guess I was supposed to know about this magic. Since it contains the connection parameters to make an RMI call to our legacy mainframe the application bombs real fast.

So by the time I had to go pick up my daughter, the application was still failing on the buildbox so I still can’t fix it on the integration server. I’ve had to check in a lot of things into the project to get it to this stage which will probably cause the developers some grief, but at the end of the day I think they’ll understand how their current practices have led to a fairly untenable situation:

• The project has two developers so if they’re both out no one else can build the system without hours of pain.
• Leaving dependencies on jars on app servers is great until someone deletes one, upgrades it, or just wants to port you to something other than JBoss.
• If your automated build tool can’t build the project from scratch, neither can anyone else unless they have some tribal knowledge.

OK, enough ranting.

We’re running a training course on RAD 6.0, IBM’s Eclipse 3.0 based IDE. I still can’t bring myself to install it, but since we have to use it for some portal and BPEL functions we figured it made some sense to get some baseline training for the developers.

The trainer seems to be pretty good, but he’s worked for IBM for 10 years and he’s true blue. So someone in the class challenged him on when RAD was going to support Java 1.5. He replied that it already did. A few minutes later typing in a generic example in all red as unrecognized and he admitted defeat. Small trainer rule, never say always.

I’ve heard the spiel about turning down bad clients from professional services firms I’ve worked for, but I’ve never seen it actually happen. I came across a post from a ThoughtWorker where they actually walked away from a paying client that was ignoring their advice and forcing them to work in a waterfall approach.

This definitely the right thing to do, but so often you need the revenue and you don’t have other clients beating down your door, so you stay with bad clients who are willing to pay. The consultants on the site get frustrated and eventually leave. You know you’re not really adding value even if they are paying $200/hr to sit in their meetings and write voluminous documentation that they review endlessly asking you to change boxes on diagrams or the name of a sub-heading. They ask for completely random enhancements which are going to take months to add and don’t seem to add any value, but since they’re willing to pay you don’t argue that hard against it. Nice to see ThoughtWorks was able to live up to the hype at least in this case.

One of the most frustrating things with legacy applications is the difficulty of harnessing them into test frameworks. Often they’re tightly coupled and it’s difficult to deal with. Usually if you’re just going in for a single bug fix it isn’t worth the effort of trying to put a unit test in.

From now on one of the items on my own mental checklist will be how to we test this new technology we’re adopting. If writing unit tests in applications using it are hard, difficult, or nigh well impossible, then there’s really no point in adopting it. If it’s really that great it should be testable. In other words things like Hibernate, Spring, and Drools are easy to test. Struts is a bit more painful because of inheritance and the web layer, but at least StrutsTestCase exists to ease the pain. Anything harder to test than that, EJBs for instance, don’t merit consideration.