Hot Best Seller

Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)

Availability: Ready to download

The Legacy Apocalypse is upon us and business, community, and political leaders at all levels need this timely and thoughtful book from a superstar in the field. Aging computer systems present complex technical challenges for organizations both large and small, and Kill It with Fire provides sound strategies for spearheading modernization efforts. Kill It with Fire examines The Legacy Apocalypse is upon us and business, community, and political leaders at all levels need this timely and thoughtful book from a superstar in the field. Aging computer systems present complex technical challenges for organizations both large and small, and Kill It with Fire provides sound strategies for spearheading modernization efforts. Kill It with Fire examines aging computer systems, the evolution of technology over time, and how organizations can modernize, maintain, and future-proof their current systems. In playful and engaging prose, Marianne Bellotti uses real-world case studies to illustrate the technical challenges of modernizing complex legacy systems, as well as the organizational challenges of time-intensive maintenance efforts. The book explains how to evaluate existing architecture, create upgrade plans, and handle communication structures. Team exercises and historical analyses of complex computer systems make this a valuable resource for those in both older and newer companies, and will help readers restore or create systems built to evolve as time goes on.


Compare

The Legacy Apocalypse is upon us and business, community, and political leaders at all levels need this timely and thoughtful book from a superstar in the field. Aging computer systems present complex technical challenges for organizations both large and small, and Kill It with Fire provides sound strategies for spearheading modernization efforts. Kill It with Fire examines The Legacy Apocalypse is upon us and business, community, and political leaders at all levels need this timely and thoughtful book from a superstar in the field. Aging computer systems present complex technical challenges for organizations both large and small, and Kill It with Fire provides sound strategies for spearheading modernization efforts. Kill It with Fire examines aging computer systems, the evolution of technology over time, and how organizations can modernize, maintain, and future-proof their current systems. In playful and engaging prose, Marianne Bellotti uses real-world case studies to illustrate the technical challenges of modernizing complex legacy systems, as well as the organizational challenges of time-intensive maintenance efforts. The book explains how to evaluate existing architecture, create upgrade plans, and handle communication structures. Team exercises and historical analyses of complex computer systems make this a valuable resource for those in both older and newer companies, and will help readers restore or create systems built to evolve as time goes on.

30 review for Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)

  1. 4 out of 5

    Michael Burnam-Fink

    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 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.

  2. 5 out of 5

    David

    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 arc 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. ----

  3. 4 out of 5

    Dmitriy Rozhkov

    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. 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.

  4. 4 out of 5

    Jo

    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 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".

  5. 5 out of 5

    Thomas

    Probably a 4.5 but definitely recommended!

  6. 4 out of 5

    Scott

    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. 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.

  7. 5 out of 5

    Kevin Merlini

    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 i 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.

  8. 5 out of 5

    Mason Jones

    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 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.

  9. 4 out of 5

    Mitra Mirshafiee

    🚀 The Book in 3 Sentences 1. Don’t modernize (or fully rewrite) just for the sake of modernization, instead, leverage your system’s ability to improve the current architecture. 2. Software/tech industry is also made of micro groups with their own mindset and politics. 3. Give programmers autonomy to define their own thresholds and debate changes they’d like to make, but set goals, policies, and assign leaders for each group. 🎨 Impressions Overall, the book was like a chimera of various tech-related s 🚀 The Book in 3 Sentences 1. Don’t modernize (or fully rewrite) just for the sake of modernization, instead, leverage your system’s ability to improve the current architecture. 2. Software/tech industry is also made of micro groups with their own mindset and politics. 3. Give programmers autonomy to define their own thresholds and debate changes they’d like to make, but set goals, policies, and assign leaders for each group. 🎨 Impressions Overall, the book was like a chimera of various tech-related subjects. Many of which were incomprehensible to my inexperienced mind, but others were relatable and even inspirational. It was not only about software engineering and legacy systems, but also a guide on how to lead groups, merge companies, and help people understand the value of change, especially when there is resistance to do so. 💡 How the Book Changed Me / tips - If a change is needed, make it a top priority - calling yellow code (or no one will give a damn after a few weeks). - In meetings: What are we optimizing? List the desired outcomes Is this item critical? (if everything else went favorable, could this project succeed?) Is this discussion in- or out- scope? (out-scope = true, but irrelevant) Do time-bound experiments. What each experiment requires\entails? ✍🏼 Large meetings are less effective than smaller ones. - Embolden/reprimand failure and you’ll lose creativity. ✍🏼 No one wants to such at their job. - One way to find old systems failure: follow the money and where it’s being spent. - Career path: switching focus to work on different areas of my job is preferable to staying in one for thousands of years. ✍🏼 Positive reinforcement in form of social recognition tends to be a more effective motivator than traditional incentives - Record what you work on, because humans are terrible judges of time. - I realized how sometimes I try to over-clean the code I’ve written to make it more coherent. But in truth I’m just overthinking the concept of consistency. (artificial consistency) - When trying to implement a change, don’t highlight the obstacles or permissions that need bureaucratic approval, instead make people feel comfortable with it by presenting the advantages of the saved time and money (✍🏼 tell the story). Also show them and how each stage takes care of itself. ✍🏼 Prune the number of big decisions that have to be made to move forward. ✍🏼 Ask for forgiveness not permission.

  10. 5 out of 5

    Nhu Luong

    This review has been hidden because it contains spoilers. To view it, click here. 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 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.

  11. 5 out of 5

    Riku Sarlin

    This review has been hidden because it contains spoilers. To view it, click here. 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 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.

  12. 4 out of 5

    Deane Barker

    Not what I expected. I thought I was getting a technical book with literal strategies for managing and migrating legacy systems. Instead, the book spends a lot of time on organizational politics, change planning, and even developer psychology. I'm not saying this is wrong (the author clearly knows more than me), but I feel like it wasn't quite what the book was promoted as. The book did open my eyes to other aspects of the migration and management process, but I was looking for something much more Not what I expected. I thought I was getting a technical book with literal strategies for managing and migrating legacy systems. Instead, the book spends a lot of time on organizational politics, change planning, and even developer psychology. I'm not saying this is wrong (the author clearly knows more than me), but I feel like it wasn't quite what the book was promoted as. The book did open my eyes to other aspects of the migration and management process, but I was looking for something much more practical and hands-on.

  13. 4 out of 5

    Josh Finnie

    This is a fascinating read for anyone in the software development space. The lessons and take-aways I have from this book will stay with me throughout my career. If you are serious about software development and do not have the luxury of staying in greedfield projects your entire career, you need to pick up this book.

  14. 4 out of 5

    Jenny

    Read the first half of this last year and loved it, decided to come back to it since I hadn’t been able to read anything new for like two months. I genuinely think everyone who builds software (this includes product and design), everyone who manages someone who build software, and everyone who cares about how theories of change clash against organizational incentives should read this.

  15. 4 out of 5

    Matthew Campbell

    Excellent book detailing approaches for tackling legacy code systems. Appreciate that the approaches cover socio-technical aspects that lead to legacy projects being challenging. Great list of resources and tools.

  16. 4 out of 5

    HLN

    Excellent ! A good place to start if you think the systems you're working on might need a little modernization 😁 Actually it also is a must read to avoid having to do any system modernization at all. Excellent ! A good place to start if you think the systems you're working on might need a little modernization 😁 Actually it also is a must read to avoid having to do any system modernization at all.

  17. 4 out of 5

    Lauri

    Offers clear actionable guidance on navigating the organization and management of a software project. Persuasive, to-the-point, and easy to read. Recommended reading for anyone working in software development teams

  18. 5 out of 5

    Łukasz Słonina

    Wish I had read it when we were planning migration of our system. Actually the book is far from advicing to rewrite legacy system. Author provides approaches for improving legacy system, organising people to do that. And finally you would learn that is not that easy to do the rewrite.

  19. 4 out of 5

    hdp

    A lot here that resonates with my experience and plenty of interesting ideas for the future. I appreciate the focus on the human elements of systems. "In the end, technology is never finished being built." A lot here that resonates with my experience and plenty of interesting ideas for the future. I appreciate the focus on the human elements of systems. "In the end, technology is never finished being built."

  20. 5 out of 5

    Matthew Carlson

    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.

  21. 5 out of 5

    Kevin

    Loved it. If your business has one or more legacy systems (and, be honest, they all do), you need this book. Very practical concepts and insights without getting into the weeds.

  22. 4 out of 5

    Patrick S Kelso

    Some stories that feel too real, and some useful strategies for dealing with big technology transformation projects. I'm sure this is a book I'll refer back to frequently. Some stories that feel too real, and some useful strategies for dealing with big technology transformation projects. I'm sure this is a book I'll refer back to frequently.

  23. 5 out of 5

    Ravi Sinha

    Aside from the tips on future-proofing, I also liked the history lessons.

  24. 4 out of 5

    Matt Connolly

    A bit slow in parts but introduced me to some new and interesting concepts.

  25. 4 out of 5

    Snorre Lothar von Gohren Edwin

    Really good pointers to how to think about technical architecture! Worth rereading when I have learned more

  26. 4 out of 5

    Lauren

    This is the most relevant book to my tech career that I have ever, ever read. It’s about navigating the people problems of working in big, complex systems.

  27. 5 out of 5

    Robert J.

    Found the book very useful and insightful

  28. 5 out of 5

    Ruslan Diachenko

    Interesting historical facts. I didn't know the story behind 80 character line length. Many given approaches for handling legacy systems may already be familiar to experienced engineers. Interesting historical facts. I didn't know the story behind 80 character line length. Many given approaches for handling legacy systems may already be familiar to experienced engineers.

  29. 5 out of 5

    Vasil Kolev

    I expected a more technical than management book, but otherwise doesn't disappoint and is full with interesting advice. I already have a few people in mind that should read it :) I expected a more technical than management book, but otherwise doesn't disappoint and is full with interesting advice. I already have a few people in mind that should read it :)

  30. 5 out of 5

    S

    Useful book

Add a review

Your email address will not be published. Required fields are marked *

Loading...