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.

I’ll be launching a small project soon to remove the last dependency on a certain unnamed enterprise tool my company purchased years ago for a few hundred thousand dollars. It has the cost benefit analysis every business person could love. For a week or two of one developers time we can save 50k a year on the support contract. It’s rare when things are that clear cut. And it reinforces a lesson I’ve learned over and over never to promise the business some magic from an expensive tool.

I started my first ever iterative project with a very complete exhaustive requirements iteration, then a design and prototying iteration, and then three iterations where we delivered code, then a system test iteration, and finally a deployment iteration. Booyah! My first iterative project!

At the end I looked back and felt pretty much like other projects I’d run in the past. I had read up on RUP, but misapplied it badly because I made what is apparently a fairly common mistake. Basically it runs RUP as a waterfall. A lot of this was because I didn’t have the advantage of actually being on a well run iterative project. I’d been part of a team or even run several projects, but I was always one of the few who knew anything about methodology. A lot of this harkens back to dotcom days when even knowing about a basic software development lifecycle was something to toss on the old resume.

The funny part was the project was successful for the most part, basically because of the people on the project who did what was needed to get the job done. People very often can trump pretty bad processes.

Anyway I find myself in a similar position now implementing Scrum. I have no examples to go by so my information is again from books, conference presentations, and blogs. Still Scrum is a pretty straightforward process, but all sorts of things can still crop up and the implementation details can kill you. One of these days it would be really, really nice to have a mentor who knew a lot more than I did. Still showing any attention to Agile methodologies is still pretty bleeding edge for most corporate IT shops, so it’s hard to find a mentor unless you can manage to hire one in.

It occurred to me that if JSF is starting to see a lot of adoption, that there’s probably some testing framework for it, possibly to mock up things like FacesContext. Sadly it doesn’t appear as though there is much thought given to how to test JSF even though testing GUIs has been a pain point for a while now as seen in this post by Rob Williams:

The one thing that I bet is not even on the radar of the JSF team, but I would peg as its biggest shortcoming is its ill-disposition toward testing.

In the comments Rick Hightower mentions having mocked a FacesContext object to get around some things, though there’s no code to be seen. This was the best I could find after a lot of searching on how to unit test JSF. Something seems to be giving off a bad smell and I don’t think it’s my daughter’s dirty diaper.