We’re constantly looking at the big picture.
For many of the projects we work on, there is an existing product that we are requested to add new features to. In a recent project, we needed to leverage much of the existing code to make the new features work. We realized that the existing code we needed to rely on was shaky: that is, likely to create bugs for both the new features, as well as in the original product.
A typical response to this situation is to duplicate the code, so that the new feature can be made bug-free. After all, we were asked to create a new feature, and it wouldn’t make much sense if the feature didn’t work because of the old code. Worse is that we might get blamed for “breaking” the existing project due to something we did in the process of adding the new feature.
But this creates something in software called a “smell.” Duplicating code is generally a bad idea. Unfortunately this how many consultants solve problems. They look only at their part of the project, without regard to the overall impact it can have in the future.
One of our core principles sounds like a Boy Scout motto: “leave the camp cleaner than you found it.” The right solution is to fix the issues with the old code and verify that the existing features remain working. While it has more risk in the short term, there are several benefits:
- the original project gets more thorough testing
- the original project becomes more stable
- the new features are stable
- things are easier to maintain in the future
We’re not here just to fix the problem that’s in front of us. We’re here to fix the problems that you haven’t yet seen.