Mainframe Blog

Why the Waterfall Development Methodology Has a Very Apt Name

Dream Falls
3 minute read
Mark Schettenhelm

How often do you use terms or phrases without really examining what they mean? I thought of this recently when considering what it means to develop and deliver applications using the “Waterfall” development methodology.

If you work in mainframe IT, you’ve probably been familiar with the Waterfall development methodology for a long time because it’s what your team has always worked with. In examining the terminology deeper, however, I realized just how great a name Waterfall is for what it represents—though what it represents really isn’t that great at all.

The Risks of Dropping Down a Waterfall

Consider a natural waterfall. Being from Michigan, I picture the Tahquamenon Falls (above), but you probably picture another large waterfall or group of them, like Niagara Falls.

What you have is water heading inevitably towards a cliff. If you were to think about going down the waterfall, you would want to plan and prepare. This has been attempted with mixed success using barrels to go over Niagara Falls.

You have to plan for all possibilities when you’re dropping 165 feet in a barrel: it’s a project with a definite deadline—once you’re in the water moving towards the drop-off, that’s it—and potentially serious consequences. What if your planning doesn’t support the outcome you expect? That is, to live. You only have one shot.

This is why we call the Waterfall development methodology what we call it. It’s trying to plan and prepare for all the possibilities that could occur once you drop your project over the cliff a year or more out from the project start date, hoping it makes a big splash and keeps floating—hoping your barrel doesn’t splinter into pieces.

And when things do work out, you can’t escape the reality of having spent countless hours planning for consequences that never occurred—time you could have invested in development and innovation instead.

The Benefits of Moving to Agile Rapids

What if you could break your year-long project with the Waterfall development methodology into a series of 12 shorter, monthly drops? This is what we call Agile development, and it would probably make you feel better about your project thanks to its shorter periods of planning that mitigate risk because they let you see ahead and plan for upcoming obstacles or the next drop.

When you’re rafting down rapids as opposed to dropping down a massive waterfall in a barrel, even if you make a mistake and get dumped out, you have a life jacket to keep you afloat and you can get back in. You will have learned your lesson, you will be able to move on and move forward, and the consequences will be much less painful and impactful on your project.

Taking this further, what if you made the drops even more frequent but shorter? This would be like going from Class III to Class I rapids, where the water is even smoother, where you can really move around, be nimble, find mistakes sooner and cut risk. Rather than dropping month-to-month, you would be developing in Agile two-week sprints, where the flow is much smoother, much faster, and the drops shallower.

The benefits of ditching the Waterfall development methodology and making more frequent, iterative code drops using Agile Development on the mainframe are easy to realize once you’re doing it. But getting there is harder than it looks. Read the BMC AMI DevX E-book “Ten Steps to True Mainframe Agility” to learn how you can take the right steps.

When you use the Waterfall development methodology, try to really consider what it represents and not just go through the motions because it’s the status quo. Do you really want to continue to plunge over dangerous cliffs, or would you rather manage more frequent but far-shorter drops?

Access the 2023 Mainframe Report

The results of the 18th annual BMC Mainframe Survey are in, and the state of the mainframe remains strong. Overall perception of the mainframe is positive, as is the outlook for future growth on the platform, with workloads growing and investment in new technologies and processes increasing.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

Business, Faster than Humanly Possible

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

Mark Schettenhelm

Mark is a DevOps Evangelist and Lead Product Manager at BMC who has experience working with developers around the world in Source Control Management, Testing, DevOps and Application Portfolio Analysis. He is a frequent conference speaker, webinar presenter, blogger, and columnist, often explaining the benefits of bringing Agile and DevOps to mainframe development and encouraging development teams to adopt new methodologies and continuously improve.

His writing has appeared in Enterprise Executive and Enterprise Tech Journal and he is a frequent contributor to and SHARE Tech Watch. Mark is currently the Lead Product Manager for BMC products in Source Control Management, Deploy, Code and Fault Analysis.