Fix it or build it again? This is how I make that call

This is a decision I make daily. Not as some grand strategic weighing with a meeting attached, but simply while I am working. Something is sitting there that needs changing, and the question is whether I reshape the existing piece or put down a new one.

In the vast majority of cases it turns into a refactor. That may sound dull, but it is the logical outcome of something that was put together well from the start: when the foundation is right, adjusting is all that is required. You move a wall, you do not demolish the house.

When building again is the smarter move

Sometimes a change simply does not fit what is there. Not because the code is bad, but because it was built around an assumption that no longer holds. At that point you can keep pushing and pulling, with more and more exceptions and detours, or you accept that this particular part has reached the end of its life.

Note the word part. Building again almost never means the whole application in my work. It means you take out one bounded piece and put it back new, while the rest keeps running. A full rebuild of a system that has grown over years is a project you disappear into for months, and during all of it you help no customer at all.

What decides it

The question is not whether something can be fixed. Almost anything can be fixed, given enough time. The question is which route comes out cheaper.

So I put them side by side. What does it cost to pull this apart and build it back up properly? And what does it cost to write this piece from scratch, including everything around it that has to be tested again? If the second sum comes out lower, I build it again. If it comes out higher, I leave the structure alone and adjust what is there.

What I explicitly do not do is throw something away because it is not beautiful. Every system contains code that is not the best I have seen and that does its job without trouble. I leave that alone. Business value comes first, not my feelings about tidy code.

How to do that sum without being a developer

You obviously cannot calculate those two amounts yourself. What you can do is ask the questions the sum follows from.

Ask how much of the existing work survives a rebuild of this one part. If the answer is that everything around it stays the same and only this piece gets replaced, the damage is manageable. Ask as well what can break on the side you are not touching. A part that has its fingers in everything is more expensive to replace than a part with one clear connection, even when they are the same size.

And ask what happens if you do nothing. Sometimes that is a perfectly good answer. Not every annoyance is a problem you have to solve now, and a list of irritations is a different thing from a list of costs.

An example from my own company

At Altrady we got stuck on our customer support system. It did what it was supposed to do, but we were not happy with it, and that feeling did not go away. In the end we built it from scratch. It works a lot better now.

What I find interesting about that project is the timeline. From first idea to delivered took about two months. The actual build work was about two weeks, and that was done alongside the regular work, as a side project.

The six weeks in between were not waiting time. During them the developers went and handled support tickets themselves. Not looking over someone’s shoulder, not sitting through a demo, but genuinely working those tickets. That gave them a feel for the flow, showed them where the real problem sat, and only after that did they design the solution.

Without that month of handling tickets we would have built a new version of the same problem in two weeks.

That is the part people skip. Building again feels like a technical decision, so attention goes to the technology. But the reason the previous version disappointed was not that the code was wrong. It was that nobody knew exactly where it chafed in daily use. If you do not work that out first, you rebuild the same mismatch, only in neater code.

What this means for you

If you are sitting with an app that does not do what you want, the first question is not whether it can be saved. The first question is where exactly it goes wrong, and for whom.

Sometimes that turns out to be one screen where everybody gets stuck, and a targeted change is all you need. Sometimes it turns out the thing was built for a process you now run differently, and then no repair will help. You only see that difference by looking at the code and at daily practice at the same time. Both, not one of the two.

And if the outcome is that part of it has to be rebuilt, that is not a disaster. It is a bounded piece of work with a price and an end point. My experience is that it is often smaller than people fear, as long as you know what you are building before you start.

Running into this? Send me a message and we will work out where your app actually stands and what the cheapest way forward is.