Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.


    When to Rewrite


    One of the hard questions of an engineering manager is how to deal with technical debt, especially of the crippling variety.

    Three bad choices

    Do you throw out the existing product, and rewrite from scratch? Everybody who has tried that has learned painful lessons. Rewrites are always harder than you expect.

    Do you gradually refactor? That means fighting an inadequate product for a long time, painfully juggling old-style and new-style parts of the product, and perhaps not being able to excise all the unpleasant aspects of the old system (after all, the parts that bug yo uthe most are probably also the ones hardest to change).

    Or do you just throw in the towel, do nothing and continue with what you have? Which may sound like defeat, but much like a boxing trainer throwing the towel it may be the safest and best option, even though the outcome surely isn’t pretty.

    I’d like to use three different approaches to think this through with you, on a high level.

    Size, Severity, Schedule

    One way to look at it is that of thinking of the “Three S” of size, severity, and schedule – or, summed up: risk.

    Size: how much effort will it actually be to make that change?

    Severity: How bad will the impact of undertaking this effort be? Perhaps even the price of failure, of having to bail? And conversely, how great will the reward be once you get it done?

    Schedule: What will have to be postponed or skipped if you invest engineering capacity into repair work? How urgent is the change really (given that there’s always more than enough other stuff to do)?


    On the risk of angering acoountants with my superficial understanding of finances, you could also look at it this way:

    A rewrite is a large up-front investment: you buy a house. High risk, but potentially also high reward: once you’ve paid it off, you get to live the good life.

    A refactor is an iterative payment: you rent a house. Or maybe you buy it on a mortgage. Low or medium risk, but less impressive rewards. But hey, you get a house either way.

    Doing nothing is… staying in your tent prehaps? Tents can be pretty nice, and some people spend their entire lives in them; but in my experience tents tend to suck in a winter storm.

    An much better perspective

    We’ve framed this in the context of all-or-nothing. But maybe that exact perspective isn’t very helpful.

    Maybe you should really refactor your approach to refactoring.

    Instead of forging ahead, ignoring the consequences, you become more deliberate. You refactor your work as you go. You make it part of your daily practice, practice kaizen.

    Because… how did you get into this mess in the first place. If you don’t understand what led you to the place you’re in now, doing a rewrite won’t solve the actual problem. Yes, you’ll have stopped the bleeding. But the same kinds of debts will creep back.

    You’ve already made a mess. You should really close the faucet before you start mopping up the water on the floor.

    Once you’ve improved your practices there, pick a way of improving your product, and you’ll have a much higher chance of succeeding.