Agile Programming: How to doom your software project

This morning, Kasia pointed me to "Agile Programming", and her take was that it was yet another buzzword. Looking into it, I find that it's more than that - it looks like a roadmap for running a project into the ground. And nobody would know why.

Reading the Manifesto for Agile Software Development we see a list of lovely platitudes that sound so nice, but hide a sinister reality.

• [We value] Individuals and interactions over processes and tools

Obviously we want to treat team members with respect and bring out the best in everybody, but those interactions have to be minimized as much as possible. Brooks' Law says that adding manpower to a late software project makes it later, and this is because of the exponentially increasing number of communications channels.

Tools and processes are fundamental sources of quality, and though of course it's possible to saddle a team with lousy tools, good tools offload much of the tedium and allow the team to expend its energies on things that matter.

Of course, no programmer is an island, and an awful lot of hard problems are solved not by a good tool, but by two developers chatting over coffee. But I think that a lot more projects have been sunk by not-enough-tools than by not-enough-interaction. I doubt many have been sunk by not-enough-people.

• [We value] Working software over comprehensive documentation

I can certainly see where this comes from, and it's hard to argue that if the software doesn't work, it doesn't matter how good your docs are. But professional developers revolve around the specification: without a spec, the developers are just hacking at code without a common purpose. This works great at the beginning (lots of progress) but goes downhill very rapidly.

The best way to appreciate the value of a good spec is by doing a project without one.

Furthermore, I have long held that "it works" is not the sole metric of software project completion, or even the best one; there are real qualitative differences between various kinds of "working" code, and anything that encourages "but it works" responses is saying that quality doesn't matter all that much and that all developers are created equally.

• [We value] Customer collaboration over contract negotiation

This has a "forget the spec, just start programming" smell that frightens me. "Contract negotiation" is not just deal-making and paper-pushing: it's deciding what the customer wants. Not only does the development team have to know what the customer wants, but the customer has to know too, and the very fact of going through "contract negotations" helps set the plan for the whole project.

Some years ago, a customer wanted me to build a large software system, and they wanted me to "just start programming". In spite of their desire for "customer collaboration", I insisted on writing a formal specification. Several weeks and 100 pages later it became clear that the project was well beyond what my customer could afford, so it was scrapped. My pushing back and forcing extended "contract negotiations" saved my customer an enormous amount of time and money.

• [We value] Responding to change over following a plan

When I see "a plan", I think "a specification", and anything that gets away from this is trouble. I think it's self-evident that change will happen during a project: sometimes external factors change the requirement, sometimes the customer didn't really think it out clearly up front, or perhaps somebody just had a great idea partway through the project.

Hopefully one has built a system that tolerates change, but one cannot send the message that change (especially late in the game) has no costs, or at least costs no more than change early in the game. Going through a round of "OK, let's find out what you really want in this change" not only nails down the details, but it creates a climate of taking change seriously.

In fairness, when one reads Principles behind the Agile Manifesto one does find good points: stepwise refinement has been a great idea (at least) since Niklaus Wirth wrote about it in 1971, and fostering teamwork is essential to any project. And any project that doesn't involve the customer on an ongoing basis is doomed.

But the whole "Agile Programming" idea seems (at best) a platitude fest, and I don't see how any actual professional software managers could have participated in this silliness. Looking at the manifesto, I can't help but believe that more projects have gone south due to following the warm-fuzzy festo points in favor of professional software-development disciplines: why would anybody want to encourage this?

And I wonder what Joel would say about this?