The process used at a certain company consists of:

  1. Create a layout according to some designs made in a web page design tool. (CSS, html)
  2. Requirements come in with "functional requirements". These consist of 100's of lines of business directions. E.G. Create a Table on page X. Column1 has numeric data. Column1 is the client code. Column2 is a string...etc.

  3. Write code to meet all functional requirements.

  4. When all code is checked in, send to QA (which is the BA that wrote the requirements) for inspection, bug finds and change requests.
  5. Punt back to developer with a list of X bugs and Y change requests.
  6. While bug finds or change requests > 0 go to step 4.

The agile development environments I have worked in allow, if not demand, early QA inspection and early user acceptance. So, pieces of the program can be refined and redefined before the entire application is in place.

Not only that, but the process leaves little room for error or people changing their minds. Instead, those "change requests" come in at the last stage when they do the most damage. And being that a bug-fix's cost increases over time, this is a costly way to write code.

I am no waterfall expert. As described, is this waterfall being mishandled in some way? How does waterfall address my concerns?

  • waterfall is an anti-pattern, it is mishandled as a matter of course .
    – user7519
    Nov 21, 2011 at 20:24
  • 5
    @JarrodRoberson Waterfall is only an anti-pattern when there is a giant brick wall between BA and DEV and requirements are just thrown over the wall and finished software just flys back over after a pre-determined period of time. When continual feedback between BA's DEV and QA occur throughout the development phase then it can and does work effectively for fixed price, set deadline projects.
    – maple_shaft
    Nov 21, 2011 at 20:41
  • @maple_shaft - Nice breakdown. That is in fact what occurs here. So, it is being mishandled in this way. Nov 21, 2011 at 20:44

3 Answers 3


The use of the Waterfall methodology, as it is described on the Wikipedia article, on any project of significant scale, is a risky endeavour. In the commonly taught waterfall methodology, testing happens at the very end. There is no discussion (that I am aware of, anyway) of verification or validation happening prior to the "testing" phase. However, the commonly taught Waterfall method is an example of how not to build software systems, and comes from a paper by Winston Royce, where it is described as:

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

Figure 10 in the paper I linked to is Royce's proposed model of software development, which explicitly includes requirements, design, and implementation reviews. I would suspect that a quality assurance team would be involved in these reviews, to some extent. And in addition to involving quality assurance, the customer is even involved (as appropriate) in the development process at all phases, which is contrary to the Waterfall model traditionally taught.

Now, plan-driven methodologies (like Royce's proposed methodology) are not wrong or bad, when used in the appropriate instances. For example, in a project with volatile requirements, they aren't the best option, and it sounds like this is your case. So yes, when you don't know for sure what you need to build or change is likely, using a plan-driven methodology is costly for the reasons maple_shaft wrote in his answer.

  • I think it's worth pointing out (yet again) that Royce's paper was the first known reference to waterfall methodology, and even there it was given as an example of how not to do things. IOW, the waterfall was invented purely as a straw man from day 1. Yes, people have had general ideas along that line at times, but there's not a generally-accepted definition of how it should be practiced, because from the very beginning, the idea was that it should not be practiced at all. Nov 21, 2011 at 21:42
  • 4
    @Jerry Coffin: It would be a straw man if it wasn't actually practiced. Unfortunately, I've been on waterfall or near-waterfall projects, and I suspect a lot of the rest of us have too. Back in the 80s, I was at a place that used PRIDE methodology, in which everything had its ordained place in order, and the director separated the systems analysts from the programmers. Nov 21, 2011 at 22:06
  • @David: I agree, I don't think it is at all accurate to call that depiction of the waterfall a "straw man", because it is practiced exactly as described, even in the present day. Nov 21, 2011 at 22:31
  • 2
    @Carson Even though it's practiced, it was never supposed to be. The intention was to be a straw man, identifying the key activities in a software project. I'm not sure where the disconnect happened, between Royce's paper and people practicing a model that was known to be flawed for well-identified reasons.
    – Thomas Owens
    Nov 21, 2011 at 23:06

This seems pretty true to the traditional Waterfall methodology and you already mentioned a significant drawback of Waterfall in that the relative cost of a bug or missed requirement exponentially increases over the course of the project:

Relative Cost of Requirements Errors

The way to minimize this in Waterfall development is to provide regular status updates with BA/QA throughout the course of the project so if they see something going astray then they can call it out earlier before it has a chance of being a bug or missed requirement later in the SDLC.

  • 2
    But, but, but... Agile methodologies don't fit nicely with MS Project or all of my PMI training. Wahhh!
    – JohnFx
    Nov 21, 2011 at 20:44
  • @JohnFx If I had a dollar for everytime I heard a PM whine about this, I would use the money to fund a startup that would outcompete the slow expensive bloatware put out by the company the PM works for and put them out of business. :)
    – maple_shaft
    Nov 21, 2011 at 20:48
  • 2
    It's sort of like claiming a board is broken because the hammer can't saw through it and make a nice straight line.
    – JohnFx
    Nov 21, 2011 at 21:02

Perhaps giving a simple yes/no is the desired answer for this question, but I just can't do it.

The thing about Waterfall is that it looks great on paper but almost never manages to match with the reality of human behavior.

You allude to having some familiarity with Agile, and you point out issues occuring from people changing their minds, so I assume you have some familiarity with this problem. Software development is not similar enough to bridge-building to proceed in a nice, orderly fashion from Step 1 to Step 2 to Step 3. We learn more as we go, customers' ideas grow and mature, priorities change.

So given that, I'll say theoretically yes, according to the rigid and often impractical process outlined by Waterfall, code is complete before going to test. In reality, though, this often just doesn't work and leads to much gnashing of teeth.

  • +1 - The last paragraph sums up the problems we currently face. Developers are expected to have written code that meets the assumptions made by the BA. Unfortunately, differing opinions, points of view, human error, etc. lead to a nearly guaranteed "failure". The whole idea of saying you can write up a program on paper that does not yet exist is absurd. There's always a need for an iterative correctional process at the end, that is akin to agile. Just, way more expensive and unaccounted for in the paradigm and the project cost analysis. Nov 21, 2011 at 20:30
  • +1: yep, this is what really happens. Apparently, considering a feature incomplete (i.e. not code complete) and considering it a bug (i.e. you are code complete) is a very gray area.
    – DXM
    Nov 21, 2011 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.