Introduction
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.
Ad-hoc
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.
Problems
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.
Summary
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.
Waterfall
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.
Problems
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.)
Summary
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.
Prototype
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.
Problems
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.
Summary
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).
4GL
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.
Problems
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.
Summary
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).
Iterative
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.
Agile
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.
Problems
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.
Summary
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).
Totalitarian
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".
Problems
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.
Summary
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.
Conclusion
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.
