Recently, I noticed something funny in a code base that I view seldomly. I was scrimmaging through the code of a maintained code base and noticed something sour – duplicated code. Duplicated code is not bad, when it is in the form of syntax of a language (haha)! And that isn’t real duplication! What I noticed was something that frustrates me, and surprisingly, wouldn’t have frustrated me 4 months ago. The duplication was basically 10 duplicated functions that were essentially identical to each other with hard-coded differences that should have been parameters and were written when the quantity of functions were low and the purpose was minor. What really irritates me is that this code has been updated many times and someone, in the words of Andy Hunt and David Thomas, did not fix the broken window. I’m not writing this post to complain, but to rather preach.

If you see something you know just isn’t right, take ownership of the code and fix the problem. It is easy to say it’s not yours or that you can do it next time or that the code base is so old it will be replaced. Well those excuses may or may not be true. But chances are, you will have to look at it again, or someone will, and you should fix it now while you know. If you aren’t familiar with this or it sounds familiar, it’s basically the principle of controlling the entropy within your project, which is preached within 3 of the 4 programming books I’ve read in the last 4 months. Whether it’s building an application, playing a game of pool, or anything for that matter, you should try to control the chaos and be pro-active and decisive with reason.

Thankfully, I fixed the problem. This is something that I do regularly and consistently now that I’ve gone through quite a learning curve. I refactor, refactor, and refactor some more. Perfection isn’t what you can add, it’s what you can take away.