My primary focus for the month of March is cleaning up code. Before releasing the beta, my goal is to have a code base that’s prepared for change as much as possible. Change, as many developers might tell you, is the only constant in software development, and for a 1.0 product, I expect it to come often.
A few books are aiding me in the refactor process. One of my favorites so far is Clean Code by Robert Martin. The writing is concise and straight forward, with practical examples illustrating how you can clean up your own code.
I particularly like the introduction chapter, a sort of manifesto on why clean code is critical for long term product development. A great example is where Martin uses the analogy of a surgeon:
What if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
According to Martin, the same rule applies to programmers. Shipping code that’s messy because there is no time to clean it, is risky and unprofessional. The biggest risk is velocity of development slowing down over time, technical debt that keeps accumulating on top of itself.
John Romero, the creator of Doom also shared some great principles on the subject:
As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.
Romero echoes Martin: New code will be built on top of bad code if you don’t clean it up right away.
Stay tuned for more posts on how I’m cleaning up in prep for beta launch!