<li>Consider <em>iteration in place</em> as the default approach.
<li>Beware of <em>artificial consistency</em> as proposed to "improve" technical value.
<li>Don't assume that what you can't see is simple to replace: there may be years of effort hiding considerable complexity which appears simple on the surface.
<li>Previous modernization efforts may have left behind serious scar tissue which you need to consider.
<li>Many people try to fix things which are not, in fact, broken. Don't optimise beyond diminishing returns.
<li>Modernization needs momentum to finish the job: don't take on risks without also producing compelling value.
<li>Decisions made to <em>avoid rewriting the new code later</em> are usually bad decisions.
<li>The only thing worse than attempting to fix the wrong thing is leaving the fix attempt unfinished.
<li>Site reliability expressed as uptime percentages is rarely the real issue.
<li>Speed of recovery after failure is always more important than you think.
<li>A perfect record of no failures can always be broken, but resilience is an accomplishment that lasts.
<li>Know when to run a systemic Code Yellow hackathon and when not to.
<li>Human beings are absolutely terrible at estimating probabilities and risk. We always under-estimate the amount of work in a rewrite and over-estimate the likelihood of success.
<li>Success does not come all at once. What are the <em>progressive success criteria</em> during the reengineering?
<li>Use <em>Diagnosis, Policy, Actions</em> where there is little consensus about what success looks like.
<li>Use <em>bullet journalling</em> to maintain your own morale during a re-engineering project.
<li>When a failure is <em>user input</em>, fail gracefully with helpful message.
<li>When a failure is due to <em>a programming or specification bug</em>, fail hard and fast.
<li>Build simple, <em>performant</em> systems before you start on the bells and whistles.
<li>Prioritise simple code running fast early, so that you can iterate fast.
<li>An existing system is <em>not</em> a reliable specification for the proposed new system. Important behaviour will be implicit, not documented.
<p>So how do we repair old code? By <ahref="https://refactoring.com/catalog/">refactoring</a>. I use the first edition of Fowler's book rather than the 2nd. And Brett Slatkin's <ahref="https://effectivepython.com/">Effective Python</a> (second edition) is absolutely invaluable.
