Waterfall

The Myth of the Waterfall

There are many Software Development Lifecycles, but probably the most ubiquitous is the Waterfall Methodology.  I first encountered it as a young software engineer in the form of MIL-STD-2167A.  The waterfall method instructs you to develop a detailed requirements specification, followed by a design specification, and then on to software implementation, and testing.  This method is appropriate and necessary when you’re building big systems, especially when components are being sourced from multiple vendors.  But increasingly, this technique is causing software projects to fail.

The fundamental flaw in Waterfall is the myth that you know “the requirements” up front.  This is difficult in many industries, but in our industry; life sciences, it’s virtually impossible.  Scientists experiment.  They form a hypothesis, design an experimental method, capture data and make inferences about whether the data support or negate their original thesis.  And then they do it again.  They let real world experience guide future experiments.  We have adopted this technique when building scientific software and it has yielded terrific results and high affinity with our customers.  We call this technique Functional Prototyping.

But in order to build computer systems using this approach, you must trade “certainty” for “ambiguity”.  You must be comfortable proceeding without knowing exactly what you will build.  You must admit that you don’t “know” all the requirements. You must trust that, together with your customer, you will make the appropriate choices between functionality, organization impact, and cost.

At BioIT Solutions, we use functional prototyping as a requirements gathering tool.  We can rapidly configure a working prototype that captures or analyzes actual data.  The customer can “see and feel” the actual system in-situ. The “real requirements” are revealed with this “hands on” approach.

Contrast this with the typical waterfall project that expects the customer to read a requirements specification to determine completeness.  We have been “held hostage” by inappropriate, incomplete, or just plain wrong requirements once they have been approved in a requirements spec.  Even when the customer agrees they didn’t understand the document, we often needed slow, costly change orders to enact the desired change.

If you’re in the life sciences industry and have been underwhelmed by “Big Bang” software projects that have failed to deliver on their promises, you may want to examine the methodology, not just the technology.   You just might find the myth of the waterfall was the real culprit.

Image courtesy of FreeDigitalPhotos.net