How to Break the Software Rewrite Cycle

About this Presentation

Despite our best efforts with Agile best practices – CI, unit testing, design reviews, code reviews – every few years we end up rewriting our software.

This talk is about my personal experiences with project failure, improvement failure, patterns across the industry, and the key lessons that were critical to success. I had a great team. We were disciplined with best practices and spent tons of time working on improvements. Yet still, I watched my team slam into a brick wall. We brought down production three times in a row, then couldn't ship again for another year.

We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn't solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way.

When I started consulting, I saw the same patterns across the industry:

Our problems are invisible. They're hard to measure, hard to explain. We rely primary on gut feel to make improvement decisions, and it's really easy to make improvements that don't make much difference.

The relentless business pressure never lets up, and developers don't have control. Without visibility, management makes ill-informed decisions, train-wrecks our projects, and drives the development team to exhaustion.

I turned the lessons I learned into the Idea Flow Learning Framework, a data-driven feedback loop for guiding improvements. By quantifying the impact of disruptions, test maintenance, confusing code, and collaboration problems, we can find our biggest problems, understand the causes, and align our development priorities with leadership.