As a counterpoint to agile methods, check out this satirical look at Agile Bridge Building. It is the author's thesis that agile methods are based on the excuse that software development is essentially different from other endeavors. His opinion is software is not that different. Like any other creation it can be designed, estimated and planned up front.
In this corner, we have "blue state" agile practitioners telling us software is different and requires revolutionary new methods. In that corner, we have "red state" agile dissenters telling us software is not that different. The truth, I'm sure, lies somewhere in the middle.
Hacknot is back. I found the link to Agile Bridge Building on Hacknot. After a short hiatus it appears Hacknot is back. Unfortunately some articles appear to have gone missing.
Subscribe to:
Post Comments (Atom)
2 comments:
The anti-agile crew makes some great sounding points, I imagine they've actually seen some rigid methodologies work in their domains. However, every minute of my expeience tells me it doesn't. For a long time I figured I must be the one who's wrongs and I've followed along as processes became more and more dictitorial. I've built UML models, I've tried to write detailed specification before coding but none of this has taught me a fraction of the information that a first pass implementation has. I still write specs and build models but I do it for my own edification and at the level of detail I'm thinking at, not at the level of detail the process dictates.
That's what I meant by the truth lies somewhere in the middle.
It makes no sense to start a project by writing specs to a uniformly prescribed level of detail. That encourages some people to make stuff up and others to ignore important issues. And all of the specs are obsolete one month into the so-called coding phase.
On the other hand, a business needs some discipline. You need to be able to estimate costs and track a plan. The trick is finding the sweet spot between "working code" and documentation. Because one size process doesn't fit all, you need really smart developers and managers who trust each other. They'll know when you've hit the sweet spot.
Post a Comment