In nearly every legacy system, what the system does is more important than what it is supposed to do. [Working effectively with Legacy Code]
Let me describe you a real-life example.
Some time ago my team was struggling with a tricky issue. A typical situation without good solution. Imagine an application which allows users to freely modify layout settings, like color of the button background. Unfortunately, there was a bug in the system - instead of changing background color, the setting was changing the border color.
The bug occurred a while ago, at least a couple of months, and users, whether consciously or not, got used to it in the meantime. So, when the issue was found and resolved, so that the setting started to change background color once more, many clients treated it as... a new bug.
How is that possible that a behavior, which works as it was originally intended, was perceived as an incorrect one?
Well, the incorrect behavior was occurring so long, that it became a new and desired system function. The baseline has changed. It is more important that over the last dozens of versions, the program worked in a non-intended way, despite the original specification. So, in this particular case, instead of changing the system behavior, it would be enough to change the name of the setting, e.g. background color to border color.
The key to understanding the situation is to focus on the phrase “was resolved”. What does it even mean? Is resolving an issue supposed to mean returning to the original intention of a designer, or is it about reflecting how a system actually behaves? So maybe it is about stabilizing, legitimizing or accepting rather than fighting?
What is the system supposed to do? That’s the most fundamental and the most difficult question while dealing with Legacy Code. It’s hard to find proper criteria for this evaluation. No matter what you have decided: communicate clearly with the users, keep backward compatibility and perform impact analysis. No one likes not to know what is happening, no one likes it when things brake without their fault, and everyone should be doing deterministic analysis of changes to prevent the previous two from happening.
Top comments (0)