If it ain’t broke, don’t fix it. Or, what?

When I promised to write about how to reduce friction from developers’ work day, I am sure that most expected me to focus on what non-developers ought to do in order to improve the working lives of developers.

But let’s face it, the major cause of friction, crappy legacy code, is our own fault. Developers wrote that crappy code, after all. So let’s focus on what we can do about that.

Software developers have a natural tendency to keep the hands off code that already works. After all, conventional wisdom tells us that it is a bad idea to try to fix something that works.

Such conventional wisdom often makes a lot of sense, even in the world of software development; any change involves an element of risk, and you surely do not want to risk introducing bugs unless you need to.

On the other hand, we need to think about the risk of not changing code. This risk is often overlooked, so I was happy that Martin Fowler in a recent article on the second edition of his Refactoring book reminded us that he was impressed while working with Kent Beck because,

[…]one thing that really stood out was they [sic] approach he took to continually reworking the code base to keep it healthy[…]

I strongly suggest that serious software developers dig into the wisdom of those two gurus (Martin Fowler and Kent Beck) in order to understand why code which is not continually trimmed will actually rot.

In my humble opinion, there are numerous reasons for constantly trimming code. For example, new requirements cause existing code to get in the way of changes, or as time goes by you get wiser on the underlying problem you are trying to solve. In short: When you get wiser, use that wisdom to continually improve your code.

If you don’t continually trim your code, if you postpone needed refactoring too long, then you end up with unmanageable code that you wish you could rewrite from scratch. Rewriting from scratch might be the only feasible option, but you will probably nevertheless have to focus your time elsewhere.

Don’t get me wrong here. I have written code which still runs unchanged after many years without needing a change. In the rare cases when this happen, don’t change the code just for the sake of a principle.

Still, in conclusion, even when code works, if the way the code is crafted is no longer good enough, you really should change it.