Move Fast and Fix Things
I&#x27;ll highlight something I&#x27;ve learned in both succeeding and failing at this metric: When rewriting something, you should generally strive for a <i>drop-in</i> replacement that does the same thing, in some cases, even matching bug-for-bug, or, as in the article, taking a <i>very close look</i> at the new vs. the old bugs.<p>It&#x27;s tempting to throw away the old thing and write a brand new bright shiny thing with a new API and a new data models and generally NEW ALL THE THINGS!, but that is a high-risk approach that is usually without correspondingly high payoffs. The closer you can get to drop-in replacement, the happier you will be. You can then separate the risks of deployment vs. the new shiny features&#x2F;bug fixes you want to deploy, and since risks tend to multiply rather than add, anything you can do to cut risks into two halves is still almost always a big win even if the &quot;total risk&quot; is still in some sense the same.<p>Took me a lot of years to learn this. (Currently paying for the fact that I just sorta failed to do a correct drop-in replacement because I was drop-in replacing a system with no test coverage, official semantics, or even necessarily agreement by all consumers what it was and how it works, let alone how it <i>should</i> work.)