Project managers like to talk about models, methodologies, and methods. They like to sound clever — throwing acronyms around, and spouting catchphrases and buzz words as often as possible. No realm of information technology seems to display this mania quite so aptly as software development.

Given the amount of hoodoo, fear, uncertainty and outright rubbish written about the various ideas, I thought it might be time to write a few words outlining what the various methodologies actually mean in the “real world”.

First things first…

What is a development methodology?

Broadly speaking, it’s the description of an approach to building software — the reason to have the description in the first place would be to get a team of developers to work in a similar manner to each other, and so that team leaders have a clue what’s going on.

Right. So what are the various well-known methodologies?


The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards — like a waterfall — through the phases of conception, initiation, analysis, design/validation, construction, testing and maintenance.

The process is followed with rigour and loved by pedantic team leaders who like to tick boxes and make everybody’s life hell. It’s incredibly expensive to do, and customers both love it and hate it — they love it because it can be run on a fixed price, but they hate it because a calculator application ends up costing as much as the space shuttle.

Iterative and Incremental

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with initial planning and ends with deployment — with the cyclic interaction in between.

So, essentially, this is Waterfall where we admit that waterfall is idiotic, and we agree to go round and round in circles until we’ve spent just as much time, effort and money as Waterfall. I guess brakes can be applied in the form of somebody in the middle of the mayhem who continually asks “is this good enough — will it do?”. Iterative development is often tied to the “Rational, Unified Process” — another meaningless description heard often, but understood by nobody.

Rapid Application Development

Rapid application development is a supposedly structured technique where early designs are turned immediately into prototypes, which are then iteratively evaluated, refined, and re-developed ad nauseum until the finished product is produced. “RAD” was invented to combat the main problem of Waterfall based development methodologies — by the time anything got built, the requirements had changed — and by the time the re-developed solution re-appeared, the requirements had changed again.

Rapid application development became very fashionable in the mid-1990s with the advent of visual design tools such as Visual Basic and Delphi that allowed fast interface development. It also caused some of the worst spaghetti code in the known universe due to nobody paying their “code tax” and inviting developers to go back and clean up after requirements had changed.

Agile Development

If you are a fellow developer, you were expecting this one to be in the list — probably because it’s the fashion of the moment, and all managers in the known universe think Agile sounds cool when talking to clients. I expect they stand in a “ready for action” fake karate pose when they say it. In reality, the “Agile” label covers a swathe of similar methodologies — the Wikipedia description reads as follows;

Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Phew! So it sounds like it will save the known universe — and it’s growing popularity has resulted in more being written about it than any other method — meaning that Managers can now have big fat books about it on their shelves, and communicate in pure acronym when discussing project plans.

In reality, all Agile really means is that you will communicate, you will try to make things work, you will be trusted (!?), and you will not blow a gasket when requirements change. Of course, the customer also has to realise that change equals longer or less.

Extreme Programming

Quite unlike extreme ironing, extreme programming does not involve carting a laptop halfway up Aconcagua to write some C++. It is however similar in taking ideas from several flavours of Agile development and constructing a set of “ideals”, or “expected behaviours” around them.

I can only imagine the anal, ivory-towered developers that dreamed up Extreme Programming as a methodology — whereas most of us may naturally follow a pragmatic process when writing code, Extreme Programming introduces a strict swathe of rules, behaviours, and guidelines that you must follow if you really want to be an “extreme programmer”. I’m guessing the people who like working this way also have 20 sided dice in their desk drawer (which is no bad thing, in and of itself).

One of the ideas within Extreme Programming that I really like is working together — so that one of you programs while the other thinks. Can you imagine sitting there — feet up, sipping coffee and spouting lofty ideas while a co-worker swears at the computer, and thumps the desk?

In summary…

I’m guessing this blog post is going to generate its fair share of laughter, snorts of derision, outright anger, incensed murmurs of “he doesn’t get it”, and various other rumblings of discontent. If it has done so, then it has succeeded.

It’s worth remembering that 99% of development teams use elements of all the methodologies written about in textbooks. It’s also worth noting that most attempts to build software in a faster, more efficient, more responsive manner are eventually defeated by millions of words being written about them in textbooks, and managers applying so much structure, measurement and review that you may as well call them all Waterfall and have done with it.