Kill It with Fire chronicles the challenges of dealing with aging computer systems, along with sound modernization strategies.
How to survive a legacy apocalypse
“Kill it with fire,” the typical first reaction to a legacy system falling into obsolescence, is a knee-jerk approach that often burns through tons of money and time only to result in a less efficient solution. This book offers a far more forgiving modernization framework, laying out smart value-add strategies and proven techniques that work equally well for ancient systems and brand-new ones.
Renowned for restoring some of the world’s oldest, messiest computer networks to operational excellence, software engineering expert Marianne Bellotti distills key lessons and insights from her experience into practical, research-backed guidance to help you determine when and how to modernize. With witty, engaging prose, Bellotti explains why new doesn’t always mean better, weaving in illuminating case studies and anecdotes from her work in the field.
You’ll
Packed with resources, exercises, and flexible frameworks for organizations of all ages and sizes, Kill It with Fire will give you a vested interest in your technology’s future.
A business book that's actually not a waste of time. Excerpts: ---- "We build our computer systems the way we build our cities: over time, without a plan, on top of ruins" — Ellen Ullman ---- The [cloud] serverless model will feed its consumers more and more development along its most appealing features until the edge cases where serverless approaches don’t quite fit start to find common ground among each other. Then a new product will come out that will address those needs. ---- One can track how architectural paradigms fall in and out of favor roughly by whether processing power and storage capacity are growing faster than network speeds; however, faster processors are often a component of what telecoms use to boost their network speeds. This kind of inter-dependency is true for basically any market. Product development shifts consumer behavior, which shifts product development. Technology doesn’t advance in a straight line, because a straight line is not actually efficient. The economy is not a flat plane, but a rich topography with ridges and valleys to navigate around. ---- If you've never restored from a backup, you don’t actually have backups. If you’ve never failed over to another region, you don't actually have failovers. If you've never rolled back a deploy, you don’t have a mature deploy pipeline. ---- working groups relax organizational boundaries while committees reinforce them. ----
One of the unfortunate facts about computer systems is that there is far more legacy code than their is modern code. Systems are built in layers of stanky hacks on stanky hacks, temporary fixes made ages ago in obsolete languages and paradigms where the original developers have long departed and the original context has been forgotten. To share one of my own stories, I had a process fail a third of the time, because it was (my) contemporary Python calling a .NET framework which was emulating an IBM 3270 terminal to connect to a mainframe called The Core, and somewhere in there the ability to handle lower case letters got lost. "Kill it with fire" is both the title of the book, and most developer's reaction to being asked to work with legacy systems, but in the real world we can't reach for the napalm. We have to find a way to live with creaky systems.
IBM 3270, the finest in modern human-computer interaction peripherals
Bellotti is trained as an anthropologist and has worked on both major open source projects like OAuth and with the United States Digital Service, and her advice is an extension of the dictum that computers are programmed and used by human beings.
This has a few major implications. The first one is that a successful modernization is one which minimizes disruptions to existing users. Try to fit within existing mental models and interfaces, while swapping out parts of a system which are causing unacceptable delays.
The second implication is that while there is no single best architecture, there are patterns which developers like to work on. Mostly whatever is new and trendy, or systems of abstraction rather than specific use cases. If people are rewarded for shipping new code, they'll ship code and won't focus on maintenance. Social rewards are more powerful than organizational rewards.
The third implication is that what makes legacy systems hard isn't bad technology, but bad management. Migrating a complex system, with lots of stakeholders, under and undocumented features, and even bugs that have become features, is an exercise in frustration. Leadership had to build morale and keep momentum up by focusing on alignment and productive questions that free the people doing the work to do the work, rather than run in circles on firedrills.
I'd have preferred a few more war stories and specific technical traps to be aware of, but this is definitely an interesting and useful book.
Great collection of heuristics for anyone looking to embark on a "software modernization" track.
This book does not discuss technical aspects in detail but rather focuses on all other organizatorial aspects: avoiding "hype-driven" rewrites, how to get started with a modernization effort, team structure and dynamics during a modernization, maintaining focus and motivation, etc.
The final chapter on "how to future-proof" is short and to the point: make your systems easy to modernize, make an effort to evolve them gradually instead of waiting on a time bomb.
I also particularly loved the introductory chapter "time is a flat circle" that takes a look at how the pendulum of technology has swung back and forth in the last couple of decades.
"Legacy system" tends to be used as a derogatory term in our field. This book offers perspective on why they deserve to be treated with a bit more respect. The closing sentences really wrap it up nicely:
"Working on legacy systems means working on some of the most critical systems that exist [...] This is not the work of technical janitors, but battlefield surgeons".
Good dive-in into history with a set of tools, and approaches to handle legacy systems.
I didn't know about the "yellow code" approach from Google to address systematic issues. I didn't know about the leap second problem although being more than 10 years in the industry. I didn't know so many systems have messed up storing time.
The author’s ideas didn’t feel well organized, and her writing style was very dry. My eyes were permanently glazed over no matter how hard I tried to focus.
This book makes me happy and frightened at the same time. I see much of this happening in different sectors, and it seems like very few people (other than this author) have actually thought about what they're doing.
Wow, a truly phenomenal book about large software modernization projects. I read the entire book in a single sitting as a PDF on my desktop (which I was not expecting). Bellotti takes what many might consider a dry topic and brings in interesting anecdotes from history, along with relevant perspectives from seemingly unrelated disciplines like sociology, behavioral economics, systems thinking, and more. The book provides not only high level frameworks for thinking about these types of problems in the abstract, but it also offers pragmatic & prescriptive advice for solving problems based on differing contexts. The book is well structured, and written in an accessible style. I'd also call out that this book is not limited to a technical audience. While software managers/engineers/TPMs will definitely enjoy & get value out of it, I think this book is just as important (if not more important) for product managers, executives, or any other non-technical audience involved with executing product strategy.
I read this start to finish in one sitting. As someone who spent the past 9 months working to modernize a business critical legacy system this was both spot-on and insightful. Bellotti does a great job of highlighting and expounding what I also saw: the biggest challenge with modernization projects are people problems, not tech problems.
My only regret, certainly influenced by my recent experience, was that she only briefly touched on celebrating wins. I found that one of the initial momentum killers in our modernization project was that when we accomplished milestones, that win wasn't acknowledged, celebrated, or communicated to the org. That caused the work to feel thankless. Once we started recognizing and celebrating wins we started building momentum.
“Kill It with Fire” exceeded my expectations. I initially anticipated a boots-on-the-ground review of technical debt handling. What I've got instead was almost everything but that.
The book has changed the way I think about technical debt and how to communicate it upwards. It provides sound advice on various topics, including how to fight tech debt, schedule maintenance work, and communicate with stakeholders. I have not come across any other book that provides this much credible advice on the topic of technical debt without exclusively catering to a particular audience.
The author has really nailed the dynamics of working on a legacy modernization project. While recognizing that the human factors vastly outweigh the technical challenges in these efforts, she highlights strategies that have worked to keep big projects on track. Pulling tools from project management, DevOps, Design Thinking, and other disciplines may be necessary for a successful effort.
Super refreshing to finally have content on evolving legacy software in a sea of material covering hot new technologies! I resonated with a lot of the principles in the book, like how leading full rewrites can shape an engineer’s career despite not usually being the best approach to solve business problems.
Good observations about the myths of legacy systems and the challenges of modernizing them. A bit too much discussion about different methods/tools for my needs.
Wow, This book brings so much nuance! Focussing on the reality of maintaining software systems, it brings to light many of the discussions software engineers avoid. Rewrites are never easy or a clear-cut black/white story. Why are we rewriting software, who will maintain it, and how can we justify the effort to motivate people on the project and engage management? I will recommend this book in the future since I often get confronted with this type of situation.
While nominally a book for engineering leaders about handling legacy systems and modernization projects, this very well-written book contains really great thoughts about engineering projects in general. The ideas and lessons presented are widely applicable, well-explained, and presented in an organized and engaging way. I was prepared to skim the book, which honestly I often to when reading engineering books: most often there are good nuggets and thought-provoking ideas scattered throughout less-interesting passages. In this case, I pretty much read the book through and enjoyed it thoroughly. Highly recommended.
Who is this book for? It assumes a deep technical understanding and explains really basic things at random times. Like we’ve already talked about monoliths why is there a several page description of what they are six chapters in.
Not everyone understands the value of modernization projects. I've been in meetings where people can't even spell "modernization", probably because they haven't been exposed to that kind of projects.
As the author quoted, "we build our computers the way we build our cities—over time, without a plan, on top of ruins." - Ellen Ullman.
Legacy systems are everywhere. And not many engineers know how to deal with them effectively. The saying if it's not broken don't fix it, is mainly due to lack of understanding of how those systems work and the fear of the unknown. That's how systems go without proper maintenance over the years, until one day a major security vulnerability is found and you discover that the system cannot be patched because it is not supported anymore (true story).
There are not many books that talk about how to deal effectively with aging systems. Even though with each year that passes, it's much more likely that you will have to consider if you need to do a major refactoring or completely rewrite a system that has been for decades in your company. Chances are that you will add a new layer on top of the legacy system to deal with new features or capacity demands, and just move the problem somewhere else and let the future engineering team deal with that mess. Making the problem worse and more complex for the future.
The book is easy to read, very informative, full of anecdotes, she shares her approach to work with legacy systems, and what I consider is often missed in these types of projects, how to manage expectations, identify the real value of these projects, keep the morale of the team high, and make sure that progress is being made.
This book is an absolute must-read for anyone involved in software development. It dives deep into the world of modernizing existing software systems while providing valuable insights on preventing common issues with current systems.
Marianne Bellotti has done an exceptional job of setting the scene and laying a solid foundation for the rest of the book. She takes the time to explain the evolution of software and the importance of not blindly following every trend. Instead, she his guiding readers on when it's the right time to migrate to newer technologies.
But that's just the beginning! This book is a full of tools and ideas for tackling those daunting, messy projects. From identifying the right approach to executing it, the Marianne leaves no stone unturned. She even goes above and beyond by showing how to change perspectives on risk, empowering teams to gain momentum and confidence in tackling neglected software that hasn't been maintained for years.
A significant emphasis is placed on principled thinking, which sparks countless new thoughts and ideas as you read (e.g. system thinking, code yellow). You'll find yourself inspired to apply these principles to your own projects and elevate your software development game.
I can't stress enough how valuable this book is. In fact, I'm already planning to reread it soon to apply its practical advices to my job, and I highly recommend you do the same. With its clear and practical insights, "Kill it with fire" deserves a rating between 4-5, making it one of my top reads in 2023.
This is one of the best career (both technical and organizational) books I’ve read in a while. It’s a bit dense at points and makes a wide range of assertions, so a reader might not be completely engaged the entire way through (I slowed down in the middle). But it is packed with helpful insights about modernizing legacy systems – when to do so, how to do so, tips for getting buy-in, and tips for driving success. And in "legacy systems," the author encompasses everything from huge corporations running decades old monoliths to small startups that have outgrown a pattern and need to update.
The author gives technical examples with just the right level of detail, drawing from her experience running deprecations/migrations and generalizing to use cases that most engineers will see during their careers. The author also gives great tips for keeping engineers motivated and maintaining the trust of leadership during long migrations that might drag out longer than anticipated. I thoroughly enjoyed this book and right now, it’s my #1 recommendation as a career book for anyone in tech.
Highly recommended book for software engineers, DevOps engineers as this book is packed with useful information learned from past failures and history.
As a new grad coming into the software engineering industry, I might have not know the history and context of some of the legacy software and why it was designed that way.
This book clarified a lot of those questions and gave very practice and useful tips from lesson learned from maintaining legacy softwares.
Some of the important lessons I learned are:
Consider spending resources and time to not make something legacy in the next couple years. Delaying or ignoring the problems will cost more in the future.
Pay attention to automation because it can be overlooked and ignored unnoticed.
Keep the feedback loop open for important feedback from critical users of the tools.
Dont fix things that are not broken.
Iterating on the existing problem is more likely to improve the software than a full rewrite.
This entire review has been hidden because of spoilers.
Modernize your enterprise system without hitting the usual pitfalls. Deliver value throughout the process, empower the team, keep momentum, and keep the big wig suits on your side.
A great book to keep as a reference for when you run into the covered situations. But a hard book to gleam out the main points. It largely follows the flow from beginning to end of the story of modernizing a legacy system.
Main points: 1. Follow Agile methods and provide value asap. Huge waterfall style upgrades are risky. 2. Don’t assume newer is better. Find the value of the change and track it. 3. Build and keep momentum. 4. Increase predictability, visibility, and understanding of your system. 5. Expect that your newfound understanding will guide you towards high value pivots in effort. 6. Perfect is the enemy of good. Make smart trade offs. (Complexity vs coupling is the authors reoccurring example) 7. Align your goals with your employees needs and the processes that reward them.
A well thought-out, concise book on how to approach legacy modernization. Having been in this business for the last twenty years, I found a lot of great insight in this book.
Perhaps the biggest idea in the book is that one should avoid the need for any "modernization" altogether! Systems should be maintained with enough resources and kept up to date with technology and business changes. While most us software engineers know that, this rarely jappens even with critical systems. Once stability is reached, the resources are moved away. Software engineers may also view maintenance as professional dead end, with nothing new and fancy to learn.
As for the actual modernization work, some rules of thumb, methodologies and practises are given. I think this is wise. Circumstances always differ.
This entire review has been hidden because of spoilers.
What a great book. I enjoyed Bellotti's context of technology is cyclical, and the patterns are solving for compute or storage. Usually, one being ahead of the other. "Managing technical debt is restoring consistency."
During the many examples, she goes to lengths to show the fallacy of using the old tech/product as the spec. Refactoring and tech debt allow you to rethink the problem, not just make a carbon copy. It's hard to copy the solution in a new tech because decisions and context aren't captured.
The best part is how to solve "people" alongside tech, which is the hard part about paying off tech debt or modernization efforts. Really good tips on motivating teams.
Not so much a technical book, but well worth technologists reading, especially if they're involved with dealing with legacy systems.
The author has spent much of her career working with such legacy systems, and has distilled her experience with how to deal with them, and also how to handle teams who have to deal with them, exploring many of the pitfalls that teams often fall into, and looking at how as technologists we can evolve the legacy systems out of the problems they can fall into, and also some tips and guidance as to how to ensure the systems of today don't become the unmanageable legacy systems of tomorrow.
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.
Unlike the others I've read on the topic, this book talks very little about actual code and code constructs. It's much more about managing a modernization project as opposed to the typical legacy code books that talk about things from a developer's perspective. It does a great job of framing modernization conversations inside the business and connecting that to what the business goals are and what the risks are along with various observations and techniques for improving the odds for a successful effort. It's a fresh approach that is really needed in this space.
This entire review has been hidden because of spoilers.
The entertaining structure of the book briefs you on any topic starting from tech history - how the ancient hardware still affects/shapes modern solutions, to psychology and biases - mere exposure effect, confirmation bias, and my favorite: humans as pattern-matching machines. The book will be interesting to everyone involved in the development cycle with more focus on management philosophy. The key takeaway is not to fear turning off the component in question and observing the meltdown. But in all seriousness, it has a lot to offer and substance to think through.
I really enjoyed reading this book, although it was less technical than I've anticipated. It is more of a rundown of the management and organisation side of the whole legacy problem and doesn't go into deep details about neglected code.
The motivational aspect that was mentioned inside of the book really helps me right now to see the other side of some running efforts and to better shift the burden of the task on more shoulders.