I was talking to one of IBM's Chief Engineer's, Landon Miller, about the religious wars that seem to flare up around "how to develop good software." I don't write often about software design and development methodologies, but if your projects require you to design and build your own software applications, then the relevance of this entry to your project leads should be straightforward.
The crux of our discussion was around the dogmatic battles between traditional software development models and agile approaches. The crux of the debate tends to revolve around the weaknesses of each approach. Rarely do the debates revolve around the strengths of each model.
In the traditional approach, the emphasis is on "documentation." In the agile approach, the emphasis falls on "working code."
The problem, say the agile zealots, with the traditional approach is that the teams get caught in a never-ending process of requirements gathering and paperwork and you end up creating a fantasy target that the team can't hit.
The problem, say the traditionalists, with the agile approach is that you just start coding and you have no fundamental architecture that will scale as your needs grow. You end up with spaghetti that has to be thrown away.
This "us and them" difference may seem a bit simplistic, but it's not all that far off from many conversations that I have found myself caught up in. You try to explain the value of documentation to an agile zealot and you are branded as quaint but dotty. You try to explain the value of agile to a traditionalist, and you are branded as a dangerous cowboy. I often find myself dancing in the DMZ of this one.
For once, right up front in our conversation, Landon and I both said that "this is a false choice." The best solution is a blend of both. Now, what he means by a blend and what I mean by a blend might not sync up when we hit the white board, but here's the point. The religious discussion is pointless and distracting.
Good leaders use the best of both (and whatever else they can use) to create a methodology that works. Even agile methodologies need to be written down and followed. Inculcate your teams in your methodology. Remain open-minded and change the approach as you go, but don't get caught in a pointless discussion that's based on dogmatic positions.
Comments