Comparison of the Waterfall Method and Extreme Programming
Page 1 of 9
Comparison of the Waterfall Method and
Extreme Programming
Brian C. Wheeler
ABSTRACT
In this paper I will discuss the creation of both the traditional Waterfall Model and the Extreme
Programming Model. Both are Systems Development Life Cycles that look at the way software is
developed and created differently in several key areas. I will compare and contrast the two, their faults
and benefits, why they were created, who they were created by and when one may be better to use over
the other. I will give my personal opinion on which of the two I think is better to use in a given situation
and my views on which I would choose to work with.
In the beginning there was nothing.
Then came software, but this was not enough, there was no organization, all was chaos. So spoke
the man “let there be the Systems Development Life Cycles” and Systems Development Life Cycles were
created. The man was pleased. People were content and the Traditional Methodologies were created and
software was developed. From this came the Waterfall Model.
Yet, nothing lasts forever.
People became discontent and there came a time when the traditional methods were no longer
viable. And so spoke another, “let there be Agile Methodologies”, and agile methodologies were created.
From this Extreme Programming was created and software was developed at a faster pace.
The time for change had come, but not all embraced this new philosophy, this new way of doing
things and so they clung to the old ways. This began the debate to decide which methodology was the
best, with each player picking sides to defend and expand their own methods to adapt to the ever
changing times.
It continues to this day.
Initially, software was developed haphazardly with no structure, numerous problems with
management and almost no organization. These caused serious problems in writing and releasing
programs for public and private use, which often resulted in broken and buggy if not unusable software.
The problems led to a rethinking and restructuring of how things were done.
In the 1970’s, Winston W. Royce published several books and articles on the development of
software and System Development Life Cycles. System Development Life Cycles or SDLC’s being a
series of steps and process’s that are followed in order to more efficiently develop software. In his works,
he described better practices for gathering information, managing a team and properly designing the
software for a given system. Though he did not coin the name “Waterfall model” or even back it as a fully
working methodology, he was the first person to describe a system like it. His works led to others
expanding upon his ideas and eventually developing the Waterfall Model that would become the standard
System Development Life Cycle for creating software at the time.
The name Waterfall Model originates from the way each phase of the System Development Life
Cycle flows from one into the next. As each phase is completed, the model can only move in one
direction like a waterfall and the next phase down can only be started when the current phase is complete.
The standard structure for the Waterfall Model is; requirements, analysis, design, implementation, testing
and maintenance as shown in Figure 1 below.
The benefits to using the Waterfall method are that it allows for everything to be well
documented and overseen. As everything is planned out and not changed randomly during the creation
process, keeping accurate records of all that is done becomes easy. This allows for anyone to pick up and
read over the documentation and become familiar with the software; how it works and so on. A well
organized and managed staff can gather all the requirements and begin analyzing and designing the
software quickly and easily which decreases the amount of effort needed before the actual software gets
written and tested. This results in a lower cost for the company to develop the software.
The Waterfall Model is also the best model for any aspiring Information Technology student or
system analyst to start with because they can gain an understanding of how a System Development Life
Cycle works and use this as a stepping stone to move on to or design their own.
The main problem with the Waterfall Model is its lack of flexibility. Once a phase is completed
and the next is started there is no possibility of returning to the previous phase. Unfortunately, this means
that there is only one opportunity to design, analyze and code the software. Since the Waterfall Model is
so rigid, any problems with input, output or any design flaws that exist will not be discovered until the
testing and maintenance phases are reached. This leaves the programmers and the IT team with only one
chance to fix any bugs in the code but not redesign the overall product.
Another flaw with the waterfall model is that it is very slow; often projects can take years to fully
develop before they are ever being released to the public or the companies that they are being developed
for. Each phase is done independently from any other phase with no overlap. So even if there was an
opportunity for the team to be split up and work on several phases at once to increase the speed at which
the project is completed the model by design does not allow for it, making periods where members of the
team could are inactive while they could be doing something constructive.
The slow speed of the Waterfall Model in an ever changing and rapidly evolving hardwired world
eventually led to the creation of other methodologies. Methodologies that are faster and more flexible
than there predecessor, they would come to be known as Agile Methodologies. With these new SDLC’s
in place the speed with which software could be designed, created and pushed out the door was greatly
increased.
One of the more dominate methodologies created during this time and used in today’s market is
called Extreme Programming. This Model stresses speed of development and shorter phases than the
traditional method and can produce software at a much faster rate.
Extreme programming was created by Kent Beck in 1996 while working on the C3 payroll
project for Chrysler. During his time with Chrysler he found that the team he was leading didn’t enjoy or
even use the traditional methods that were in place. So, he went on to look for and design a better way of
doing things to get his team more involved and like working on the software they were developing.
What Beck came up with was Extreme Programming, a model that is chaotic in design but is
organized in practice. Extreme Programming changed the way the SDLC was used entirely and threw
away the one phase cascade that the traditional methods relied on. His system stressed speed of creation
and constant communication during the project, everyone talked to everyone else. With this in place
programmers could go straight to the source, the customer, with any questions they had instead of through
management and the customer could change the design of the project as well as add or remove features at
any time during the SDLC. There was now a more cyclical way the software was created.
There are five phases to the model that break down into many different smaller phases which in
turn can be broken down and done in an iterative or cyclical way. The five rules the Model follows are;
planning, managing, designing, coding and testing. Figure 2 shows the basic model of the SDLC.
The benefits gained from using the Extreme Programming Model is that it is fast, very fast. The
model relies on teams of programmers releasing smaller bits of code that is then integrated into the final
product. Testing is doing constantly during these phases so any bugs that may exist are found long before
the final product is created and sent out. Communication is the key to Extreme Programming, as everyone
talks to each other at weekly planning meetings no one is left out of the loop of what stage the project is
in or what needs to be changed to suit the customers’ needs. The advantage this has over the Traditional
methods is that each person knows what stage the project is in, with the traditional methods there was
often only one person who knew the entire scope of the project and if something happened to them the
project would effectively be put at a standstill. Extreme Programming eliminates this problem; if one
person is out another can easily step in to pick up the slack.
The flaws with Extreme Programming are, unfortunately, a bi-product of the model itself.
Because of the speed that the software is developed, any features of the program that are non essential are
not programmed until the last minute, so not until the core features are ready and fully tested. This can
often lead to features being left out entirely if there just isn’t enough time to code and integrate them.
Another downfall is that with the customer being constantly involved with the project they can choose to
change any and all of the design of the software at any time, this can lead to entire weeks of coding being
scrapped and a complete redesign of the software, it can be bad enough that the team may have to start
over from scratch, though this is a worst case scenario and doesn’t often happen. With the iterative
movement from one phase to another and the constant release and testing of smaller program packages it
becomes challenging for even the most stalwart team to keep updated documentation of all the work that
is being done.
The decision to use one methodology over the other is still a little tricky to decide. As stated each
methodology has its own benefits and flaws and which to use really comes down to personal preference
on the part of the team leader and the team members themselves. The project that is being planned can
also heavily influence which method is used, if the team is on a timeline it may be best to choose to go
with the Extreme Programming model. If the team has no set release date and is working on a big project,
like a new operating system, that may take years to develop it would probably be a wise decision to use
the Waterfall model, as this will allow the team to completely gather all the information and other
requirements they may need and to fully design every essential and non-essential feature that will be
included in the final product before coding is even started.
Yet still each methodology, weather it is traditional or agile, fits a certain project and team better
than another. Sometimes trial and error can be the only way to decide which is best to use and let the team
become comfortable with a specific one, but once a team has chosen and adjusted to the methodology the
work will be easier and much more fulfilling for everyone involved. There quite a lot more methodologies
that exist today than the two I have discussed so choosing one can be quite tedious.
I would personally choose to go with a combination of both the Waterfall and Extreme
Programming methodologies to work with. The speed and team work of Extreme Programming combined
with the completeness of the Waterfall Model. Such a methodology may already exist or someone at
some time may come up with a new and better methodology to work with.
http://www.extremeprogramming.org/
http://ootips.org/xp.html
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.startvbdotnet.com/sdlc/sdlc.aspx
http://www.buzzle.com/articles/waterfall-model-it-project-management-solutions.html