I’m currently reading Thomas Sowell’s A Conflict of Visions: Ideological Origins of Political Struggles. As the title suggests, it deals with certain fundamental differences in the way we see the world and how that affects our political views. Don’t worry, I’m not going to delve into politics in the post. However, I was struck by how applicable the ‘visions’ in the book are to the competing (and conflicting) views about how we should write software.
Here’s a simplified sketch of the two fundamental visions in the book. (Note that I’m not attempting to make a judgment call here on which vision is correct or better. Though admittedly, I have my bias. Likewise, I’m necessarily keeping it simplified.).
- Complex problems are best addressed by:
[a] systemic evolution or [b] clear and articulated reason
- When a complex problem is addressed the result will most likely be:
[a] a set of prudent trade-offs or [b] a solution
- Better results are produced when governance is provided by
[a] role and ritual or [b] well-educated individuals
This is just a few characteristics indentified in the book. We have a tendency to favor either the A answers or the B ones.
Let me unpack this now in terms of software development. I think that the philosophy of agile/software craftsmanship/etc has generally preferred the A answers. While more traditional software development has generally preferred the B answers.
- Many agile practices (such as TDD) build up software through systemic evolution. (Tim Barcz touched upon this idea some time ago). Evolution is at the heart of iterative design. In opposition to this is a heavy initial design phase (or Big Design Up Front). In BDUF, the problem is analyzed and a clear, detailed path is laid out.
- I think the second point follows implicitly from the first point. BDUF is a ‘solution’, whereas iterative development is inherently about trade-offs. By the term ‘solution’ I am implying that on such-and-such a date, the software will be delivered and the problem will be solved. The value is delayed, but it is complete. In an iterative project the goal is to deliver immediate, but only partial value. It acknowledges that some value is always omitted and that the software might never be complete.
- The third point is one of the more divisive ones. I believe that agile practices focus a lot on ritual. TDD is a ritual. (I believe there was a Hanselman interview with Robert Martin that discussed this point). Kaban, Scrum, and other similar practices are ritualistic. These rituals are the soil where the systemic evolution grows. On the opposing side, development teams are led by architects. That is, by well-educated and intelligent individuals who have a greater understanding of what needs to be done.
It is always important to admit your bias. I tend to favor the A answers above, though not always. I have been in circumstances where that approach broke down.
Regardless, I highly recommend the book as it has given me a lot of insight into my own views and those of others.
01-12-2010 6:38 AM