Apr 23, 2012

Build Redundancy then Reduce to Refactor

Technical debt is something programmers deal with all the time. Everytime we want to ship something faster, we make a compromise with the design patterns. Everytime software is used for a while, we realize that an alternate pattern would have been a better fit. We then decide to patch up and move on or do it the "right way" by refactoring the code.

Refactoring most of the times is a scary deal. Especially when the code has been in use for some time and is stable. The perfectionist gene in us wants us to redo it right. Build it up again the "right way". But then the pragmatic gene in us wants us to patch it up and ship it.

One of the measures I use in refactoring is the actual time that my application wont be able to run. If I am changing the code and it has been say 2 hours since my code cannot be executed because of the changes I am doing, that alerts me that I might be going the wrong way. The fatigue, the fear, kicks in. This has led me to use redundancy to refactor. While I am transitioning my application from its current state to the "right way" state, I build redundancy so that the duration when my code is non executable is minimum. Once the redundancy has been tested I reduce my code getting rid of the old patterns of doing things.

This method does require some additional coding, even writing code that I know I will be deleting later. But a stable application generally has too many little things that can be missed out if we try to redo it from scratch. Also, seeing my code running all the time keeps me relieved and happy!