How Not to Need to Kill it with Fire

Over the holidays, I tried to do a bit of professional reading to keep my mind fresh and help me be a bit more productive with some work that I’m currently doing. To this end, I read Marianne Bellotti’s Kill it with Fire: Managing Aging Computer Systems (and Future Proof Modern Ones).

I’m not sure what I expected, but I got much more. The book provides excellent case studies, tips, and history to keep everything grounded in modernizing computer systems. This is a critical skill in a world where any time we walk in a new door, we may see infrastructure and codebases between fifty years and five minutes old. Bellotti gives tools for both the technological and strategy and the critical parts of building team morale and driving stakeholder buy-in on modernization projects. 

One of the book’s first points is that technological development is highly cyclical and that if you wait long enough (or live long enough), the wheel always returns to the same ideas. The critical thing to remember is that those ideas never recombine in the same ways. Hence, modernization efforts are complicated even when the ideas rhyme, much less when they’re on opposite sides of the pendulum swing. This is increasingly an important realization, as the nature of cloud computing can appear deceptively similar to older ideas of shared compute, such as mainframes and minicomputers that we are often modernizing today. Still, all of the supporting technologies and ideas are so very different.

The book continues into the almost eternal conversation about “why modernize and why is it so risky?” One of the points made throughout the book is that technological modernization should only happen when it makes business sense, not simply because there is a new technique available. There is a tendency among so many engineers and developers to try to perfect every problem, even the ones that are already solved. So often, when these kinds of technology modernizations are divorced from the business, it leads to failures. Many times, these are not just failures of the project but the underlying tools that the organization had come to rely on, causing disruptions and outages. Bellotti reminds us, “[a]dopting new practices doesn’t necessarily make technology better, but doing so almost always makes technology more complicated, and more complicated technology is hard to maintain and ultimately more prone to failure.” These failures are damaging, not only for the organization, but for the reputation of IT, as memories of broken promises, downtime, and loss of functionality last far longer than delivered problems and months, years, or decades with minimal downtime.

Other discussions of use are on how to deal with technical debt, how to migrate to a services architecture, and handling performance issues. Each of these topics is covered from a strategic and business perspective, including the “why” of each and how to recognize when that is the problem. There are also techniques for breaking these problems down into incremental development as used in a modern development process – that also is easier for the business to understand.

Finally, a large chunk of the book approaches what to do when, as a leader, you gain a modernization project in progress and how to go about dealing with the many common problems that crop up inside a failing modernization process. This section is instrumental in identifying ways to avoid the typical “spiraling” issues that occur when a poorly executed or planned modernization program starts to go off the rails.

This book is excellent, and I’d recommend it to anyone who has to deal with or touch legacy systems, and by that, I mean any system that’s already in production.