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.