Nigel Cheshire's Blog
David Seruyange pointed me to a great presentation by Yahoo! Javascript Architect Douglas Crockford on software quality. At least, “Quality” is the title of the presentation, but in fact Crockford gives a wonderful history lesson, showing how we got to where we are today. This is a 48-minute presentation, and well worth the time. If you don’t have time to watch the whole thing at work, do yourself a favor: forgo an episode of American Idol, set 48 minutes aside at home, don the headphones and listen in. You won’t regret it.
Crockford reminds us of some theories that have been around for a while, but have gotten lost in the morass of “snake oil” - new methodologies, tools and techniques that are claimed, by their vendors, to be silver bullets - quick, easy wins in the battle against poor software quality. There are no silver bullets, says Crockford, and you know what? He's right.
In case I can’t persuade you to watch the whole presentation, here are some highlights:
Crockford recalled some key points from the 1975 Frederick Brooks book The Mythical Man Month, which is still surprisingly relevant today:
He also referred to Donald Knuth's concept of Literate Programming, and Harlan Mills’ surgical team concept, which recognizes the fact that certain programmers can be as much as 10 or 100 times as productive as others. High performing developers are provided with a support team, which Crockford updates to include a co-pilot, a writer, a “language lawyer” - someone with a deep understanding of the language being used, a buildmeister, toolsmith, testers and interns. (Mind you, Dave Delay thought way back in 2005 that Mills’ perceived need for all those people just to support one programmer had been obviated by automation.)
One of the most powerful arguments for caring about software quality, at least from a business standpoint, is almost glossed over in the presentation. Crockford points out that for a company like Yahoo!, the state of the code base has a significant impact on the company's valuation. They look at two aspects of code quality: coding conventions (aka coding standards), and macro architecture. They have found that the easiest win for improving code quality is to improve readability. His suggestion (although he didn’t actually say whether they do this at Yahoo! or not) is that every 7th sprint, no features are added to the code; you focus on clean-up. Crockford ends by noting that security and simplicity go hand in hand: a way to make your code more secure is to simplify it.