Click here to Skip to main content
12,944,410 members (51,491 online)
Click here to Skip to main content
Add your own
alternative version


50 bookmarked
Posted 4 Nov 2010

Software Development Methodologies

, 4 Nov 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
A Young Person's Guide to Development Methodologies


Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects. In this, the first of two articles, I will introduce the different types of methodologies. I will describe them from an historical perspective, as one way to understand where we are and where we are going is to know where we have been.

There will also be a subsequent companion article looking at the current state of the art and what I believe the future holds. This second article is given the rather controversial title of "Why Creating Software is not Engineering", which I will, of course, explain. In the 2nd article I will discuss several popular agile methodologies particularly their most important aspects (such as unit testing), which are generally neglected or glossed over.

Before beginning I should warn the reader of my penchant for analogy. Actually this whole article is one big analogy stretched almost to breaking point. I like them because many of the concepts in software development are abstract and hard to grasp, but using a familiar real-world situation, like taking a taxi to the pub, can clarify the ideas. Of course, there is always the caveat that no analogy is perfect. Be careful to understand the similarities and the differences.


Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology.

We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few minutes later you arrive at your destination safely and without wasting any drinking time!

In this analogy you are the "customer" and the taxi driver is the "developer". The above is the ideal case where the customer knows where they want to go and the developer knows how to get there. Unfortunately the real world is never this simple. Consider these variations.


1. You tell the driver where to go but you end up at the train station not the Station Hotel. Obviously he misheard you and after all many of his passengers go there.

You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. Eventually, you work out that the driver does not speak English well.

At some point you give up. If you are really persistent you might get to your destination but by then Jim has already left.

2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". Apparently, there are three within a ten mile radius and you don't know which one Jim went to. You try them all but can't find Jim.

The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started.

3. The taxi driver kindly informs you that your destination is quite distant and you do not have enough money. He suggests that you take the bus.

Of course, the bus is slow and does not go directly past the pub. You get there eventually.

4. The taxi takes you straight to the hotel but it's closed for business.

5. You are half way there when you realise you need to post a letter. Then Jim calls your mobile and says that he has gone to a different hotel. Then you get stuck in traffic and also need to use the bathroom. The whole trip is much longer and more expensive than expected.

6. The taxi driver seems to know where to go but is inexperienced and after quite a while he realises that he is going completely the wrong direction. Several times he has to backtrack but eventually finds the destination though the trip takes much longer than expected.

I'm sure you can think of many more things that can go wrong.


The ad-hoc methodology can work provided you have a simple problem. If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success. However, most of the time you get there late or not at all.

The above scenarios represent several common problems seen in software development, namely miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the reader to work out what scenario 3 means.


OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to ask an expert for help and there are many willing helpers ready to provide their services, for a fee, of course. You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed unambiguous instructions on how to get there.

The analyst works out by deduction and/or educated guesswork exactly which "Station Hotel" you want. Perhaps they even manage to contact Jim to confirm the location. They also find out the exact address and the opening hours.

Now you know exactly where you want to go but how to get there? The designer provides a "specification" or instructions for getting to the hotel - eg proceed 2 miles to the roundabout, take the 3rd exit, etc. To ensure that the driver understands the instructions the essential parts are even translated into his native language. A good designer might also try to anticipate problems and have contingency plans - eg, if the freeway has heavy traffic to take an alternative route.

The essential point of the specification is to have the trip completely and thoroughly planned before starting out. Everybody involved reads the specification and agrees that this should get the customer to the pub on time. Can you see a problem with this approach?

While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been some time and you still haven't gone anywhere. You also want feedback that once you start the trip everything will stay on track, since your experience of taxi journeys is that they can be very unpredictable and the driver never gives any indication of whether he is lost or on course.

You need a "plan" so that you can check that everyone is doing there job and that if something is amiss it will be immediately apparent. The plan will also require the driver to regularly report his position so you know if he is going to be late or not get there at all. For a large project you will need a "project manager" to formulate the plan.


This all sounds very thorough and reassuring but there are many problems with this approach.

1. First the taxi driver has to read and understand the whole specification before starting out - for example, he might have to work out where he can buy fuel if necessary. The specification is complex and detailed and it can take some time before the driver understands it enough to begin.

2. The taxi driver attempts to follow the specifications exactly but there are a few small ambiguities and he makes a wrong assumption. By the time he realises the mistake he has gone for miles in the wrong direction and has to backtrack.

3. There are crucial assumptions in the specification that nobody checked. For example, you can never get a taxi after 8pm on a Friday. The designer had not considered this but his excuse is that it was outside his purview - the customer should know this since he is the one that catches taxis and after all he signed off on the specification.

4. Things happen that were not anticipated. For example, unexpected traffic snarls cause slow progress.

5. There are problems that the designer was not aware of. For example, roadworks that require a lengthy detour. The taxi driver knew about it but nobody asked him.

6. There are problems that nobody was aware of. For example, the planned route goes the wrong way down a one-way street, even though it was not marked as such on any map.

7. There are some things that you (the customer) forgot to mention - eg, you need to stop at the bank to get some cash on the way. It seems like a minor thing to you, but the designer complains that it completely invalidates most of the specifications (though he exaggerates of course).

8. There are unexpected events that nobody could have anticipated such as a major accident that causes traffic chaos.

9. The taxi driver becomes annoyed and frustrated with the process. "Just tell me where you want to go!"

10. The project plan estimates that the journey will take an hour. The passenger immediately starts reading a book or falls asleep in the back seat. The taxi driver thinks it will take half that time, especially as he knows a shortcut. He dawdles for awhile, makes some detours to take care of some personal business, and loses track of the time. The customer wakes up and wonders where he is - the driver assures him that all is going to plan.

However by now there is only 15 minutes to go and he's hardly made any progress. He finds the road for his shortcut has been closed, then gets booked for speeding. In the end he makes a huge effort and only arrives 20 minutes late. Ironically, he is praised by all for being so dedicated.

11. The designer knows from past experience that taxi drivers vary widely in ability. The specification is written to the lowest common denominator, even though this demeans the average taxi driver.

12. The designer knows that the taxi driver has a tendency to deviate from his specification. This can be at the behest of his passenger (see 7 above), or he may take the scenic route to make the trip more pleasant (and increase the fare), or take a shortcut that may save time but has many risks involved, or simply take a diversion out of some personal interest.

To counter this, the designer will try to limit the information provided to the driver to only what they need to know. As an extreme example the designer might cover all the windows of the taxi and make the driver navigate entirely using the odometer and a compass. Obviously, this a very dangerous approach as the driver has no feedback at all in order to correct for even the slightest deviation from the course.

13. You start the journey but there are a lot of problems and delays. You manage to contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. (Unfortunately this completely invalidates the specification which is discarded.)


The waterfall model can work if everything goes to plan, but in a complex project things rarely do. The crux of the problem is the reliance on getting the specification perfect before attempting to implement it. Unfortunately, even if you get close to getting it right at the start things will change. For most real-world projects this means this approach is doomed to failure, or at best a late and over-budget project and a very frustrating experience.

The above scenarios represent several common problems with the waterfall methodology namely the difficulty of understanding (1) and following the specifications (2) and getting them right in the first place (3, 5, 6, 7). The process does not cope with change (4, 8, 13) and does not make best use of the developers (9, 11, 12).

A major problem is that without hard deliverable milestones most developers will procrastinate at the start (10). However, to be fair this behaviour is reinforced by the fact that the most projects have major changes (or are even cancelled) well after development has started. To the developer there is no point in working hard at the start when in all likelihood the effort will be wasted.


The prototype methodology addresses the major problem of the waterfall methodology's "specification", which is that you are never sure it will work until you arrive at your destination. It is difficult or impossible to prove that the specification is correct so we instead create a simple working example of the product, much like an architect would create a scale model of a proposed new building.

To continue our taxi analogy the designer, or a delegate, grabs a motorbike to first check that you can actually get to the Station Hotel and even explore a few alternative routes. When the motorbike driver has found a good way the actual taxi trip can begin.


1. A motorbike is not a car. It can bypass traffic snarls or pass through narrow lanes that a car cannot. In his eagerness to prove the feasibility of the trip the designer may gloss over the fact that the taxi trip will take a lot longer.

2. To you (the customer) it seems that creating a prototype is a waste of time, since your trip can't begin until the motorbike has arrived. (The taxi could start out before the motorbike arrives but there is always the risk that a better route is found and the taxi has to backtrack.)

3. You decide that if the motorbike can get there so easily why not just jump on the back and avoid taking the more expensive taxi trip altogether. The problem with this is the motorbike trip may be far less pleasant. Moreover, the motorbike is not designed to take a passenger and can become unstable with you and your luggage causing an accident.


The prototype approach is good if there are a lot of unknowns about how the best approach or even the feasibility of the project. Different routes can be quickly explored and the best decided on. However, if the best route is obvious and well travelled then creating a prototype is unnecessary. In the end completing the project may not be made that much easier by having a prototype.

The above scenarios represent these problems often encountered with prototypes: creating the final product can be a lot more difficult than creating the prototype (1) and the use of a prototype may not be of much benefit anyway (2). A major problem is that once a customer tries a working prototype of the software there can be pressure to simply use the prototype rather than develop the full product even though the prototype may be completely unsuitable in many non-obvious ways (3).


This is not so much a methodology as an approach that tries to use new technology. The idea, pushed heavily in the 1980's, is that very high level languages could be developed to allow users to create their own applications. These so-called "4th generation languages" were supposedly easy enough for anyone to use.

In our analogy this is like getting rid of the taxi driver altogether. Of course, most people can't drive taxis (in the analogy) so we need a simple system where the user just has simplified controls. Unfortunately, the only way this was possible is to create a huge network of guidance rails to keep the taxis on track.


1. You get in the taxi, enter the destination, and you get an obscure error message. You go nowhere.

2. The cost of the rail network is enormous so it doesn't go to very many destinations yet.

3. You need to go by a long and circuitous route even though your destination is not that far away.


The idea is good but in general it is not workable. Perhaps one day, with advances in AI, this approach can work.

The above problems mean: the technology is not good enough (1) and expensive to develop (2). In practice the product is slow and cumbersome (3) and gives generally unsatisfactory results compared to other methods (2).


The precursor to today's agile methodologies (see below) can be loosely grouped as "iterative". They are also often described as "cascade" methods as they are really just a series of small waterfalls.

I am not going to discuss these in detail as they were not very widely used (except nominally) or very successful. They were more an attempt to fix the problems of the waterfall methodology rather than to bypass them altogether. As such they had many of the same problems, and even exacerbated some.


The main problem with the waterfall approach is that it takes a lot of effort up front effort in planning, analysis and design. When it comes to the actual implementation there are so many variables and unknowns that it is very unlikely to go to plan.

The prototype approach meant we could eliminate some of this uncertainty by demonstrating that there is a reasonable chance of success. However, there is still a lot of up front effort to design and build the prototype even before we even start the real development.

What if we could divide the project into a sequence of steps so that at each stage we can demonstrate that we are closer to the final product? After each step we produce a working (but not final) product so that the customer can see that the project is on the right track.

To continue our taxi analogy we can start our journey immediately since we know that to get to any of the possible destinations we have to take the main road into town. When we come to a point where there is uncertainty we stop to assess the position and choose the best path. Further, by continually re-assessing we can adapt to any unforeseen and new developments.

On the surface this looks very much like the "ad hoc" methodology in that you just jump in the taxi and go. Indeed, it does empower the taxi driver with finding the best way again but the feedback mechanism allows more people to see what is happening and to keep things on course.

It also does not preclude the use of extra team members to ensure the trip is smooth and trouble free. A navigator could monitors traffic conditions, looks for trouble spots and try to find the best way to the destination. A mechanic could ensure that the taxi is always in good condition and will not break down.

But there are still pitfalls to watch out for.


1. You (the passenger) are sure you know where you want to go, the trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Jim is not there but at another hotel.

2. The trip is proceeding smoothly but when you are halfway there things change completely - Jim rings to say he has gone in the opposite direction. There is a lot already invested in the trip so there is a reluctance to just abandon it and start again - after all that is the "waterfall" way of doing things.

3. The direct route is straight down the hill and over the old bridge. A much slower path is taken to mitigate the risks and so the customer always has the destination in sight. The quickest way would have been the direct route but was not seen as the "right" way to do it.

4. There are two equally good ways to the destination, via the north or south side of the mountain. However, the driver wants to go one way and the navigator the other. As a compromise they choose the worst possible way - right over the top of the mountain.


The advantage of the agile methodology is that the development team is happy since they are empowered not just to drive the taxi but to navigate and ensure that everything goes smoothly. The customer is happy because he knows the driver is not lost and, even if he is late, at every stage he knows where he is and still has a good idea when he will get there.

However, there are still potential problems to watch out for. One problem is a customer representative who does not really know what is best for the "real" customer (1). Agile methods are evolutionary but sometimes you can't evolve the existing software into what is really required (2). For a simple, well understood project "ad hoc" may still be better (3). Finally group decisions may not always be the best decisions (4).


Finally, I introduce a class of methodology that I have experienced but never seen described. In many ways it is like the agile methodology taken to the extreme. The customer is highly involved in the development and releases are not every few weeks but daily or even more often.

This typically occurs when the customer is a former taxi driver and wants complete control of the product and the process; hence I have called this methodology "totalitarian". An alternative name might be "back seat driver".


1. At every turn you (the passenger) check the roadmap and make suggestions or even tell the driver he is going the wrong way. The taxi driver has to stop and check to make sure but mainly to reassure the passenger.

2. With the constant barrage of instructions the driver becomes confused and even forgets where he is going. The immediate direction is constantly changing.

3. The driver stops thinking about where he is going and just follows your direction. You end up at the end of a dead-end one-way street.


This approach has no advantage over the agile and has many disadvantages. First, like the waterfall approach it disempowers the developers (2, 3), with consequent effects on their quality of work and hence productivity. There is no clear goal and no sense of accomplishment as there is at the end of each sprint in the agile approach.

It is also difficult to make any sort of significant change to a piece of software and keep it in a consistent state (1, 2). For this reason producing a new "release" should not be attempted more often than weekly. Developers need time to do their own testing and integrate input from different team members. Using this approach you can waste time chasing your own tail, by tracking down non-problems that would eventually "come out in the wash".

Further, the customer needs to do a lot of testing to provide daily feedback. Testing the same thing many times becomes tedious and eventually the customer becomes less diligent and bugs get past them.


Unfortunately when developing software there are many more variables and unknowns than in a simple taxi trip. In this strange world the Station Hotel may not be stationary hotel - it can move or even dispappear or there can be a myriad of hotels all seemingly the same. The roads may be unmapped and always changing.

I should also mention that there are things that can go wrong that are beyond the bounds of any development methodology - the Station Hotel may explode, who knows? There are car accidents and break downs.

I hope this article has given you insight into the different software development methodologies. In my next article I will look at the state of the art, in particular some agile methodologies. I will also emphasize what areas I believe are important and what the future may hold.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Andrew Phillips
Australia Australia
Andrew has a BSc (1983) from Sydney University in Computer Science and Mathematics. Andrew began programming professionally in C in 1984 and has since used many languages but mainly C, C++, and C#.

Andrew has a particular interest in STL, .Net, and Agile Development. He has written articles on STL for technical journals such as the C/C++ User's Journal.

In 1997 Andrew began using MFC and released the source code for a Windows binary file editor called HexEdit, which was downloaded more than 1 million times. From 2001 there was a shareware version of HexEdit (later called HexEdit Pro). HexEdit has been updated to uses the new MFC (based on BCG) and is once more open source.

You may also be interested in...


Comments and Discussions

QuestionExcellent article Pin
Rohith Krupal1-Mar-15 17:04
memberRohith Krupal1-Mar-15 17:04 
SuggestionNice! Still want more? Pin
Member 1104292328-Aug-14 3:01
memberMember 1104292328-Aug-14 3:01 
GeneralRe: Nice! Still want more? Pin
Edward Quixote4-Oct-14 0:31
professionalEdward Quixote4-Oct-14 0:31 
QuestionNice Article Pin
kiran pericherla28-Nov-13 17:13
memberkiran pericherla28-Nov-13 17:13 
GeneralMy vote of 5 Pin
AR54725-Nov-13 17:43
memberAR54725-Nov-13 17:43 
QuestionHi there Pin
DevAffair19-Jun-13 7:01
memberDevAffair19-Jun-13 7:01 
GeneralNice article Pin
nithyananthamn13-Jun-13 22:56
membernithyananthamn13-Jun-13 22:56 
QuestionYour article is so well written Pin
junkpraveen21-Mar-13 21:31
memberjunkpraveen21-Mar-13 21:31 
QuestionWow what a way to write the article Pin
junkpraveen21-Mar-13 21:29
memberjunkpraveen21-Mar-13 21:29 
GeneralMy vote of 5 Pin
anil720-Mar-13 6:16
memberanil720-Mar-13 6:16 
Questionplease response Pin
PAthanKp3-Nov-12 23:28
memberPAthanKp3-Nov-12 23:28 
AnswerRe: please response Pin
Andrew Phillips14-Nov-12 19:20
memberAndrew Phillips14-Nov-12 19:20 
QuestionIncremental model: Pin
sisadosizdah2-Jun-12 19:42
membersisadosizdah2-Jun-12 19:42 
QuestionMethodology defined Pin
sisadosizdah2-Jun-12 19:41
membersisadosizdah2-Jun-12 19:41 
AnswerRe: Methodology defined Pin
Andrew Phillips4-Jun-12 3:09
memberAndrew Phillips4-Jun-12 3:09 
Questionمدل افزایشی: Pin
sisadosizdah2-Jun-12 19:37
membersisadosizdah2-Jun-12 19:37 
QuestionThe second article Pin
zlatkostapic18-Apr-12 6:17
memberzlatkostapic18-Apr-12 6:17 
AnswerRe: The second article Pin
Andrew Phillips4-Jun-12 3:02
memberAndrew Phillips4-Jun-12 3:02 
QuestionTotalitarian? Pin
Juba26-Mar-12 17:29
memberJuba26-Mar-12 17:29 
AnswerRe: Totalitarian? Pin
Andrew Phillips29-Mar-12 21:00
memberAndrew Phillips29-Mar-12 21:00 
QuestionMore Stuff Pin
Andrew Phillips1-Feb-12 0:21
memberAndrew Phillips1-Feb-12 0:21 
GeneralMy vote of 5 Pin
Mohammad Nasim9-Dec-10 22:19
memberMohammad Nasim9-Dec-10 22:19 
Question[My vote of 2] A bit on the negative side? Pin
Silic0re094-Nov-10 3:19
memberSilic0re094-Nov-10 3:19 
AnswerRe: [My vote of 2] A bit on the negative side? Pin
AWdrius5-Nov-10 1:40
memberAWdrius5-Nov-10 1:40 
AnswerRe: [My vote of 2] A bit on the negative side? Pin
Andrew Phillips6-Nov-10 7:21
memberAndrew Phillips6-Nov-10 7:21 
I take your point that my article could be seen as negative as it mostly talks about the problems of the different approaches. (Perhaps I should have called them "challenges" instead of problems. Smile | :) Also thanks for your advice about adding a table of the advantages and disadvantages of each methodology, and I may add that to the next article (which I have yet to write).

However, I will say that, as mentioned in the introduction, this was a review of methodologies from an historical perspective. I tried to simply explain a methodology and the "challenges" it faces and how subsequent methodologies were created in response. Advantages of a methodology are implicit in that some problems from earlier methodologies are missing - eg Agile overcomes most of the 13 problems of Waterfall.

The real point of the article was, rather than try to give a simple formula to decide which methodology to use (which I don't think is possible), I tried to give the reader a feel for the dynamics of real world development under each of them.

I admit that the article has disadvantages in that it may take a bit more work on the part of the reader to understand the meaning of the analogies, but in doing so the reader hopefully attains a greater insight that allows him or her to make better decisions. Actually, my first draft did not even have the "Summary" sections, but I thought some of the subtleties of the numbered problems would be missed unless I explained the meaning of the analogies.

Finally, if you want advice, you will have to wait for my next article. As well as advice, I believe it will offer even more insight than this one. And I recommend giving this article a good score as incentive for me to complete the next one!
Andrew Phillips
andrew @

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170518.1 | Last Updated 4 Nov 2010
Article Copyright 2010 by Andrew Phillips
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid