Legacy code is code you are afraid to change. It has ossified and is no longer _soft_ware. It could be 20 years old in an outdated style and versions of tooling, or it could be 2 seconds old because you don’t really understand why your new code is working.
Tests and docs are the best prevention of legacy status because it gives maintainers some confidence their changes do not have unintended consequences.
I think this is spot on, it doesn’t matter much why you’re afraid to change it, just that you are.
Ironically some of the most ossified systems I’ve worked with had decent documentation and the people who built them were still around, but they were overworked and stressed out of their minds. The last thing they wanted was for someone to rock the boat and get them paged in at four in the morning, even though the tests made the risk of that rather small.
In my experience it’s pretty common as legacy systems hardly adapt to the inevitable changes in the world around them. They also have an annoying tendency to warp their environment because it’s easier to change that, which rarely makes for stable solutions.
I don’t want to lead away from the main discussion, but the first thought I had when I read the context to the question was the video with Richard Feynman answering the question of “why” magnets pull and repel each other. He quickly goes more deep into the question of how difficult a “why” question is to answer.
This is mind blowing !
Loved it !
I mean, the first few minutes alone helped me understand my life. I have a toddler and he always asks why. It makes sense - we do not share a common framework!
This also builds perfectly into my knowledge of systems. Explaining Managers why something happens can be a hard task in the easiest of days.
I think this was a perfect addition to the conversation!
An experience I share as well.
But this raises yet another question:
Should we rewrite them?
@dimitarvp defends we should possibly avoid such a rewrite if a legacy system has business logic inside
@jhogberg defends that legacy systems make it unlikely to have stable long term solutions to business problems
It feels to me that if you have one (and in my experience you always do) then you have no right way to go about it.
Almost. I am defending the position of: “If your ONLY business logic documentation is the code itself then don’t rewrite it – YET. You could rewrite it later if you manage to contain and isolate good business logic documentation”.
It feels to me that if you have one (and in my experience you always do) then you have no right way to go about it.
I think there is, believing there’s no good way out is one of the ways legacy systems stay the way they are. I’ve yet to encounter something that couldn’t be righted once we fully comprehended it, either through refactoring or understanding the problem deeply enough for a rewrite.
Mind you, if it were easy you probably wouldn’t have the problem to begin with, but sometimes you just have to grab your garden gloves and start digging.
Yes, there’s rarely one root cause. Ultimately the exercise is to determine how it could be prevented in the future and if it is worth it take the steps required.
I always approach RCAs with the idea that everything will happen again and no incident is such a unique snowflake that it won’t. The RCA uncovers likely repeat causes. You can either take steps to mitigate or not complain when it happens the next time.
Resolve a few of these and you’ll end up with a very reliable system.
@Fl4m3Ph03n1x Thank you! I am glad to hear that you enjoyed it, and that it was well received. Yes, toddlers are a good example of the framework dilemma. I often encountered it working or in general, meeting people from entirely different cultures. Hope you guys are having fun expanding (your) frameworks ; ).