Today, Joel discusses how horribly the mainstream media reports on programming tools (and I would argue technology, in general) - specifically how there’s always a reference to a new tool somehow turning programming into something similar to putting together Lego blocks. The most interesting part for me in his post was at the end, when he quoted Fred Brooks from the essay No Silver Bullet (emphasis mine):

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

I’m not sure that Joel would agree with all of my own conclusions from that statement, but the way he quotes it, I think we would agree on the problem itself. Either way, it really made me think. Based on my own experience, agile seems to be trying to address exactly those concerns.

If the specification is one of the hardest parts, a fix for that is short feedback cycles. This, of course, is not an agile-only concept, but a it’s a defining quality of agile approaches, rather than just one way to do it. Another is not attempting to fully document the specification, but rather keeping an open dialog between developer and customer / business owner / subject matter expert.

Regarding design, some key ways to minimize “the hard part” include simplicity, refactoring, and the use of metaphor when building software - not strictly agile, but again, key tenets of agile approaches.

To address the testing of software, automated tests and continuous integration (to run the tests) definitely help. Additionally, short iterations make things easier for people to test functionality because there are fewer things to focus on. And an on-site customer helps to have a subject matter expert there for questions during the whole process.

The whole subject is making me give me serious thought to going back and reading The Mythical Man-Month again.