Mainframe Blog

I Don’t Do New Year’s Resolutions—That’s Waterfall

2 minute read
Mark Schettenhelm

Overview: What if, instead of resolving to make one big change on New Year’s Eve, you made minor changes, evaluated them and modified your approach as the year progressed? The same applies to building software.


This time of year, talk turns to resolutions. Something about the end of the year makes us want to prepare for the next.

But how confident are you that your resolutions will hold up? I ask because many people resolve to make big improvements once a year and quickly break those resolutions—even the day after.

For this reason, I gave up New Year’s resolutions, but I’m still committed to continuously improving. This is true in my own life and in software development. Let me explain.

Missing Big Targets

To me, the tradition of making New Year’s resolutions is very much like traditional mainframe Waterfall development: You plan your enhancements—in this case resolutions—and deliver them only once a year.

You’ve spent the year with whatever behavior it is, but only now do you intend to change it, and drastically—right now! In effect, you’ve wasted months waiting until now to make a change when you could have been gradually working on it day-by-day and without so much pressure. Now that the focus is on, you decide to go big, and it rarely works out the way it’s intended to.

Constantly judging against the one big goal you want to meet makes it much easier to toss in the towel and quit. The goal is too large. It’s a binary thing where you either do the whole goal or nothing. There’s a better approach.

Attaining Small Goals

What if, instead, as the year progressed, you made minor changes and evaluated them each time? You could find out what works and what doesn’t, then modify your approach for the next few weeks.

You would do this with the idea that the “deliverable” each few weeks isn’t the end goal—it’s progress toward the end goal. You would go for smaller, attainable steps that continuously build into something closer to where you want to be.

Most importantly, as the year progressed you could incrementally benefit by building on successes and learning from errors. The amount of pressure you would be under would be much less.

Setting Incremental Software Goals

If this makes sense for self-improvement, it can also make sense for your mainframe software projects. The psychology behind it is the same: Instead of continuing to set up large, binary, pass/fail projects with far-out dates that only build up the pressure you’re already under, it would be better to start on the project now and make incremental improvements with greater quality, velocity, and efficiency.

Break the project into smaller goals that can be met in short time frames, such as with two-week sprints, and deliver the benefits along the way. As problems are found, adjust and move on. You want a clear goal you can meet soon. That’s more motivating than staring at a huge, far-off goal.

Meeting these small goals is what we call continuous improvement, a hallmark of Agile Development. It’s a simple idea, and there is no better time than the present to start. So, if you’re going to make a resolution, make it that you will start using the incremental power of Agile.

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

BMC Bring the A-Game

From core to cloud to edge, BMC delivers the software and services that enable nearly 10,000 global customers, including 84% of the Forbes Global 100, to thrive in their ongoing evolution to an Autonomous Digital Enterprise.
Learn more about BMC ›

About the author

Mark Schettenhelm

Senior Product Manager for BMC Compuware ISPW, Mark has more than 35 years of experience in the IT industry. In his 30+ years with Compuware, Mark has been instrumental in helping to bring mainframe solutions to the forefront of the industry.