CUCC Expedition Handbook

Troggle - Kill it with Fire

This is a book: Kill It With Fire: Managing Aging Computer Systems (And Future Proof Modern Ones)

Read the brief reviews:

• on No Starch Press
• on Amazon.co.uk
• on Goodreads

About a third of the book is about management and doing repair/rewrite inside large organisations, but nearly half of it is directly relevant to us:

• Consider iteration in place as the default approach.
• Beware of artificial consistency as proposed to "improve" technical value.
• 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.
• Previous modernization efforts may have left behind serious scar tissue which you need to consider.
• Many people try to fix things which are not, in fact, broken. Don't optimise beyond diminishing returns.
• Modernization needs momentum to finish the job: don't take on risks without also producing compelling value.
• Decisions made to avoid rewriting the new code later are usually bad decisions.
• The only thing worse than attempting to fix the wrong thing is leaving the fix attempt unfinished.
• Site reliability expressed as uptime percentages is rarely the real issue.
• Speed of recovery after failure is always more important than you think.
• A perfect record of no failures can always be broken, but resilience is an accomplishment that lasts.
• Know when to run a systemic Code Yellow hackathon and when not to.
• Always discover why previous modernisations failed first.
• Spend a lot of time problem setting before you start to think about problem solving.
• Working through a major modernisation is all about managing scope.
• Code is much easier to write than it is to read. Modernisaton means a lot of code reading.
• 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.
• Success does not come all at once. What are the progressive success criteria during the reengineering?
• Use Diagnosis, Policy, Actions where there is little consensus about what success looks like.
• Use bullet journalling to maintain your own morale during a re-engineering project.
• When a failure is user input, fail gracefully with helpful message.
• When a failure is due to a programming or specification bug, fail hard and fast.
• Build simple, performant systems before you start on the bells and whistles.
• Prioritise simple code running fast early, so that you can iterate fast.
• An existing system is not a reliable specification for the proposed new system. Important behaviour will be implicit, not documented.

The book was published in March 2021.

Refactoring

So how do we repair old code? By refactoring. I use the first edition of Fowler's book rather than the 2nd. And Brett Slatkin's Effective Python (second edition) is absolutely invaluable.