mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-22 15:21:55 +00:00
65 lines
4.3 KiB
HTML
65 lines
4.3 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<title>Handbook Troggle Kill it with Fire</title>
|
|
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
|
</head>
|
|
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
|
|
<h2 id="tophead">CUCC Expedition Handbook</h2>
|
|
<h1>Troggle - Kill it with Fire</h1>
|
|
|
|
<p>This is a book: <em>Kill It With Fire: Managing Aging Computer Systems (And Future Proof Modern Ones)</em>
|
|
<p>Read the brief reviews:
|
|
<a href="https://www.amazon.co.uk/Kill-Fire-Manage-Computer-Systems/dp/1718501188">
|
|
<img border="1" class="onright" width="150px" src='../i/killitwithfire.jpg' alt='book cover image'/></a>
|
|
|
|
<ul>
|
|
<li>on <a href="https://nostarch.com/kill-it-fire">No Starch Press</a>
|
|
<li>on <a href="https://www.amazon.co.uk/Kill-Fire-Manage-Computer-Systems/dp/1718501188">Amazon.co.uk</a>
|
|
<li>on <a href="https://www.goodreads.com/book/show/54716655-kill-it-with-fire">Goodreads</a>
|
|
</ul>
|
|
<p>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:
|
|
|
|
<ul style="list-style-type:square; line-height:115%; padding-left: 20px;">
|
|
<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>Always discover why previous modernisations failed <em>first</em>.
|
|
<li>Spend a lot of time <em>problem setting</em> before you start to think about <em>problem solving</em>.
|
|
<li>Working through a major modernisation is all about managing <em>scope</em>.
|
|
<li>Code is much easier to write than it is to read. Modernisation means a lot of <em>code reading</em>.
|
|
<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.
|
|
</ul>
|
|
|
|
<p>The book was published in March 2021.
|
|
<h3>Refactoring</h3>
|
|
<p>So how do we repair old code? By <a href="https://refactoring.com/catalog/">refactoring</a>. I use the first edition of Fowler's book rather than the 2nd. And Brett Slatkin's <a href="https://effectivepython.com/">Effective Python</a> (second edition) is absolutely invaluable.
|
|
<br>
|
|
<hr />
|
|
Return to: <a href="trogintro.html">Troggle intro</a><br />
|
|
Return to: <a href="trognotes.html">Troggle Programming Guide</a><br />
|
|
Troggle index:
|
|
<a href="trogindex.html">Index of all troggle documents</a><br /><hr />
|
|
</body>
|
|
</html>
|