New Year's Resolutions Won't Fix Bad Code

This is the time of year when many of us start planning New Year’s resolutions.

We feel that we could lose some weight, we could be fitter, and we could do more to improve ourselves. A few days of idleness and indulgence has made us feel restless, a little more guilty than usual, and ready for a change. The turning of the year feels like the right time to make that change.

So we make vows that this time - this time - we will change our ways. We will join that gym, enter that diet programme or enrol in that course.

The only problem is that New Year’s resolutions don’t usually work. There’s been lots of research done about why they don’t work, and how we can make them more effective (for example, Richard Wiseman’s Quirkology site has a characteristically interesting and entertaining article: https://www.richardwiseman.com/quirkology/new/USA/Experiment_resolution.shtml). However, while this research can be helpful, we don’t really need it to tell us that New Year’s resolutions don’t usually work: we’ve always known that. New Year’s resolutions are often the punchline to a bad joke, a list of things that we know that we won’t be doing by February.

It’s clear that, although we make them every year, New Year’s resolutions are not a good way to break bad habits.

I believe that the same is true of software: software gets out of shape, just like we do, and it doesn’t get back into shape through resolutions that we don’t keep.

Whether we call them legacy systems, heritage systems, or simply the-systems-we-implemented-last-year-in-a-bit-of-a-rush, we know that, as soon as most systems are implemented, they start to show some of the same behaviour we show when we get out of shape. They become a bit slow. They get a bit stuck in their ways. They become harder to change.

This is not an inevitable characteristic of software. Good software does not go bad on its own: good software will run forever unless we change it or unless we change the environment that it is operating in. But much software does not start out as good software, and much good software is turned into bad software when it is changed without care (or without the time and effort which care requires).

There are many people more qualified than me to explain the difference between good software and bad software, but it’s important to realise that good software is not just software that works: it’s software that is also easy to change and easy to understand. And, despite advances in automation, testing, code analysis and practices such as Pair Programming, making software easy to change and easy to understand is still hard to test for, hard to measure and, just like our waistlines at Christmas, hard to keep under control.

This is one of the main reasons that older systems have such a bad name, and why people want to move away from them. Although legacy system transformation is often expressed as a desire for new technology, or for accelerated innovation, in practice it is often really a desire to get away from code which has been changed so many times that no-one understands how it works any more.

The problem is that, too often, plans to transform legacy systems are like New Year’s resolutions. We feel that we are not agile enough, we feel stale, we feel that we have gone too long without major improvement. We worry that we are being left behind. So we make a vow that, this time - this time - we are going to make a big change. We are going to attempt that audacious rewrite! We’re going to buy that package! We’re going to create that innovation team and give them complete freedom!

Just like New Year’s resolutions, these are all good intentions, but unless we go about them in the right way, we will end up with the equivalent of the unused gym membership in February; except that the price will normally be higher than a gym membership, and it will normally take us quite a bit longer to realise that we haven’t achieved the six pack that we were hoping for. Programmes to transform legacy systems often start strongly and face fast when we realise just how hard they are, or, if they get to end, cross the finishing line is such a rush that the code going in is no better than the code coming out.

What’s the answer then? It’s not to go on living with being out of shape, or to go on living with bad code.

I believe that, just as with New Year’s resolutions, there are only two ways that work.

First, if we’re going to make that radical change, we need to commit. If we’re going to join a gym or take a course, we have to turn up. And if we’re going to do that, we have to be absolutely sure about our motivations. Are we joining the gym because, deep down, we believe that the gesture is more important that the outcome? Or are we joining the gym because we are committed to becoming the sort of person that goes to the gym regularly? Are we prepared to make it part of our lives? Similarly, are we launching a legacy transformation project because we’ve lived with this system for years and we don’t really know what to do about it? Or are launching a transformation project, because we’re committed to transformation, of our business models, of our products and processes as well as our systems? Is this who we are going to be now?

Second, we can change our habits in modest but sustainable ways. We can eat slightly smaller portions at every meal. We can build some regular exercise into our routine. We can run that code analysis check, and act on the results. We can do proper code reviews for readability as well as for function and feature. We can measure ourselves on code maintainability. These changes may seem much easier than committing to a big transformation programme and they are - each time we do them. The trick is to keep doing them, not just in January, and not just in February, but forever.

While both of these way are hard, they can both work: the important thing is to be clear about which one of them suits us right now. Do we really need to embark on a giant programme? Or do we just need to do a few small things better every day from now and forever?

New Year’s resolutions are an expression of intent: an intention to get better. We just need to listen to that intent, make sure that we are serious about fulfilling it, and use our design brains to design ways to make it come true.