Code maintenance is a big part of a developer's job. After we write our first method and then go back to fix it, it is a maintenance job 1. This is true for developing a new application from scratch or making enhancement to an existing application. But, developers often don't see it that way. When we inherit a poor written application, we lose a lot of freedom and creativity in creating our own solution.
I happen to inherit a poorly written application from time to time. When I inherit such application, I am not very motivated to work on the application. Everyday is a torture for me to just look at the legacy code. The code is poorly written, application architecture is accidental, no test cases or some of the test cases don't have assert statements. I complete the tasks I am asked to do by putting down the solution that first comes to my mind without refining it so that I can finish the project as soon as possible and move on to the next project. But, what if the next project is worse than the project I had before? So, the evil cycle continues.
I didn't resolve to hacking my solution overnight. At the beginning of the project, I was determined to make the project better by recommending some of the pragmatic approaches to be adopted in the project. I had a long discussion with the team and everyone thought those were good ideas. But, everyone had higher priority on their plates and none of the good ideas were realized. I tried to put in some tests, refactored some of the code that I was working on so that it is testable. But, no matter what I did, it didn't seem to have an impact to the overall application. So, I gave up and went down to the code hacking path. I fell into the trap of Broken Window Theory.
The truth is, I lost focus. I care too much about the end result. I should focus on completing today's tasks to the best I can by refactoring the legacy code into testable code and refactoring long method into smaller methods using composed method pattern. I should fix one broken window at a time and not attempting to fix all the broken windows overnight. If I have done something to make today's code better than yesterday, I have achieved something and I should be happy about it1. I may not see a big difference as a whole but incremental improvement is the first step to improving the whole application. If I stay on this path, the developers around me may see the benefit of the good practices I am adopting and start following.
1. The Passionate Programmer