The misunderstood word - Waterfall
Unpacking the myths and realities of what Waterfall is or is not
What comes to mind when you hear the word "Waterfall" today? For many, it conjures images of rigidity, inefficiency, or outdated methods. It's often thrown around as a buzzword for lousy project management. But this is an oversimplification and, frankly, a misrepresentation of what Waterfall was meant to be.
Waterfall, back in the day, made perfect sense. It wasn’t created to be the villain of modern software development; it was designed to solve the unique challenges of its time. So how did it go from being a sensible methodology to a term often vilified or misunderstood? Let’s explore.
My own journey in technology began with studying COBOL on mainframes and used punch cards. Fortunately, I only learnt it and never worked on a production system with punch cards. And yes, it was a pain doing assignments.
A Glimpse Into the Past
Back in the early days of programming, the landscape was vastly different.
Mainframes were prohibitively expensive, and most businesses couldn’t afford a dedicated environment for development or testing. There were no IDEs, compilers, or debuggers. Testing wasn’t iterative; it was a manual process of walking through the code on paper. The stakes were high, and if your code failed, it didn’t just cause frustration; it could halt an entire business operation.
We did not have the luxury of changing things quickly like we can today. Say you spot an error in code today. You simply edit it, recompile, and commit your code—a quick few minutes. A change like that may have taken days to make. Changing requirements often meant starting again as it was a new program.
What Waterfall Really Was
Waterfall wasn’t about being inflexible. It was about managing risk. Winston W. Royce's seminal 1970 paper, "Managing the Development of Large Software Systems," show the process commonly used:
System Requirements - Defined the overall objectives and constraints for the entire system, especially when it came to hardware and processing power. This was often documented on paper and involved lengthy reviews by stakeholders, as changes were costly due to the physical nature of mainframe resources. Missteps here led to cascading problems due to very limited hardware capacity and expense of new hardware.
Software Requirements—We broke down the system requirements into specific software functionalities. Requirements were often handwritten or typed, with minimal room for iteration due to the nature of how software was built. Misunderstandings could cause incorrect applications to be built and logically put in the wrong places, resulting in starting again.
Analysis - Translated software requirements into structured logic, often represented by flowcharts or diagrams drawn by hand or typed. This stage provided detailed input for design and required people to test the logic, flow, and interactions manually. This testing was done on paper with flow diagram.
Program Design - Detailed the architecture and program flow, specifying how the system would function and how it started. This included creating step-by-step logic for coding, often outlined on paper before translating to punch cards. Significant manual verification was needed here.
Coding – By the time it got to coding, the flow diagrams, logic and structure were well articulated and manually tested (on paper). Now it was a matter of translating that into code. This was typically done on a typewriter. Significant manual walking through the code was done, imaging debugging on paper and keeping track of all variables manually. Once successful, the code was put onto punch cards, one line of code per card using a keypunch machine.
Testing (Live) - Involved running batch jobs on the mainframe to verify program logic. Debugging was manual and relied on printed logs or core dumps to identify issues, a tedious and painful process.
Operations – Making it available to users, training them as computing was new to most people. Not as easy is we have it today.
Each phase had to be perfect because moving back was almost impossible. The technology and business constraints of the era shaped Waterfall, not some innate desire to lock teams into rigid processes. It made perfect sense back then as it was a risk mitigation strategy that made sense for the technology of that era.
Why Waterfall is Misunderstood Today
The world has moved on. Technology has advanced beyond recognition. We now have:
Local PCs with immense processing power
IDEs that highlight errors as you type
Automation, Build Pipelines, Continuous Deliver and Release
Cloud environments that allow instant provisioning
Tons of reusable libraries, many freely available
Multiple people working on the codebase at the same time
These innovations have eliminated the constraints that once justified Waterfall. Yet, the term has stuck around—often misunderstood and misapplied. People use it to describe inefficiency or resistance to change, ignoring the context that made Waterfall necessary in its time.
I was writing some code yesterday and refactored something in a few minutes, committed it to the repo, and a few minutes later, all tests were done, and it was in production. That change would have taken several weeks with multiple people involved back in the day. That is iterative and incremental.
The Real Problem: Misusing Waterfall’s Legacy
Today, the biggest issue isn’t Waterfall itself but the outdated mindset of applying it in a world where it no longer fits. The idea of locking in all requirements upfront and building in large, isolated phases is as outdated as punch cards. Modern tools and practices enable rapid feedback, iterative delivery, and continuous improvement.
However, some teams still cling to Waterfall-like behaviours. They push everything through exhaustive analysis and design phases, attempting to “get it right the first time” while ignoring the benefits of working iteratively. This isn’t Waterfall; it’s just bad project management.
There’s No Need to Get it Right the First Time
The technology today is vastly different from that of the early mainframe days. The risks faced back then, when Waterfall made sense, are no longer valid today. Instead, we face different challenges, and technology no longer constrains us as it once did.
We don’t need to build it once and get it right the first time. We can adopt an iterative and incremental model, breaking big products into manageable stages or phases (also known as short iterations). This approach fundamentally changes the risk dynamic, allowing for pragmatic and active risk management.
By working iteratively, leaders can pivot quickly if things are headed in the wrong direction. Feedback loops provide real-world insights early in the process, enabling teams to adapt and evolve their solutions. There’s no need to cling to the outdated notion of perfection on the first attempt. It’s time to embrace a more dynamic and responsive way of working.
The biggest misunderstanding on Royce’s paper “Managing the Development of Large Software Systems” is that many people incorrectly assume he coined the term waterfall; he did not. Royce critiques the single-pass sequential approach, describing it as "risky and invites failure," and instead advocates for an iterative process involving customer feedback and multiple development cycles. That was in 1970, yet 55 years later, people still attempt to build software in a single-pass and get it right.
Let’s Stop Misusing the Term
The term “Waterfall” deserves better than to be a shorthand for outdated or ineffective practices. It had its time and place and served its purpose well. But the world has changed, and so must our approach to development.
As for a “hybrid” approach, waterfall versus iterative and incremental development are mutually exclusive. You either build in multiple iterations or build in one attempt, and there is no “hybrid” or impossible to do both.
Next time you hear someone criticise “Waterfall,” ask what they mean. Are they talking about legacy processes that no longer fit, or are they simply using the term as a scapegoat for deeper issues? Let’s be clear about what we mean and focus on building better ways of working.
If you found this post insightful, I’d love to hear your thoughts. Let’s spark a conversation about what really works in today’s fast-paced climate.
That's a great reminder Brett! Thank you for sharing your thoughts.