As someone that has spent the last two years migrating legacy code, I can assure you, you do find bugs in legacy code.<p>I've seen bugs that user's don't notice.<p>I've seen bugs that user's have just gotten used to.<p>I've seen bugs where that failures it caused were dismissed as the system being a bit temperamental, for many years.<p>I've seen bugs that financially affected thousands of customers, and remained unnoticed over the course of several years.<p>I've even seen bugs that only remained because, by luck, the preconditions to trigger it had not been met.<p>I can assure you, you do find bugs in legacy code.
Quick website comment: If you're going to ask if I want to subscribe to your agile development course <i>and</i> your newsletter, I'd prefer if those popups came at the same time rather than several seconds apart. It's annoying enough to get one such popup.
> None of the business analysts could remember what this statistics feature was used for, so we tried to find out who uses it. We looked at the logs of the last 6 months and found out: It was never used! Not a single time!<p>I've seen a lot of similar stories. General advice: if you want to find out whether anyone really uses something, the relevant time span is a year and a day. It's theoretically possible longer would be needed, but a year and a day will cover almost all cases.
If you find a feature nobody has used for the last 6 months... and its to do with some long term calculations... probably safe to say they use it annually.
We have the end of year reports that generally kill the database when people try to run 5 years worth of data through them every christmas... they never touch them during the normal working year though.
It's only mentioned in a single line, but there are a lot of real bugs in legacy code that the users actually learned to live with. It's the software's personality now. And when someone has learned to live with a bug, it will be missed if it is suddenly not there any more.<p>In the past I considered that a bug in human behaviour, but actually it is admirable. You give people a broken tool, but instead of failing, they find a way to succeed using that broken tool. And of course after the effort they are not as willing to change to anything else. Don't change a running system and such.
"Legacy" is a very loaded term -- generally used in a derogatory way.<p>There is an old engineering truism: "if it ain't broke, don't fix it"<p>When Lindbergh flew across the Atlantic in the Spirit of St. Louis, the Wright Aviation Company which made the engine for his plane, wanted to do its best to make sure he made it. They carefully built and checked the engine and hand delivered it with a note: "don't monkey with it" (or words to that effect). Lindbergh was a careful guy and he didn't.<p>Businesses and developers need to distinguish between warranted or needed changes to working systems (software or otherwise) and ego trips.<p>Real systems are built in limited time, with limited resources, even if they have a multi-billion dollar budget. Invariably there are things someone can make an issue about even in a system with a perfect performance record. Why did you hard code 3.14159267 instead of having a general variable for PI initialized to 3.14159267, and by the way why do you have only 8 decimal places -- wouldn't 16 be better? It is an ego trip and it is the ancient territorial imperative, marking your territory by deprecating the previous person or team -- or a colleague.<p>Joel Spolsky wrote a famous and widely ignored blog post on this sort of thing:<p><a href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/" rel="nofollow">https://www.joelonsoftware.com/2000/04/06/things-you-should-...</a><p>Take a deep breath and ask yourself: is this something we <i>really</i> need to do or am I (are we) showing off/putting someone down/behaving like a spoiled adolescent?
So users of old software may be aware of various defects and have changed their behaviour to make it work for them. It's important to consider the human element when "fixing" legacy software.
You can't really safely alter legacy code unless it had decent unit tests. Red/Green programming (test drive development) is absolutely essential in cutting down on technical debt.