Measure twice, cut once. This concept presents itself as a solution to any project which requires some level of design. It is so very easy to understand, yet very difficult to enact. When do we know that our design is indeed finished and ready for the next phase? How do we decide that this is the best possible version that we can produce? The answer, as I have learned it, is rather complex. The optimal balance lies somewhere between “it works” and “it is perfect”. Unsurprisingly, the currency to exchange for a tilt in either side of the scale, is time. Spend too little on the design, and the fissures will reveal themselves during implementation. Spend too much time, and well, one cannot really ever achieve perfection, so this becomes a fool’s errand. Personally, I don’t believe this expression properly accounts for the intricacies and complexities found in the environment of computer science. While designing something from the ground-up can truly see this concept flourish, creating a module for an existing system can be incredibly challenging. This is especially true where code is concerned. One can map out the functionality in advanced, but there will always be that chunk of code that winks at you with redundancy. You know it when you see it. Your mind kicks into overdrive, glancing over the details, deciding what the commonalities are between the twin entities.  Then the lies begin. “I’ll come back later and fix it”. “Maybe the code is different after all”. “It’ll break something else if I fix it”. These are all things that have probably gone through our heads at one point or another. With this is mind, and in the spirit of writing cleaner code, I propose the following amendment to the age-old adage:

Measure twice, cut once, recover with grace, and refactor.

Truly, perfection is unattainable, but we can come close. For this reason, it’s necessary to account for refactoring in any design. According to Joydip Kanjilal in the article Understading Code Smells and How Refactoring Can Help, while code smells may not always indicate a particularly serious problem, following them often leads to discoveries of decreased code quality, drains on application resources or even critical security vulnerabilities embedded within the application’s code. It should be noted that while all of these potential flaws are important, we must consider the human factor as well. Clean code not only works better, it reads better. This is fact that we must remember when designing or maintaining code. At one point or another, another human will need to interact with our creation.

Let this be a positive experience for all those involved.

reduce. recycle. refactor.