Quick Fixes versus Careful Rewriting

Posted by Neil Ludlow on Monday, 15th December 2025

Time to read: 4 minutes

In software development, there are pros and cons to everything. I try to explain this to people I work with, to varying degrees of success. I tend to be on the cautious side because I don't like software that breaks, especially if it appears that I am the one who has broken it.

This is a scenario that is all too common. It is completely understandable, but also it is preventable. If you enjoy the thrill and exhilaration of breaking some software and feeling the cold sweat and time pressure, stop reading now. However, if you like sleeping at night and making calm, rational decisions, read on.

The Scenario

A piece of software has been built by others, maybe it was an agency, maybe by your brother-in-law who is a plasterer but does some coding on the side. It's full of bugs, and the code is a mess, but it basically works. Now, your brother-in-law is busy with his plastering, or you've moved on from the agency.

What do you do?

One Common Strategy

You think all it needs is some bugs fixing and some new functionality adding, which should be quick and cheap. You already paid for it to be built, you don't want to repeat that whole process.

Let's change as little code as possible to fix all the bugs and add the new parts. After all, everything is there, and it works to a degree. Re-building anything from scratch will just take extra time and expense that isn't needed.

The Outcome

If someone is only fixing one tiny bug at a time, and the whole codebase may well be a mess, you often get unintended consequences. You might fix a minor bug, but then it turns out fixing that one bug has broken something else in another part of the project.

In software this is called a regression. Regressions happen because the person who has changed a piece of code wasn't thinking about what other parts of the software might be using that code.

Regressions thrive in environments where changes just need to be made ASAP. Considering all the things that would be affected by the code takes time and slows things down.

"Don't think, code!"

Discussion

If it's software you've built yourself you might understand how to fix it from the off. You might make the nicest, cleanest, most readable code in the world. Changes are quick and easy!

If it's software that is made by someone else that has been assembled by people that either don't know what they're doing or are just trying to get it built quickly the code can be a mess. Parts of the code that shouldn't be connected are connected, no-one knows why. Parts of the code do things that no-one understands.

• Do you work with the code the way it is and just try to tinker around the edges with fixes and additions?
• Do you try to improve the code so that it is more understandable and better for people to work on?

Both are valid, but what you should understand is the quality of the underlying code. An existing project is like a building, if it's falling apart, and you're trying to add something on top of an uneven mess, you should know that at the outset. However, if the structure of the building is sound, in that case yes you can make additions in safety.

In the past, certainly when I started out, a lot of code was "inline" with no structure. This led to very messy code that was often harder to fix, there was often a lot of repetition and even lots of different languages in the same file. But, with this kind of code, if you changed one file, other files did not tend to be affected. That's not to say code was better in the past, it wasn't, more that styles have changed with the times and something that worked in the past may no longer work now.

With modern software, it's still possible to create messy code, but also if you use a framework you can sometimes rely too heavily on that framework. This can lead to tight coupling, which can lead to these kinds of regressions.

"Tight coupling" describes a situation where different parts of the software are so closely linked that changing one often breaks another. You can call the whole software that has been built in this way as "fragile" or "brittle".

I was listening to "The Pragmatic Programmer" book recently. In the book they talked about an acronym in software development I hadn't heard before... ETC (Easy To Change). They were saying that we as software developers should be making software that is easy to change.

But, if some software has not been carefully crafted so as to be easy to change, or even easy to read, it becomes brittle and regressions happen.

Conclusion: Understand What You're Asking For

Quick Fixes vs careful rewriting is the comparison I'm trying to make here. It's not normally as simple as I have this much money and I want something written ASAP. If the code is well-written, maybe it can be added to fairly quickly, but even then you're risking turning the nice code into a patchwork quilt. And, if the code has not been well-written you're just asking for trouble.

Today's quick fix can be tomorrow's headache. Saving money today may be costing money tomorrow.

Before asking for a quick fix, it's worth asking whether the code is actually safe to change - and trusting someone who can answer that honestly.

.

Image of an old-fashioned alarm clock on a modern desk next to a laptop by Jan Vasek

.

About This Series

This article is part of the Client Survival Guide, a series designed to help business owners and entrepreneurs cut through the jargon and make smarter decisions when working with developers or agencies.

If you'd like guidance on bridging the gap between the technical and non-technical sides of your business, feel free to reach out - this is exactly where I help clients find clarity and confidence.