Software Development Life Cycle Series: The Waterfall Model

It all started with a big bang

  • Little to no downtime, as downtime meant you were blind to the skies
  • Extremely reliable as false alerts would be as catastrophic as real alerts
  • Centralized command to prevent renegade attacks against the Soviet Union
  • Information needed to be reported in real time so the response was immediate

Managing complexity

In 1956 Herbert D. Benington presented a paper at the Symposium on Advanced Programming Methods for Digital computers describing a model used at MIT’s Lincoln Laboratory to produce software in a very structured manner.

Plan or Die

Today, society puts innate trust in computer systems but in the 1950s computers didn’t have such privilege. The norm was for computers to be down for weeks or months, so having a computer with 100% up-time seemed like mission: impossible.

Plan->Code->Test->Release

The operational plan defines the broad design requirements of the system. This is used as the basis for the machine specification and operational specification. The operational specification is from the user’s point of view and treats the entire system as a black box with the only concern being how the user interacts with the system.

Documentation: an important by-product of software

In addition to testing, Benington noted that “documentation of the system program is an immense, expensive job” and even simple changes have ripple effects, as many different documents may need to have their changes coordinated.

The process gets a name

The waterfall method solidified more in the 1970s through a paper by Dr. Winston Royce where he described his personal views about managing large software projects and gave the first example of the process we’re more familiar with today.

Software development goes mainstream

The waterfall method was doctrine for developing software in the 20th century. It works well in a world of clearly defined stable goals. Since development moves through defined stages it’s easy to communicate across a large enterprise which stage everyone is in.

Failures using the Waterfall Model

  • Unrealistic or unarticulated project goals
  • Inaccurate estimates of needed resources
  • Badly defined system requirements
  • Poor reporting of the project’s status
  • Unmanaged risks
  • Poor communication among customers, developers, and users
  • Use of immature technology
  • Inability to handle the project’s complexity
  • Sloppy development practices
  • Poor project management
  • Stakeholder politics
  • Commercial pressures
  • Working software isn’t produced until late in the lifecycle
  • It doesn’t easily allow for new requirements or scope adjustments
  • People are bad at estimating large projects
  • Technical or business bottlenecks aren’t identified early

The Internet Arrives: Move Fast and Break Things

While competition is always fierce and moving fast is always an advantage over your competitors, it was never the deciding factor in gaining market share. In fact, Microsoft was late to the browser wars but was able to use it’s OS dominance to crush Netscape Navigator.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Niarcas Jeffrey

Niarcas Jeffrey

I write about managing software teams and building software products through human-centered and agile processes.