5. Software dev-methods comparison, Macadamian - Ani Karapetyan
Confidential 10/7/2013 1
AGILE TOUR YEREVAN
05, October, 2013
Software Developer, PSM
Scope of the presentation
Software methodologies are concerned with the process
of creating software - not so much the technical side but
the organizational aspects.
This whole presentation is one big analogy.
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 hotel, can clarify
Historically, the first methodology was basically no
methodology at all. This is generally called the "ad hoc"
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
In this analogy you are the "customer" and the taxi driver is
Let’s Consider these variations
The ideal case:
customer knows where he wants to go
developer knows how to get there
A few minutes later you arrive at your destination safely
and without wasting any time!
Unfortunately the real world is never this simple.
Taxi driver misheard you and you end up at the train
"Which one?“ There are three within a ten mile radius.
The destination is quite distant and you do not have
The taxi takes you straight to the hotel but it's closed for
Jim calls your mobile and says that he has gone to a
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 then there is a good chance of success.
The above scenarios represent several common
problems seen in software development:
customer doesn't know exactly what they want
Let’s try to avoid all the mentioned problems
You find that you need an "analyst" to work out where you really
want to go and a "designer" to provide detailed instructions on how
to get there.
The essential point of the specification is to have the trip completely
and thoroughly planned before starting out.
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 want feedback that once you start the trip everything will
stay on track.
The taxi driver has to read and understand the whole
specification before starting out.
There are a few small ambiguities in the specification
and taxi driver makes a wrong assumption.
Unexpected events that nobody could have anticipated -
a major accident that causes traffic chaos or some
Things that you (the customer) forgot to mention - you
need to stop at the bank to get some cash on the way.
The taxi driver becomes annoyed and frustrated with the
process. "Just tell me where you want to go!“
The project estimate is one hour. But the taxi driver
thinks it will take half that time (he knows a shortcut) and
starts to take care of some personal business. In the
end he makes a huge effort and only arrives 20 minutes
You contact Jim and arrange to meet him at a nearby
hotel which is actually more convenient for both of
you. This completely invalidates the specification.
The main problem with the waterfall approach is that it
takes a lot of up front effort in planning, analysis and
The model can work if everything goes to plan, but in a
complex project things rarely do. For example:
1. difficulty of understanding and following the spec
2. getting them right in the first place
3. process does not cope with change
4. process doesn’t make best use of
developers(they may procrastinate at the start)
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.
For example, start our journey immediately by taking 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.
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.
The quickest way would have been the direct route but
was not seen as the "right" way to do it.
There are two equally good ways to the destination, but
they choose the worst possible way.
Development team is happy since they are empowered
not just to drive the taxi but to ensure that everything
Customer is happy since he knows the driver is not lost
and, even if he is late, he knows where he is and has a
good idea when he will get there.
Sometimes you can't evolve the existing software into
what is really required.
Group decisions may not always be the best decisions.