Software consultant/engineer/architect, public speaker, triathlete, homebrewer, dad.
Living in Varberg, Sweden.
| Blog | https://raniz.blog |
| Work | https://factor10.com/ |
Without significant change of process and/or methodology, your new system will become your next legacy mess.
(Photo: Stacy via Unsplash)
The most common issues I encounter in legacy software systems are:
- Little or no automated testing
- Everything depends on everything else (high coupling)
- Functionality is spread out across the entire code base (low cohesion)
- No clear separation of internal and external concerns (such as HTTP authentication cookies in business logic functions, database connection handling in REST API controllers, etc.)
The software practices and development methodology that led you there will likely bring you into a similar mess if you do not change them.
Think about how you want your next system to look in ten years, identify the practices that will get you there—and then start implementing them!
The system you're replacing your ageing legacy with will be worse than what you have today.
This is because you are very likely to overcompensate for what you dislike in your current system.
Instead of a monolith, you might go overboard and have a hundred microservices,
You've heard about all these cool technologies that everyone else is using but haven't had the chance of trying, so you're using ALL of them.
(Image: "The magic roundabout", by Alby via Wikimedia Commons, CC BY-SA 2.0)
What you might end up with is, instead of a complex monolith with ageing technologies, a Kafka-based, event-driven, append-only sea of function-as-a-service storing their state in a blockchain running on Kubernetes, all communicating asynchronously over GraphQL through sidecars implementing a service mesh.
You now have more problems than you had before :)
A lot of rewrites fail because they are cancelled before completion—and a half-finished rewrite is, in most cases, not usable.
No one is going to accept a complete feature freeze for one, two, or even ten years while you rewrite everything from scratch. This means that what you are starting to rewrite today will not be the same system you will be replacing once you finish the rewrite (if you finish it)—i.e. you are chasing a moving target.
(Photo by Sébastien Lavalaye via Unsplash )
Your legacy system most likely has bugs—probably lots of them. How do you treat them when modernising or rewriting (parts of) it?
Straight-up bugs are probably fine to fix, but what about behaviour that doesn't exactly meet your specifications?
Changing behaviour that has been in place for many years—even if it was _wrong_—comes with the risk of breaking your customers' workflows and integrations. Tread carefully!
(image credit: XKCD 1172, "Workflow", CC-BY SA 2.5)
