This is something that seems to come up time and time again in software engineering, and something I’ve been thinking about a lot this week. When a system is struggling, slowing down, or otherwise giving you and your team headaches, all too often the solution teams reach for is to tear it down and start again from the beginning. In almost every scenario I’ve seen this, hindsight has shown it to be a big mistake.

I totally understand the desire to build again, the sales pitch is easy: “we can do everything we can do now and more, that we can release faster and that uses all the latest and greatest technologies – our customers will love it”. I’ve even fallen into this trap more times than once. Inevitably though, it takes longer than you expect, you end up with a small percentage of your original product feature capabilities, and many of your processes haven’t gotten any faster. Often the existing system keeps causing you so many problems you never truly get to focus on the new one, leaving you with two services that aren’t fit for purpose.

There are, of course, cases where building again can be the right choice, but so often my experience shows that critically reviewing what you currently have, looking not at the code and the pipelines, but internally at you and your team, reveals more about the headaches you’re experiencing.

Perhaps you aren’t refactoring as you go. Perhaps tech debt (I prefer the term product debt) is getting out of hand. Perhaps you haven’t been keeping your dependencies up to date and they’re introducing critical security issues. In these scenarios replacing the code and technologies rarely helps in the long run. It’s a bit like buying a brand new car, treating it badly for a couple of years and having constant issues with it, and thinking that just buying a new car is going to solve all your problems. It will for a short while, but if you don’t change your approach, you’ll be back at square one in another couple of years.

Instead, taking time to plot a course to get yourself out of that hole, to develop that maintenance and stewardship mindset in yourself and your team, and to bring the best of your existing system along with you, will likely get you to a much better position, and in a way that you can practically support into the future.

I have lots more (currently unstructured) thoughts on this, likely worth a full blog post at some point, but for now – tell me your stories (good and bad!) of rebuilding software from the ground up, I’d love to hear them @chrishutchinson.

This past couple of weeks I’ve been playing Civilization V with a couple of friends. I stumbled over this podcast – Civ Stories – in which the hosts tell stories of games that have gone on late into the evening, and all too often have had absurd or ridiculous outcomes. Playing Civ again has been fun, although I am fairly awful at it for the time being. Practice makes perfect they say!