When To Overhaul? (Day 435)

Time to market is important, and building quickly will incur technical-debts. After a year or two of quick feature deliveries, a platform could become hard to maintain and fragile--easy to break and slow to build new features.

But overhauling the entire architecture is costly. All the time spent in rewriting is the time lost from building new features. Huge opportunity cost. How do we decide when should we pull the trigger?

This could be solvable by a weighted decision tree. But usually it is simpler. When a system is fragile, there will be hard to solve bugs, and cost company money. There will also likely require longer times to add new features, and lots of regression tests needed for each new release. When that additional cost and time added up more than the overhead of rewriting the whole thing, it's the time to pull the trigger.

Of course, there are other concerns need to be factored in, such as the company's funding situation, available developer resources, etc.

The bigger question sometimes is that how do you make the non-engineering team understand the need of overhauling? This is a question I have yet to find a good answer to.