Way of the Retainer

What if I told you right now that you could have a free developer on your team? No cost except interview time, and this mythical dogsbody would diligently do nothing other than compile the latest code in source control, perform anal-retentive checks against Sun’s coding standards (or your own company coding standards, if you’re one of the rare examples implementing standards beyond Sun’s) and run unit tests. And they’d do this twenty four hours a day.

If you’ve done time doing Java development, you can probably see where this is going already.

Automated builds.

Nothing incredible or revolutionary here. Sure. Nothing new. And yet, the number of times I’ve had conversations with really smart people that have gone along the following lines:

“So, do we have automated builds?”
“Er, no… we didn’t have time to set up automated builds”

Really smart people, and yet there’s a contradiction here that so frustrating that it makes steam shoot out my ears. Automated builds don’t cost time, they save time. Mentally tally up:

• Time lost across the whole team because one developer either checks in a broken file, or forgets to check in something critical to the build (that’s my personal cardinal sin)
• Time spent across the whole team hand-cranking unit test suites (or, even worse, manually testing functionality repeatedly) to validate code
• Time spent by your poor harried release manager lovingly handcrafting artifacts to release to controlled environments.
• Time spent before releasing code to prying eyes spent polishing and refinding and whoops!… I just broke a unit test.

  …and that’s just off the top of my head. Now compare all of that to a day’s solid work for one developer putting together a workable, basic automated build process in place, and then realistically spending another 2-5 days throughout the project tinkering and tuning.

  For my money, I don’t understand how you can make do without automated builds. An automated build is like a canary in the dank mines of team development. Is it safe to update from source control? Possibly not if the canary’s been pinballing itself bloody back and forth against the bars of its cage for the last five hours. Time to go on a developer witchhunt instead…

  I’m helping out with a development project that is being run out of our Brisbane office at the moment, and even on days when I don’t have time to code, firing up CruiseControl helps me keep an eye on what’s happening up north. Oh, and hey – speaking of CruiseControl, the instigator for writing about all of this was getting a chance to check out the latest release of CruiseControl – 2.7.1. The latest at the time I downloaded it, at least. You know all those magical transformations in teen rom-com-dramas where the smart, funny, practical girl you’d date anyway suddenly gets seriously sexy on the other side of a montage sequence?

  Yeah. CruiseControl has always been a fantastic tool, but with the help of some hardcore GUI development and some serious Ajax love, the automated build dashboard has been enhanced beyond belief. Just a quick look at some of the information CruiseControl puts at-a-glance: (click images for a larger view)

  Current build status

  

  CVS modification logs – a summary of checkin messages left by developers

  

  Test suite results

  

  One to six days work over the length of the project, and you add the most diligent developer you’ll find to your team. And you can scale that commitment in time to what makes sense to your project. You only get to add that magical free developer once, but they’ll never complain, never steal your Jolt, never steal your girlfriend with their more impressive range of Jinx.com T-shirts, or steal your precious torrenting bandwidth.

  I can’t think of another way to get that significant a return for that same amount of time.

No Comments »