[elygre]

I notice that on your “one side”, you have the cost of the rebuild — but not the “projected cost of keeping this thing and maintaining it”.

That’s a common fallacy of programming: the existing code is convoluted and hard ti maintain, but the new code I would replace it with will be much better and much cheaper to maintain.

[djbusby]

Yea, they(we) always say the new code will be better. Yet, eventually the new code becomes the old code and the cycle repeats.

Assumptions and Environment change. New becomes old. And old has maintenance cost.

[usrbinbash]

That's a very good point you make there, and I should have mentioned that in my post.

Yes, the cost of the rebuild itself, PLUS it's own maintenance, fit with the rest of the codebase, extensibility and so on, must be considered in that equation.

I glanced over that, because usually the rationale for a good rebuild is an improvement regarding exactly these metrics.

[kmoser]

In addition to projected cost to maintain, there is also the potential ill will you are continuing to generate with your customers if the existing buggy/legacy system affects them. Your reputation with your customers matters. This is one of the biggest factors I see companies ignore all the time.

[XorNot]

Conversely...in a lot of cases you can reasonably project it's likely you won't be maintaining it. So what you're really projecting is how much trouble you expect to save yourself for your forseeable remaining time at the company.