Kill it with fire!
- Grant McKenna
- Feb 9, 2024
- 2 min read
Marianne Bellotti's Kill It With Fire is a great book with invaluable insights into why software ends up in the state it is in, and why legacy doesn't mean old but something more fundamental. I won't go into huge detail but I strongly recommend you invest your time reading approximately the 200 pages.

The key learning when faced with legacy modernisation is to ask "Why?" and the answer should be focused on value. The obvious value metric is cost (e.g. moving to the cloud will save money) and that is a reasonable thing to measure; however cost is not the only value metric. Other possibly competing value metrics could be productivity improvements, maybe for the developers through simpler onboarding or better tooling, or maybe for your users if it means better remote working connectivity, or system stability. System stability is all about trade-offs. Adding distributed micro-services, or lambda functions, gives greater scalability and redundancy, but it does introduce network latency and failures. Also, migrating from an older language or architecture paradigm may introduce issues (bugs!) that were not previously in the system because of the different ways data is handled, 'truthiness' is determined, nulls are handled, etc. Not migrating from an older language may make it expensive or impossible to find developers were the required skills either to do the job or train others to do the job.
The above are all assumptions (both positive and negative) and as such they need to be tested like any other assumptions in the business plan, or migration strategy. Cloud is not always cheaper than on-premise, especially if large data sets are involved, but even if it is not cheaper there might be other reasons for moving to a cloud provider. The key is not to assume it is cheaper; the key, in this case, is to find the real cost and compare rather than assume or guess.
As much as it might be tempting to do, stopping the world and asking to get off is not an option and the same applies to maintaining software applications. If you've ended up in a situation of having to do a modernisation programme have a plan, assume it will be harder than everyone thinks and take longer than everyone wants; better still avoid the need by ensuring your systems are adaptive and fit-for-purpose - i.e. don't put off the small stuff until the small stuff is now a towering mass crushing the business and (metaphorically) everyone who works there.
Comments