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

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

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?

I took Clipper, Oracle SQL/PL, dBase, and Lotus 123 databases and converted them to MS-Access and SQL Server databases.

Among salespersons, it means "that which we didn't sell you."

My definition of "legacy system" is something like "you can't ask for help when you need it on specific parts of the system".

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.

The reason for the negative connotations is when it's used it also usually means "A system which nobody really understands", usually because of lack of tests and documentation. Maybe the high cost to modify it is working as intended in some cases (don't modify this project, start a new one). But when the business expects the legacy product to be modified, then you run into trouble.

To me it means existing code. If it has been accepted by the PO it is now legacy. The new code that was just accepted now influences any decision involving it going forward. Legacy.

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