This post is a big shift from what I’ve been writing here before, but it’s my blog and I can do that if I want. :) Besides, I’m sure there are regular readers who are interested in this topic.
Lately I’ve been exposed more than I like to something called “Agile Development.” It’s a software development methodology which codifies the bad habits of many programmers. Its founding document is the “Agile Manifesto.” Its main tenets are brief:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Expressions like the last one nearly always mean “We don’t care about the items on the right.”
The first point is meaningless. Individuals are the ones who do the work. Processes are how they do it. They aren’t commensurable. Placing either one “over” the other just doesn’t mean anything. And really, today’s world is much too interactive for effective software development. Programmers need to be able to concentrate, not to be interrupted every five minutes with e-mail and instant messages and constantly shifted from one task to another.
The second disparages documentation. If you’ve ever tried to work with uncommented, undocumented code, you know what a pain it is. Working software that subsequent programmers can’t figure out doesn’t stay working.
“Customer collaboration over contract negotiation” actually does make sense, and it’s what attracts people to agile development. But watch out for everything else that comes with this package deal.
A plan for developing software should include allocating time and resources for responding to change, but just reacting to changes can’t replace planning.
The Agile line depends heavily on a straw man. If you don’t use Agile, its proponents tell us, you have to use Waterfall. Then we must have been using Waterfall all our lives, being ignorant of the glory of Agile. What? You’d never heard of it till the Agile people told you? Neither had I. Wikipedia tells us (as of this writing, the always-necessary caveat with that source) that “[s]ince no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.” Adopted by whom? Citation needed, indeed. In the Waterfall approach, you gather all requirements, then you do the design, then you implement it, then you verify it, and finally you go into maintenance. There is no overlap; one stage must finish before the next starts. This seems to mean you don’t do any prototyping during the first two stages, and you don’t test the code until it’s completely written. You always do development this way, don’t you? No? I don’t either. Maybe those people doing secret government contracts are the ones who do. That would help explain why they cost so much.
Less formally, Agile means things like putting the emphasis on getting something that demonstrates some functionality over sustainable design. Agile advocates tend to say that planning for future refactoring of code is a waste of time. If you have to change data bases down the line, you’ll just throw the whole thing out and start over anyway. If the code was written on those assumptions, that will be all you can do.
In my long experience in software development, certain things are consistent, and they aren’t Waterfall. Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of planning for flexibility from the start.
I do have to grant the strength of the third point again, the one that carries all the nonsense along with it. Software managers like to keep programmers in isolation. They’re afraid of what we’ll say to the users: things like “That’s a bad idea” or “It’ll take a long time to implement that for very little benefit” or “why not do this instead?” There’s a common saying among programmers: “I must be a mushroom. They keep me in the dark and feed me bullshit.” Grabbing on to an argument for actually talking to the users, and seeing their bad habits confirmed, they’re naturally attracted to Agile.
But we’re also the programmers who have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own buzzword. Sensible Development, anyone?