Waterfall Methodology 101: the Pros and Cons

As a child, did you arrange your Legos by color and size, then map out each of your projects in minute detail before you connected the first two blocks? Plan. Order. Execute.

If you are drawn to this type of thinking, waterfall methodology may be an appealing way for you to approach software development.

The centerpiece of waterfall methodology is a Software Development Life Cycle (SDLC) plan that, in ideal circumstances, should move like stacked dominoes, mapping a well-planned, limited-interaction, linear approach that progresses to the next phase only when the current phase has been completed and approved. Midstream changes are minimal. Development moves through the process one step at a time and typically looks something like this:

Advantages of Waterfall Methodology

Waterfall methodology’s advantages lie in its structured approach:

  • Since all — or most — functional and design requirements must be agreed upon before coding begins, surprises that affect timelines and/or budget are less likely.
  • Testing and production documentation, such as use cases and user guides, can be written in parallel with the code.
  • Adequate documentation limits possible communication failure points and makes transferring project knowledge easier.
  • The highly structured process yields concrete milestones for management and the client to track.
  • Little client involvement is required, except in the beginning, again limiting possible communication failure points.
  • User interface may be improved by the fact that early design requirements that will affect user experience will have undergone troubleshooting and resolution prior to coding.

Disadvantages of Waterfall Methodology

The same structured approach affords waterfall methodology two main disadvantages:

  • Project requirements must be clearly defined at the beginning of the project. If the requirements aren’t clearly defined, or if they change along the way, the developer descends into change-order purgatory, with a dissatisfied client in tow. For waterfall to flow easily, the client must have very clearly defined requirements that won’t change along the way.
  • Waterfall methodology features minimal client interaction with the ongoing project. If your client wants to be involved at every step and often makes changes, using waterfall can increase client frustration and diminish your chances of success. The sequential nature of waterfall and the isolation inherent in the method keep the developer and the client apart until the finished product is produced. For hands-on clients, this lack of interaction can be unsettling. And for clients wracked with uncertainty, not seeing the final product until it’s … well, final, can be painful.

When to Use Waterfall Methodology

Waterfall methodology works well under these circumstances:

  • When the client’s desires are clearly defined at the project start, and you feel confident that the agreed-upon requirements will result in an acceptable final product.
  • When the client wants a defined schedule and budget from the beginning.
  • If the client will be minimally involved in the development process.
  • If team members are numerous or will change often. (Waterfall methodology offers uncomplicated knowledge transfer for smoother progress in the face of personnel changes.)

When you get to pick a method, opt for waterfall if the previous statements are true — and if all the shirts in your closet are grouped by color and face the same way.

Share your (very logical and well-ordered!) thoughts on the value of waterfall methodology in the comments section.