Legacy code is not necessary a bad thing. Some times a piece of software is working as expected and does not need to be changed in a significant way. So it makes sense to just "leave it" at that.
It does become an issue when the software, or parts of it, needs to be changed and maintained on regular basis. This could be because the roadmap or business needs suddenly are focusing on a legacy part of the software. Then is when more care needs to be taken.
When this happens I would usually recommend to "refactor as we go along". Meaning writing tests and refactoring code with as minimum scope as possible. There is no need to rewrite a big part of the application when what we are really after is updating or changing a smaller part of it.
Overall it should be taken in a pragmatic way. My view is that technical debt should be constantly repaid as work requires it. But not necessarily going on a "which hunt" just to conform with arbitrary targets or standards.
Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
Legacy code is by definition a liability. Code always has to change and if you leave parts of it unknown your developers will work around it, growing the problem by warping the code around their limited understanding.
Entire companies have folded under the liability of unchangeable code, don’t be like them. Work against it with tests and aggressive simplicity
True. Technical debt is a liability when not handled properly. There are several approaches you can take to repay technical debt. My preferred approach is to repay constantly as we work on the code that is affected by it.
The important aspect of this IMO is to be pragmatic about it. By addressing technical debt as we encounter it. And by keeping it within the scope of the work we are doing. We make sure that we get the best balance results. Technical debt is repaid, and no "unnecessary" (to the eyes of stakeholders) work has been undertaken.
Totally agree! We should stop seeing legacy code as broken code. It’s usually just old or hard to understand, but it doesn’t mean that it can’t be improved one step at the time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Legacy code is not necessary a bad thing. Some times a piece of software is working as expected and does not need to be changed in a significant way. So it makes sense to just "leave it" at that.
It does become an issue when the software, or parts of it, needs to be changed and maintained on regular basis. This could be because the roadmap or business needs suddenly are focusing on a legacy part of the software. Then is when more care needs to be taken.
When this happens I would usually recommend to "refactor as we go along". Meaning writing tests and refactoring code with as minimum scope as possible. There is no need to rewrite a big part of the application when what we are really after is updating or changing a smaller part of it.
Overall it should be taken in a pragmatic way. My view is that technical debt should be constantly repaid as work requires it. But not necessarily going on a "which hunt" just to conform with arbitrary targets or standards.
Legacy code is by definition a liability. Code always has to change and if you leave parts of it unknown your developers will work around it, growing the problem by warping the code around their limited understanding.
Entire companies have folded under the liability of unchangeable code, don’t be like them. Work against it with tests and aggressive simplicity
True. Technical debt is a liability when not handled properly. There are several approaches you can take to repay technical debt. My preferred approach is to repay constantly as we work on the code that is affected by it.
The important aspect of this IMO is to be pragmatic about it. By addressing technical debt as we encounter it. And by keeping it within the scope of the work we are doing. We make sure that we get the best balance results. Technical debt is repaid, and no "unnecessary" (to the eyes of stakeholders) work has been undertaken.
Totally agree! We should stop seeing legacy code as broken code. It’s usually just old or hard to understand, but it doesn’t mean that it can’t be improved one step at the time.