There's still a bug in this old soft, who's willing to fix it?
Every company has old software, which has performed services and still does, but which is now impossible to maintain. Most of the time, when a bug in this application is reported, the devs don't fight to intervene. Most of the time, it's the last person to have his name on git who intervenes (when he's still in the company).
Git
But let's face it, yesterday's solutions are today's problems.
Why is it that code has become impossible to maintain, and that every time a bug is fixed, 2 more are added? The causes are often multiple, but it's often due to a lack of automated tests, especially those that test for non-regression.
It's very unpleasant to work with this kind of source code, and it's even more unpleasant for the user.
Some developers will put forward the solution of refactoring, which is often long and costly. It's also a big responsibility. Others, less conscientious, will prefer to start from a new code base, but this means running into the same problems again in the more or less short term, since it will be based on the same development techniques and the same management.
Your code give you an hand
There's also the mirage of technology, "Don't worry, with this new framework, all these problems will disappear". Let me tell you: no, the magical new framework won't change a thing, the problems will happen just the same. A framework can also be misunderstood, misused, or used for the wrong things. I've seen it happen a lot in my career.
So we'll just pray that this bug will be the last one, and that we'll never need to go back into the code again. But that's an illusion. In this day and age, it's no longer possible to freeze software in time. You have to keep updating the libraries you use, to correct security flaws for example. And updates mean potentially new bugs, but as our software is poorly tested (if at all), we won't know until the customer submits a bug report. And we're back to square one.
With experience, I've learned to manage refactoring projects. Depending on the extent of the damage, there are several ways of dealing with problems:
Use a development methodology that integrates automated testing, such as Agile. Kent Beck, one of the signatories of the Agile manifesto, created Junit.
Refactoring often means deleting code. If you want to write things that last over time, write novels, not source code.
Refactoring should be part of your development routine.
There are plenty of techniques for refactoring even the most "Al dente" code you've ever seen. I particularly like the "Golden Master" and the "Mikado Method".
I'd now like to appeal to your own experience? Have you ever experienced what I'm describing, and if so, how have you solved the problems of old, buggy software that needs to be refactored?
