It’s something of a running joke that, you hand existing code to a developer, that developer will stay up all night completely re-writing it. I wish I could say it was completely a joke but, not only have I seen it happen numerous times, I’ve done it.
Counter-intuitively, some developers find it easier to use an existing application as a storyboard for a re-write rather than simply digging into the existing code. This is because programming is not only an extremely mental activity, it is quite psychological as well. When you are asked to take over existing code, as has happened to me a few time recently, you are not only learning the code, you are are also become familiar with how the previous developer(s) approached problem solving. You must train yourself to think like the previous developer in order to understand their approach.
The advantage of this is that you can learn new approaches. I have spent a lot of time reading open-source code to learn new ways to attack algorithms and such. This is especially helpful if I am working in an unfamiliar language. That is not the same, however, as taking over maintenance of code written by someone else.
The main disadvantage of this is that it can lead you away from your own tendencies. You can begin coding with a bit of trepidation as you try to adjust to the style in front of you and mesh your new code into it.
I would love to say that all developers adhere diligently to design patterns but, as the saying goes, patterns are more like guidelines than actual rules. Also, what developer worth their salt got into programming so they could follow patterns?
The past few years, I’ve trained myself to get out of the habit of re-writing. I was initially to do this inspired by open-source software. Open-source projects have numerous collaborators come and go without major re-writes every time. Why can’t I do that for a single project?
In recent projects, I’ve only proposed and executed one complete re-write, and that was because the approach was simply unsustainable. Instead, my approach is to spend some time with the code before making changes. I’ll read through it (the code, not the comments), build the application and get it running, debug it, and generally examine it inside and out. This can take a while and it can often appear that little progress is being made during this time. What I have found, however, is that I can be much more efficient in making modifications. Additionally, new code, which is usually written in my style, integrates more easily.
Putting myself into the mindset of the previous developer has become a puzzle that I enjoy solving. It requires an open-mindedness that I did not fully appreciate earlier in my career. It helps my customers by eliminating the back-tracking of unnecessary re-writes but, in the long run, it’s also made me a better developer.
