Return of the Toolsmith

Software developments teams of late are becoming so fractious, toolsmiths are becoming a necessity to help maintain focus and development best practices.

• By Mike Gunderloy
• 11/15/2005

Brooks was writing before many of my readers began their software development careers (indeed, I suspect before some of my readers were born). Despite that, the point about development teams (the "surgeon" in his example is a metaphor for the lead programmer) needing their own dedicated toolsmith has never seemed more true than it does today — which just goes to show, I suppose, that things don’t really change all that fast in our field.

The Joy of Continuous Integration
What got me thinking along these lines was some fun I had recently with revising my own working process on a couple of small projects. I decided that it was finally time to get end-to-end continuous integration running here, so I paused writing code long enough to set up a couple of servers (using virtual machines — fortunately I had a relatively new dual Xeon server that wasn’t yet heavily loaded) and started downloading software.

The first order of business was to get a Subversion source code control repository up and running. Then I installed TortoiseSVN on my development box to give me an easy interface to give me an easy way to move code back and forth between the box and the repository. Next, I set up the other server as a continuous integration box with CruiseControl.NET as its backbone. This server also got all the tools to manage the build: NAnt for scripting, NUnit for testing, FxCop for compliance checking, NCover for code coverage checking, Simian for duplication checking, and Vil for metrics generation.

With all the pieces in place, I was ready to dive into configuration. This mainly meant some time writing NAnt scripts, though there was also time spent figuring out why things that compiled on the dev box didn’t compile on the build server (“oh, I forgot to install that library”). Finally, the job was done.

In case you’ve never used continuous integration, it’s really pretty slick. Now, as soon as I check a change into the Subversion server, the CruiseControl.NET server starts beavering away. A few seconds later I get a little notification in the tray of my dev box, and I can go to a Web page on my intranet to see what all the tools have to say about the quality of my code (usually at least one of them has something uncomplimentary to say, but that’s another story). It’s a wonderful system; With a smoothly-running continuous integration server, you know that at any moment you’ve got code that’s shippable (or you know exactly what’s broken). If you’re already using source code control, performing unit testing, and writing good specs, I recommend you look into adding continuous integration to your bag of tricks.

Keeping the Engine Running
But there’s a downside to all this plumbing, too. If your development process evolves to the point of depending on a continuous integration server and the software on it, you’d darned well better keep that server running. You’d also better keep the scripts that it depends on checked into your source code control. And don’t forget that this stuff is cutting-edge: All the various tools are under active development, so you can expect to have new versions to evaluate and possibly install on a regular basis. I have the luxury that I’m just futzing around. You probably don’t.

This is where I see the opening for the modern toolsmith. Someone has to stay down in the boiler room, shoveling coal into the engines that keep the whole operation running. Certainly, such positions have already existed in the software world for quite some time. If you go to Microsoft, for example, you’ll find plenty of build engineers whose job is to make sure that Windows or Office comes rolling out of source code each and every day. But I think more and more smaller teams are going to realize that this has to be a dedicated position, rather than something that gets done by other developers as an extra job at the end of the day.

It’s Time for Specialization
Let’s think about the things that a dedicated toolsmith might do for a team of, say, eight or ten developers:

• Keep the build and source-code control and bug-tracking servers running
• Test new versions of tools the team is already using and install them as needed
• Evaluate new tools and suggest ones that can streamline processes
• Write scripts and tools specifically for the team
• Document processes and be ready to set up the software environment for new hires

I don’t know about you, but I sure see a full-time job there.

Now, granted, these jobs already get done on small and medium teams. But how do they get done? In my experience it’s by some combination of asking corporate IT to do things (at least, when there is a corporate IT to ask) and hoping they get done, stealing time from other projects, working late, and shoving things under the table to be done later (like that ever happens).

Wouldn’t it be better to have one person who lived and breathed tools devoting full-time to making this stuff happen? Wouldn’t it be better to have your other devs devoting their time to writing the product’s code and not worrying about trying to be experts in NAnt and NCover and all the rest too? I’d bet the average eight-person team could pull one developer to dedicated toolsmith activities and not experience any loss in code productivity at all.

To my mind, this is just one facet of a change that’s inevitably coming to software development as our tools and target environments get more complex: specialization. Many of us are generalists now, ready to dive in and learn whatever the project requires, whether that be a new communications subsystem, a build tool, a new UI design language, or whatever. But I think we’re hitting the limits of generalists pretty quickly, if indeed we’re not already there. Consider the demands that Windows Presentation Foundation will make on user interface designers — do you really think every developer you know will be able to create an attractive user interface in the new world of Vista? I don’t. We’ll see user interface specialists commanding high wages from companies who have a clue. But I digress.

Moving Forward
It was Adam Smith, back in Georgian times, who pointed out the connection between specialization and economic growth. As large jobs are broken down into smaller components and workers become more specialized, they more expert in their jobs. This in turn means that they can do those jobs more efficiently, helping create more wealth. Though this principle hasn’t been widely applied to software development yet, I can see no reason why it shouldn’t be. Perhaps the toolsmiths of tomorrow will be the ones who lead us into a new era of creating richer software in a more efficient fashion.

Want to read more of Mike’s work? Visit his Larkware site for daily updates at http://www.larkware.com.