Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Greg Wilson is an Adjunct Professor in the Department of Computer Science at the University of Toronto.

In 2002, scientists at Lawrence Livermore National Laboratory found that, on average, 12 percent of the effort in a large project went into maintaining the build environment, and that on some projects, the figure was in the 20-30 percent range. If you include the time spent culling stale entries from the bugbase, figuring out which parts of the documentation are out of date and managing tests, it's surprising that any actual development ever gets done.

Luckily, with Practical Development Environments (O'Reilly & Associates, 2005, $39.95), Matt Doar has produced a practical guide to what should be in every team's toolbox, how competing entries stack up and how they ought to be used. Practical Development Environments covers everything from configuration-management tools (CVS and Subversion), to build tools (make, GNU's Autotools, Ant, Jam and SCons), various testing aids, bug tracking systems, documentation generators, and we're still only at the halfway mark. He names names, provides links and treats free and commercial offerings equally. My copy currently has 28 folded-down corners, which is 28 more than most books get. Recommended.

Neither Vincent Maraia's The Build Master: Microsoft's Software Configuration Management Best Practices (Addison-Wesley, 2006, $39.99) nor Rick Mugridge and Ward Cunningham's Fit for Developing Software (Prentice Hall PTR, 2005, $44.95) measures up to the high standard Doar establishes. Maraia's The Build Master is an uneven mix of how Microsoft does it (good), management advice (not as good) and anecdotes (uneven). Some of the material is eminently practical—if he'd concentrated on that and provided more example code, I'd give this book good marks. As it is, he seems to be trying to distill everything he's learned into one book.

Fit for Developing Software, on the other hand, is very focused. It describes Fit, a table-based framework for organizing and running tests, which is the best idea to come along since JUnit. I like Fit (and its Web version, Fitnesse), but I came out of the first four chapters of this book feeling like I knew less than I did before I started. I understand that there's always tension between breadth-first and depth-first exposition, but this book seemed to do neither. In the end, I found the best way to use it was via the index (a primitive form of Google, for those of you under 25). Fit is great, and everyone should use it, but if your mind's built along the same lines as mine, this book is probably not the best place to start learning about it.

We've all cursed slow software and unresponsive websites, and most of us have probably built a few, but making them zippy is often as big a challenge as building them in the first place. One reason is that modern computer systems are among the most complex artifacts ever created; another is that their components often interact in counterintuitive ways, so that optimizing a loop or adding another server can actually slow the whole system down.

Neil Gunther's Analyzing Computer System Performance with Perl::PDQ (Springer, 2005, $69.95), and Daniel Menascé, Virgilio A.F. Almeida and Lawrence W. Dowdy's Performance by Design (Prentice Hall PTR, 2004, $54.95) aim to introduce developers to the mathematics used to analyze and predict system performance. Both start with the kinds of simple models used to figure out how many customers a grocery store checkout clerk can handle in an hour. From there, they move on to more complex set ups with preemptive interrupts or feedback loops.

Both books compare theoretical predictions with measurements of actual systems, and both are clearly written and well organized. The big difference between them is their pace: Menascé et al.'s is a gentle stroll, while Gunther's varies between a fast jog and a gallop. As a result, I found myself flipping ahead often in Menascé, then flipping back to reread something crucial in Gunther. The extra effort Gunther requires is repaid by the Perl toolkit his book is built around, but on the other hand, I sometimes found myself tripping over minor typos.

Which book you read depends on how much calculus and probability you remember, and the complexity of the systems you're trying to tune. If performance matters, though, you should definitely read one. Otherwise, you may find that a week reconfiguring a server farm has saved you 20 minutes of thought.

RELATED ARTICLES ASP.NET Gets Testable Adobe, Saleforce.com Team Up for Flash Builder for Force.com Fuzzing Security Testing Tool Released Automated Functional Test Tool Updated Klocwork Announces Support for TI CCStudio IDE		TOP 5 ARTICLES No Top Articles.