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.

Only 1 day into the new Cruisecontrol across all the developer projects. By 8:30 this morning I had two programmers standing in my office asking why they were getting these emails from ChickenLittle. ChickenLittle is the name of our build server, the idea’s borrowed from ShipIt! They were fine once I gave them a 5 minute explanation on the whiteboard and understood we were just gradually easing into the builds over the next week. Of course after next week broken builds will have to be cleaned up quickly.

The interesting thing is even today where it’s really just more of a dry run I saw more evidence of the indirect benefits. One of the builds is still broken because they need to checkin a dependent jar. So on each checkin the failure emails go out. We’re using the HTML email publisher, and the list of changed files from CVS with the owner and the comment shows up at the end. Turns out the senior developer making fixes has a good habit of adding meaningful CVS comments like ‘cleaned up deeply nested conditional statements on calclulateInterest()’. The other developers have just been checking things in with blank cvs comments. So expect soon I’ll see a lot fewer empty cvs comments.

Today, I finally got around to sitting down with one of my senior developers and adding all of our current projects into Cruisecontrol. For the last month or so I’ve only been running one project on the automated build. But I freed up some time today and added our other two projects in about 30 minutes. Both bombed of course. The first one relies on some library the developer thought would be in JBoss’s library. The second only passes 8 of it’s 13 unit tests since the 5 are JWebunit tests and rely on the web container being up and running. But the buzz started since the emails are going out now. No one likes failing emails, or maybe I’m kidding myself and no one likes failing emails when annual reviews are around the corner.