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

A good read with relevant case studies. Food for thought for any systems developer or architect.

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 maintaining long-lived science and voluntary data management projects: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.

I think there’s a lot of wisdom behind these ideas but as a manager and tech lead of small team in a small company (< 50) I found these ideas too abstract.

The book was a little difficult to read as it felt that the author was jumping between different topics. It slowly becomes clear how the topics are related. This is one of those books where a re-read becomes necessary.That said, the subject material is very valuable as it is driven from real world stories. All these stories are contextual but there is enough diversity here so that at least one of these would be helpful in your case, as long as it is about managing a complex and large software system.Despite the difficulty, it is a must-read book.

I had the pleasure of working with Ms. Bellotti on an ageing computer system just like in the book. To this day I'm grateful for the opportunity to work with such talented folks. Ms. Bellotti was their lead on the project. Her book reminds me of the hard work that went into modernizing an aging infrastructure. I think this is a must read for Government IT leadership. I highly recommend reading the book and taking those lessons to heart.

De los mejore. libros de gestión técnica que ha leído últimamente. No os dejéis engañar por el título, va mucho más allá de la gestióo de sitsemas legacy. Los consejor, historias y ejemplos que la autora recopila y explica sirven para cualquier proyecto, incluso para los que todavía son demasiado jóvenes como para haber creado legacy. Un gran libro, que merece estar siempre al alcance para consulta y relectura.

Despite the flashy title, this book does not urge to throw away “legacy code” but does a great job of dispelling the myths around it. Projects touching old systems may need some special treatment - uncovering lost context, finding people with niche technology skills - but in general they should be run like… other projects :) Define measurable goals, iterate on successes, keep the team’s momentum going and you should be fine. Also, don’t forget to maintain the code afterwards, lest it devolve to “legacy” again.Bonus points for clear distinction between “legacy” and “tech debt”, for noticing how old and new technologies can be basically the same, and for showing the similarities between software systems and organizations going further than just invoking Conway’s law. The author’s background is anthropology which I find very fitting. After all, all problems are human problems, legacy code no less so.The book is not overly technical - it does not delve into code, architectural problems are drawn roughly - but really, that’s not a problem at all. There are other titles on restructuring code or refactoring to patterns, software engineers surely know them already. Marianne Bellotti offers insights on a higher level, reminding us that all decisions should be driven by your project’s context. In other words, consciously choose what you optimize for and stick to it unless the feedback suggests otherwise. I probably just sounded awfully vague, but believe me, the book has much more substance than what I am trying to portrait.Why am I taking one star off? Politics :) To my taste, the author suggests a tad too much of manipulating the perception of risk or urgency to keep a project going. Still, it is a great read for engineers and managers alike. Who knows, maybe it will help save your legacy system?

It's easy to see the author's fascination with anthropology, and while it brings interesting perspectives to software engineering, the book does not offer many practical insights.