There are a couple of big items on my blog to-do list. One of them is to write an essay about how hard it is to write software. Another to-do item is to write a review of Scott Rosenberg’s remarkable 2008 book Dreaming In Code.
Until I get around to these two tasks, you will find Kyle Wilson’s 2007 essay “Software Is Hard” to be a good start on both topics. Wilson is a software engineer in the game industry; and there is no harder toil than programming in the game business.
The blogosphere is dominated by the opinions of software developers who build browser-based software. Certainly this is important and valuable software, but it remains just one of the many variants. Wilson and Rosenberg examine the creation of game engine and email server software, respectively. Both of these categories of software are qualitatively, quantitatively, and morally different from iPhone apps or e-commerce.
The recent successes of agile methods have led many to see them as a universal panacea. Because a new social networking website application can be built very fast using Scrum and TDD, many developers believe that all software can be built just as fast with these agile methods. But the demands of military or medical or game software are very different from those of tweeting or shopping.
There is no doubt that agile development is a significant step forward in creating software. It is certain that agile thinking will eventually permeate every aspect of software development. But it would be a mistake to think that every variety of software construction will be affected equally or that there will be any semblance of uniformity of agile practice across the full range of programming. It’s easy to extrapolate universal truths about software development by examining your own software development work experience, but this is a sinister trap. The world of software development is far broader than most people realize.
Even though Fred Brooks’ famous aphorism that there is “no silver bullet” in software is quoted frequently by agilists, they use it only as a weapon against diehard supporters of obsolete waterfall development methods. They often don’t see that it applies to agile methods just as profoundly.