Software Development Methodologies
Given the amount of hoodoo, fear, uncertainty and outright rubbish written about the various ideas, I thought it might be timely to write a post outlining what each one really means — both for my own reference, and my own sanity — if this is of any use to you, that’s a bonus.
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 — so team leaders have a clue what’s going on.
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 (remarkably like a waterfall, funnily enough) through “Conception", “Initiation", “Analysis", “Design", “Validation", “Construction", “Testing" and “Support". The process is followed with rigour, and loved by pedantic team leaders who like to make spreadsheets, tick boxes, and spend time playing with Gantt charts. 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 simple 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 an 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 structured technique where early designs are turned immediately into prototypes, which are then iteratively evaluated, refined, redeveloped, 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 redeveloped 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 change.
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 basically 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.
Quite unlike extreme ironing, extreme programming does not involve carting a laptop into the middle of a busy road to write some code. 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 might well follow a lot of the ideas anyway, there is a strict swathe of rules, behaviours, and guidelines that you can 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. I’m being cruel, aren’t I. 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 — sit there, with your feet up, sipping coffee and spouting lofty ideas at somebody all day?
I’m guessing this blog post is going to generate it’s fair share of laughter, snorts of derision, outright anger, incensed murmurs of “he didn’t get it", and various other rumblings of discontent.
It’s worth remembering that 99% of development teams use elements of all the methodologies that have been written about in the text books. It’s also worth noting that all 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.