5 ms·

A Review of “Kill It with Fire: Manage Aging Computer Systems”

110 points by slyall 5y ago

throwaway984393 5y ago
Legacy systems are still legacy because nobody ever wanted to pay to replace it. Later on it becomes so old that nobody even knows how to replace it, which adds to the cost - in investigation, and in the replacement not meeting feature-parity, and in cost of failure. Basically, you should fully expect any replacement system to be too expensive and take too long. So this book is correct that managing the organization is probably the most important part of transitioning a legacy system. Somebody has to trick finance into giving you twice the budget, and product & sales into giving you twice the time, and build an engineering department strong and large enough to do two things: 1) run a legacy system, and 2) build and run a new system that will be way more complex than the old system team can handle - including the moving-saucers-of-tea-between-two-moving-18-wheelers-on-a-plank migrations. It's only once you've got the organization well trained (like a prize Poodle) that you can think about the code. And I'm not sure if "Future Proof" is tongue-in-cheek, but it should be. Every system should come with a sunset date and a plan to transition to a replacement system. You can't predict the future system, but you can at least estimate how to migrate to a nearly-identical system - the cost, the timing, the reliability, the portability, etc. My favorite sign of an unprepared manager is when I ask them about their plans for when we will eventually transition away from the system, and they reply "Well I hope we don't move away from it, it's costing $X to build!" When what they really mean is, "I'll be long gone by then."
- KineticLensman 5y ago
  Yes. A good lifecycle model should include a disposal phase and associated questions. E.g what resources can be repurposed when we stop using X?
- cable2600 5y ago
  I took Clipper, Oracle SQL/PL, dBase, and Lotus 123 databases and converted them to MS-Access and SQL Server databases.
- ownagefool 5y ago
  I don't think "future proof" has to be tongue-in-cheek. There's about a billion buzzwords that are misappropriated which'll make everything slower, but behind the buzzword there's typically some insight that'll help with some problems when they're not just a catch-all buzzwords. Personally, I don't actually think the following is a terrible tactic for most of our CRUD apps. - Start with a fullstack monolith framework because it's probably going to be the fastest and simplest way to market. - Break up the monolith. Microservices everything! - Use some buzzword system that'll help facilitate this ( your testing an operations just got harder, it's a trade off, k8s now might make sense ). Stepping away from just following the fad, at some point, if you're successful, your company is going to be complicated enough where you have, for example, 5 ways of sending emails. None of them quite complete enough to handle blacklisting, delivery failure, debugging, or audit logging. Que the email gateway service. You now, if done right, hopefully have encapsulated the email problem into a single codebase, run from a single location, owned by a single team, that understands the issues and actually completes the implementation. If you go into this eyes-wide open, it doesn't need to be a massive problem when it happens. Of course, this doesn't always go well. The most common failure I see in big orgs is it gets political, gets stolen by architecture, they bootstrap an internal services team who refuses to release anything until it's done, dissapear into the void, whilst banning any other development org from working on the problem. This has less to do with the path being wrong, and more to do with the culture being wrong. Give the problem to someone who needs to release something, i.e. the onboarding team sends most emails, they can build the common email gateway, and they'll accept PRs as it's not the only problem. Of course YMMV. It depends. :)
speed_spread 5y ago
I would skip the first book and go straight to the second book "Nuke It From Orbit: It's the only way to be sure it wont be restarted"
- bombcar 5y ago
  And the thrilling “The Revenge of The Unknown Yearly Process: I Hope You Had a Backup” ;)
kqr 5y ago
I'm a huge fan of Bellotti's writing on the web (https://bellmar.medium.com/ https://bellmar.medium.com/), so this is definitely high on my to-read list.
cpeterso 5y ago
Here are two presentations from the author of "Kill It With Fire", Marianne Bellotti: "We Killed These Things With Fire | Øredev 2019" https://www.youtube.com/watch?v=XoEfV0kXXDY https://www.youtube.com/watch?v=XoEfV0kXXDY "Future Proofing Systems with Marianne Bellotti" (2020) https://www.youtube.com/watch?v=_ICzo5r-7vY https://www.youtube.com/watch?v=_ICzo5r-7vY
goto11 5y ago
"Legacy system" has negative connotations among developers, but really it just means a system which works and have been working for a long time.
- _wldu 5y ago
  This is true. I have heard security people argue that SMTP, POP and IMAP are 'legacy protocols' that must be ditched to better secure email.
  - jhgb 5y ago
    Bread is legacy food. Beer is legacy drink. I feel like that about sums it up.
    - Koshkin 5y ago
      This sums up nothing. (You could go as far as saying that our own bodies are legacy systems. So what? What does that have to do with anything?)
      - netr0ute 5y ago
        > What does that have to do with anything? It means that "legacy" is meaningless if it can be applied so so many other things.
        psd1 5y ago
        Semantics are contextual, and your legacy bread / legacy software parallel doesn't convince me. Is it a precise term? no, but most ppl here will have a good idea of what it means.
    - bostik 5y ago
      Legacy is any code you wrote before lunch.
  - paulryanrogers 5y ago
cable2600 5y ago
I list on my website that I work with legacy computers, often moving them to emulators to preserve them from crashing due to a hardware failure. I use QEMU because it emulates many systems not just PCs.

110 points by slyall 5y ago

Legacy systems are still legacy because nobody ever wanted to pay to replace it. Later on it becomes so old that nobody even knows how to replace it, which adds to the cost - in investigation, and in the replacement not meeting feature-parity, and in cost of failure. Basically, you should fully expect any replacement system to be too expensive and take too long. So this book is correct that managing the organization is probably the most important part of transitioning a legacy system. Somebody has to trick finance into giving you twice the budget, and product & sales into giving you twice the time, and build an engineering department strong and large enough to do two things: 1) run a legacy system, and 2) build and run a new system that will be way more complex than the old system team can handle - including the moving-saucers-of-tea-between-two-moving-18-wheelers-on-a-plank migrations. It's only once you've got the organization well trained (like a prize Poodle) that you can think about the code. And I'm not sure if "Future Proof" is tongue-in-cheek, but it should be. Every system should come with a sunset date and a plan to transition to a replacement system. You can't predict the future system, but you can at least estimate how to migrate to a nearly-identical system - the cost, the timing, the reliability, the portability, etc. My favorite sign of an unprepared manager is when I ask them about their plans for when we will eventually transition away from the system, and they reply "Well I hope we don't move away from it, it's costing $X to build!" When what they really mean is, "I'll be long gone by then."

KineticLensman 5y ago
Yes. A good lifecycle model should include a disposal phase and associated questions. E.g what resources can be repurposed when we stop using X?
cable2600 5y ago
I took Clipper, Oracle SQL/PL, dBase, and Lotus 123 databases and converted them to MS-Access and SQL Server databases.
ownagefool 5y ago
I don't think "future proof" has to be tongue-in-cheek. There's about a billion buzzwords that are misappropriated which'll make everything slower, but behind the buzzword there's typically some insight that'll help with some problems when they're not just a catch-all buzzwords. Personally, I don't actually think the following is a terrible tactic for most of our CRUD apps. - Start with a fullstack monolith framework because it's probably going to be the fastest and simplest way to market. - Break up the monolith. Microservices everything! - Use some buzzword system that'll help facilitate this ( your testing an operations just got harder, it's a trade off, k8s now might make sense ). Stepping away from just following the fad, at some point, if you're successful, your company is going to be complicated enough where you have, for example, 5 ways of sending emails. None of them quite complete enough to handle blacklisting, delivery failure, debugging, or audit logging. Que the email gateway service. You now, if done right, hopefully have encapsulated the email problem into a single codebase, run from a single location, owned by a single team, that understands the issues and actually completes the implementation. If you go into this eyes-wide open, it doesn't need to be a massive problem when it happens. Of course, this doesn't always go well. The most common failure I see in big orgs is it gets political, gets stolen by architecture, they bootstrap an internal services team who refuses to release anything until it's done, dissapear into the void, whilst banning any other development org from working on the problem. This has less to do with the path being wrong, and more to do with the culture being wrong. Give the problem to someone who needs to release something, i.e. the onboarding team sends most emails, they can build the common email gateway, and they'll accept PRs as it's not the only problem. Of course YMMV. It depends. :)

speed_spread 5y ago

I would skip the first book and go straight to the second book "Nuke It From Orbit: It's the only way to be sure it wont be restarted"

bombcar 5y ago
And the thrilling “The Revenge of The Unknown Yearly Process: I Hope You Had a Backup” ;)

kqr 5y ago

I'm a huge fan of Bellotti's writing on the web (https://bellmar.medium.com/ https://bellmar.medium.com/), so this is definitely high on my to-read list.

cpeterso 5y ago

Here are two presentations from the author of "Kill It With Fire", Marianne Bellotti: "We Killed These Things With Fire | Øredev 2019" https://www.youtube.com/watch?v=XoEfV0kXXDY https://www.youtube.com/watch?v=XoEfV0kXXDY "Future Proofing Systems with Marianne Bellotti" (2020) https://www.youtube.com/watch?v=_ICzo5r-7vY https://www.youtube.com/watch?v=_ICzo5r-7vY

goto11 5y ago

"Legacy system" has negative connotations among developers, but really it just means a system which works and have been working for a long time.

_wldu 5y ago
This is true. I have heard security people argue that SMTP, POP and IMAP are 'legacy protocols' that must be ditched to better secure email.
- jhgb 5y ago
  Bread is legacy food. Beer is legacy drink. I feel like that about sums it up.
  - Koshkin 5y ago
    This sums up nothing. (You could go as far as saying that our own bodies are legacy systems. So what? What does that have to do with anything?)
    - netr0ute 5y ago
      > What does that have to do with anything? It means that "legacy" is meaningless if it can be applied so so many other things.
      - psd1 5y ago
        Semantics are contextual, and your legacy bread / legacy software parallel doesn't convince me. Is it a precise term? no, but most ppl here will have a good idea of what it means.
  - bostik 5y ago
    Legacy is any code you wrote before lunch.
- paulryanrogers 5y ago

cable2600 5y ago

I list on my website that I work with legacy computers, often moving them to emulators to preserve them from crashing due to a hardware failure. I use QEMU because it emulates many systems not just PCs.