The anti-Agile manifesto

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.[citation needed]” 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?

Advertisements

6 Responses to “The anti-Agile manifesto”

  1. Eyal Mozes Says:

    I was taught about Waterfall development in college, in the early 1980s. It surprises me that you haven’t heard of it.

    However, I was taught Waterfall specifically as a theoretical approximation used in thinking about software development; my professor was very explicit that nobody actually develops this way. Waterfall was very well known during the 1980s in academic writings about software development methodology, but I’m not aware of anyone who thought it is the way developers actually work. 1980s conferences about software development methodology were full of talks with titles like “Beyond Waterfall”. The promotion of Agile in recent years as if it were an alternative to Waterfall is indeed a ridiculous straw man.

    • Gary McGath Says:

      I got my last degree in 1975, so by the eighties I wasn’t paying much attention to academic discussions of computer science.

  2. phillipmills Says:

    A couple of other ways of looking at Agile:
    – It’s depressing and defeatist in that it says, “We — as a profession — are not very good at planning, so let’s stop trying.”
    – It reminds me of the horizon effect from early computer chess; if I push a problem’s consequences beyond my look-ahead limit, it no longer exists.

    I think that if I were in the business of developing web sites, I’d consider an Agile approach…maybe. For anything less disposable than that, not likely.

    In 1981, I was on a development team that adopted the Waterfall approach. I think it was actually named Architecture-Oriented Development or something of the sort. It was the only project in my career that was a technical failure and I don’t think that’s just coincidence.

  3. twwells Says:

    I’m not familiar with this style of programming (though it sounds like it’s merely a relabeling of so-called Extreme Programming from a decade or so ago0 but one thing is very, very clear: It cannot possibly work unless managers wholly sign on to it. If, as is typical, a manager deems the project over when the code is shipped to QA and the tech writers, and thus doesn’t allocate time for code and documentation reviews, this so-called Agile Programming is merely a recipe for disaster.

    • Gary McGath Says:

      Agile is closely related to Extreme, though it drops some of the crazier ideas such as Pair Programming.

      Agile also involves Sprints, which are frequent deadlines sprinkled through development on which unrelated tasks have to sync.

  4. Bill Roper Says:

    My perspective is unusual, because I’m a programmer who actually has the right skill set to be a product manager if that was what I really wanted to be. As a result, I *desperately* want unfiltered access to some of our users, because I need to find out what *problem* they’re trying to solve, not what they believe the *solution* is.

    Having worked on more than one very old code base in my time, I’m also firmly convinced that working code includes accurate comments. :)


Comments are closed.