The Worst Way to Develop Software

In software development, differentiating between good and bad ideas is critical. "There is no right way to do the wrong thing." Despite this, one of the most criticized concepts still in use is the waterfall model. Although widely recognized as flawed, it remains the default methodology for some organizations, often without them realizing it.

What makes the waterfall model so problematic? Why is it still so widely adopted, despite its evident shortcomings?

Simply put, there are no cases where the waterfall model is the best choice for software development. It's unsuitable for regulated industries, doesn't enhance safety in critical systems, and doesn't adapt well to product development at scale. Organizations known for successful software products avoid this approach. The waterfall model, burdened by bureaucracy, often leads to subpar results, expensive rework, is risky, and invites failure.

Read more…

This doesn't mean software can't be built using this approach, but success rates are much lower. Many still rely on the waterfall model because it provides an illusion of control and progress. Its linear nature might suggest steady progress, but it often leads to significant rework and delayed feedback.

In software terms, the waterfall model refers to a linear process that involves distinct phases: planning, design, development, testing, and deployment. The concept emerged in the 1950s, but it gained popularity from a 1970 paper by Winston Royce, featuring a diagram that describes these sequential steps.

Interestingly, Royce intended this diagram as a straw man, using it to highlight the weaknesses of the waterfall approach. He pointed out that this model is prone to risks, often leads to rework, and increases the likelihood of failure. However, the waterfall model gained traction, possibly because many people only skimmed his paper and didn't understand his critique.

Royce's original proposal leaned more toward bureaucracy than agility, but it included elements that align with modern agile practices, such as incorporating testing throughout the development process.

Despite early criticisms of the waterfall model, it remains a common approach in many software projects.

Although many organizations claim they don't use it, they often follow a rigid, step-by-step process that leaves testing until the very end, echoing the waterfall's structure.

To determine if your development process is waterfall-like, consider how it responds to unexpected changes. Can your team easily adjust requirements? Are you able to adapt plans if priorities shift? How efficiently can you identify and address errors? Are you able to deliver fully working tested software frequently every couple of weeks and obtain customer feedback? The waterfall model typically lacks the flexibility to handle these dynamics.

Modern Agile Software Development approaches, on the other hand, offer a more adaptable approach to deal with uncertainty. They promote flexibility, allowing teams to pivot quickly and when needed. This focus on continuous improvement and early and often feedback on actual working tested software, reduced defects, minimizes rework and avoids delays. While agile is now the favored approach with 90% industry adoption, traces of the waterfall mindset can persist, often showing up as resistance to change and bureaucratic hurdles.

Summary

Ultimately, agility and flexibility are essential because they encourage innovation, reduce the risk of rework, and create a development environment that's responsive to change and conducive to innovation required to survive and thrive in today's VUCA world.