Methodology Wars

A sure fire way to set off a full scale geek war is to promote one software development methodology over another. Online behaviour being what it is, methodology wars usually take the form of tearing down an “opposing” methodology rather than promoting the preferred methodology in isolation. This approach serves two purposes; first, highlighting things you see as wrong is often a good way to clarify your point about what is right. Second, it’s a great way to attract attention and inflame passions.

Back in the day, operating system wars were all the rage and arguments over Windows vs. *nix vs. Apple left blood on the wall of many an IT department. The operating systems wars are far from resolved but methodology wars are a far sexier topic these days.

For a few years now, advocates of Agile methodology have been evangelising it as the cure to all ills (as a side note, it’s interesting how this topic lends itself to political and religious terminology – ideology, war, evangelists). One of the things the Agile movement has in its favour is a fairly significant mindshare in the IT set and a commensurate share of shelf space in the IT section of bookshops. One of Agile’s biggest problems is its supporters have trouble pointing to any large scale successes. By definition, Agile works best with small teams. In the real world, 90% of IT workers work in big IT departments. I’m not about to rush to the defence of huge bureaucracies but changing the structure of a company based on an unproven theory is a tough sell.

Another plus for Agile is its proponents are usually very good at identifying the shortcomings of existing processes and methodologies. The downside is often, again, that real-world success with Agile methodologies is more difficult to attain than the glowing manifestos tend to suggest. The tendency of Agile proponents to respond to failures by saying “You didn’t do it right” doesn’t inspire a lot of confidence in non-devotees. Surely if it is such a panacea it shouldn’t be so hard to implement?

At the end of the day, the right methodology is the one that works. Slavish adherence to any development dogma is going to get you into trouble (I could argue the same for actual religious dogma but that would probably get me into even more trouble than questioning Agile – if such a thing were possible.) The real world doesn’t fit into neat boxes and anyone who tries to arbitrarily fit diverse situations into the same box (because that’s what you should do, dammit!) is headed for a world of pain. And reflexively blaming failures on the… ummm, box-maker (taking a metaphor too far is a mistake) almost always undermines your credibility rather than advancing your cause.

Agile proponents often suggest the only alternatives are the twin evils of “waterfall” or “Big Design Up Front” (BDUF). Traditionally, the waterfall method assumes development is completely linear process. A business case is developed and thrown over the wall to a designer and/or Business Analyst. A spec is written and thrown over a wall to a software designer. A software spec is written and thrown over a wall to a programmer. A solution is developed and thrown over a wall to a tester. The system is tested then thrown to users. Anyone who thinks that such a process can deliver anything workable without making all participants’ lives a misery is far scarier than the most wild-eyed Agile evangelist.

In such a complex process as software and system development arguing that you can define ahead of time when any of the stages will be “done” and never need revisiting is tantamount to insanity. It certainly has no tangible relationship to reality. In any development cycle, each stage is likely to reveal something new or some additional complexity that wasn’t considered in the previous stage. Sometimes this will mean revisiting a previous stage to clarify the way forward and sometimes it means an extension to the time for the current stage to be completed. If a methodology isn’t fluid enough to allow for these variations then it is doomed to fail.

Full disclosure time:  Disclosure 1 – I’m a proponent (broadly) of what Agile fans derisively call BDUF, so long as the disclaimers are in place that allow it to be an iterative process.  I subscribe to the crazy idea that if you don’t have a clear idea of what you’re trying to do before you start programming (i.e. do at least some Big Design Up Front) then how the hell do the programmers know if they’re doing the right thing?  I’m also a believer in having faith in each person involved in the process so I like to keep the process fluid.  When one person discovers an issue that hasn’t been thought of up to that point, the process has to be fluid enough to cope with this (e.g. it must be possible to revisit design decisions and re-write specs when necessary).

Disclosure 2: I don’t have a great depth of knowledge of Agile.  I read quite a bit on the topic, usually from Agile advocates but I don’t have real-world experience of using the process.  Personally, I can see lots of promise in the Agile approach so long as the participants are open-minded and the workplace has the resources to dedicate to the required training.  Religious evangelism of Agile makes me uncomfortable and sometimes it seems absurdly easy to pick the zealots apart.

I read the Signal vs. Noise blog of the 37 Signals crowd quite often and I think they offer some excellent advice to smaller organisations.  I also think they have a tendency to promote their pro-Agile views as universal truths that will work anywhere.  When pressed (for instance, in critical comments) they will add the disclaimer “yeah, this might not work everywhere” but it would be a lot less annoying if they added this qualifier up front.  Glibly asserting that your methods are universally applicable when they clearly aren’t provides ammunition for your opponents – don’t give them a free shot. 

At this point, I’d like to add a disclaimer: The 37 Signals guys are probably much smarter (and richer) than me and definitely develop some very good products.  If I was running a startup I would definitely listen to what they say but for anyone in large organisations, a grain of salt is recommended.

Couching this discussion in religious terms is intended to have more than a humourous effect (although hopefully it added some humour).  Much like I would run a mile from an evangelical politician who zealously pursued his goal to introduce a theocratic state, I try very hard to avoid people who obsessively seek to install a methodology ahead of worrying about achieving practical results. 

I’ve seen enough examples of disasters to believe that it’s almost impossible to successfully implement an even moderately complex system without some formal methodology in place.  “Flying by the seat of your pants” is not a way of life I aspire to.  But when the tools start to take ascendency over the end result, it’s usually time for a reality check.

12 Comments

Filed under Work

12 responses to “Methodology Wars

  1. Good post Mr Angry.

    Like you, I am often in BDUF implementations. I think a significant part of why they are so maligned is due to the organizations they take place in, generally bureaucratic offices that place an emphasis on management and process rather than developers and results. So, when people criticize the methodology, they are really attacking the situation. It’s sort of a chicken and egg thing.

    I agree with you on how people tend to deflect criticism by saying “you just didn’t do it right.” It’s freaking annoying. It reminds me a little of my politics classes back in school when all those idiots said how communism would work if it were ever done right.

    In the end, I really think the success of any project will be determined by the capabilities of the people involved, which is exactly the opposite of what management folks buying these books and scheduling the seminars want to hear. If having someone else sitting over your shoulder watching you code makes you do a better job, great. I’ll be over here in my nice, quiet office.🙂

    -Mike

  2. Name

    Agile isn’t a state that you can be at – there’s no dividing line between ‘Agile’ and ‘Clumsy’. However, I have worked at one or two places that honestly believed that BDUF was the way to go. That you could spec something out, give it to the programmers, go play golf for a month, and get a finished product.

    I currently work in an Agile workplace. The design isn’t fixed in stone, development is mostly test-driven, and iterations are very short (a week or two, depending on what’s getting implemented). Although I don’t use any of the more crack-brained ideas, such as pair programming, the methodology as a whole is still ‘Agile’.

    Agile is simply the state of not using BDUF and the Waterfall model, nothing more.

  3. I actually meant to make that point so I’m glad you did it for me. A big corporation that screws up BDUF is likely to screw up Agile even worse. And a good team will do better with *shudder* waterfall than a bad team will do with agile. Australian sports commentators often call it “playing the man and not the ball”

  4. Some quick points:

    – whoever has spent some real, quality time reading, discussing and above all trying Agile knows that one of the Agile motto is “there is no silver bullet”

    – large scale Agile exemple are out there. My previous project involved over 40 people

    – what you describe as the way you do BDUF is NOT BDUF, it’s just the right amount of design needed to understand what is needed to be done.

    Don’t let a bunch of screaming people hide what many more – silent – others are doing🙂

  5. Your last point is my favourite – good people do good work without making a big song and dance about it!

  6. Good people do good work and make enough money that they can hire people to make a big song and dance about it.

    Sexy people.

    maybe I’m daydreaming at work again.

  7. mmmmmmmmmk ill do that.
    thats a good idea

  8. engtech: I like your thinking… I want to work for a company that has enough money to pay sexy people to walk around singing my praises

    victoria: glad to be of help

  9. A big problem with this topics (brought up all over the net) is the Agile vs agile. Every team needs to be agile as in flexible. But Agile with a capital A = Scrum, XP, Pair Programming, Daily Scrums, Scrum Masters, No Deadline, TDD, …

    I think pretty much every programmer on the planet believes in agile (lower case ‘a’). The disagreements are whether or not Agile (big A) is the best way to be agile or not.

    Unfortunately unless that is made clear half the comments are arguing about agile (little a).

  10. Gman: good point. I was definitely discussing Big A. hmmm, I’m probably the only one who remembers the old punk song “Big A Little a” so I won’t bother referencing it here.

  11. Very good article, I share your point of wiew on this one. Bringing your methodology to religious proportions and evengelism doesn’t do anybody any good. I also have a small article on this subject in my blog: http://hypersynapse.blogspot.com/2006/10/methodology-wars_116050729311845028.html.

  12. Pingback: nothing happens

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s