Working Effectively with Legacy Code

by Michael C. Feathers

Adding a feature seems like the most straightforward type of change to make. The software behaves one way, and users say that the system needs to do something else also. Suppose that we are working on a web-based application, and a manager tells us that she wants the company logo moved from the left side of a page to the right side. We talk to her about it and discover it isn’t quite so simple. She wants to move the logo, but she wants other changes, too. She’d like to make it animated for the next release. Is this fixing a bug or adding a new feature? It depends on your point of view. From the point of view of the customer, she is definitely asking us to fix a problem. Maybe she saw the site and attended a meeting with people in her department, and they decided to change the logo placement and ask for a bit more functionality. From a developer’s point of view, the change could be seen as a completely new feature. “If they just stopped changing their minds, we’d be done by now.” But in some organizations the logo move is seen as just a bug fix, regardless of the fact that the team is going to have to do a lot of fresh work. It is tempting to say that all of this is just subjective. You see it as a bug fix, and I see it as a feature, and that’s the end of it. Sadly, though, in many organizations, bug fixes and features have to be tracked and accounted for separately because of contracts or quality initiatives. At the people level, we can go back and forth endlessly about wh...