Of course there are defects in legacy code. But when you are a developer working on changing, refactoring or enhancing legacy code, many of the “defects” you’ll find are probably desired behaviour (or have been, at some point in time). And even when they are not, you often still cannot be sure if you can fix the undesired behaviour without negatively affecting users. Let me explain…
...Changes Colour Unexpectedly
I once wrote some piece of really bad code that I use when I facilitate refactoring exercises at conferences, at user group meetups and during my trainings: The BabySteps Timer. A few days ago, I invited people on Twitter to refactor this code, as a challenge.
One of the developers who accepted the challenge, Franziska, submitted a defect report:
Clock resets to white colour when time is over Not sure if bug or feature, if the time has expired, the clock turns red, starts counting down from 2:00 again and then it turns white after a couple of seconds (see screenshots). Issue #1 by Franziska Sauerwein
I am fully aware that Franziska only reported some unexpected behaviour she saw, and did not have any intent of changing that behaviour during a refactoring exercise.
But this reminded me of a situation I experienced at a past client, where we actually changed some unexpected behaviour, and it didn’t turn out well…
But... The Numbers are Wrong!
Some years ago, I was working with 2 Scrum teams as an agile coach. When I joined, they were already one year into a project where they were changing some legacy code: They refactored the server, and they completely re-wrote the client.
In addition to its main purpose, the software calculated some statistics. When we started to work on that feature, we found out that the numbers it calculated were wrong. Under some conditions, it just gave inaccurate answeres, that were at least in the right ballpark, but sometimes the numbers were not only inaccurate - just plain wrong.
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!
Our Product Owner asked some key stakeholders, but noone could explain to us why this feature would be required. So we removed it.
A few months later, the “Blocker” defects were rolling in: “The statistics feature is missing! We cannot do our work!” they said.
We found out that this feature was only used during 4-6 weeks of the year and only by some users, and we did not look at this time frame when searching the logs.
We tried to convince the users to allow us to change the statistics so they’ll get the correct numbers. But we did not get a budget for that. They just wanted the old feature back, because “We only use them as ballpark estimates anyway”. “And when the software gives you wrong numbers?” we asked - “Oh, we can spot that”, they said.
So we put the faulty feature back in. But even after we put the feature back in, nobody wanted us to fix the defects…
Unexpected != Defect
In a real legacy code situation, don’t expect that you have found a defect when you have found some really strange behaviour. Ask business analysts. Ask stakeholders. Ask real users. Gather data from usage statistics and logs.
And even after you did all this, you cannot be 100% sure…
Yes, there are defects in legacy code. And yes, you will find some of them. But, as a developer, beware of just fixing the defect (especially if you are new to the project): The strange behaviour might not be a defect at all. And even if it is one, your fix might cause more problems than the defect.
Update: This post was on the front page of hacker news. Read the discussion here.
Side Note: I also changed the README of the babysteps timer to make it more clear that it is mainly an exercise/kata, not a program you should use. Even though you can use it, if you want.
Read more about how software architecture and design impact your agility in my book “Quick Glance At: Agile Anti-Patterns”: Buy it now!