News flash: I’m not perfect. Chances are you aren’t either. When it comes to writing programs there’s (almost) always a better way to write code. And by this I mean the solutions for solving problems evolve. Sometimes it’s a new bit of information, sometimes a new tool, more often it’s a bug.
Despite the technical nature of laying down code I tend to think of it more as an art form, of sculpting paths of logic and structures of data. It’s the decomposing of a large, complex, multifaceted task into bite-sized components that can be written in reasonable time and perform without fail. Everything from what is the class hierarchy to what CSS class names you ought to give to DOM elements. And when you stand back and look at what has been created there is almost always room for improvement.
I love DRY (Don’t Repeat Yourself) and that’s pretty much been my motto ever since I started learning to do this. I abhor cut-and-paste solutions—I’d rather make a reusable code chunk. I love using flexible parameter lists that allow future compatibility. I love neatly-indented code that reads cleanly. I love enforcement of naming conventions and directory stuctures—things are always predictable. I am strict about writing comments and notes. I love refactoring.
But the Business side of the company often doesn’t like that word “refactor”. It means more work. The question could be: “why didn’t you write it correctly the first time?” Or perhaps: “we’re already tight on resources, why do you have to waste time rewriting something that will inevitably change?” I ask myself the same questions every time I approach a situation where I see the opportunity to refactor or clean something up. In the end if my gut feeling says “yes, refactor” (and I can make the time) I usually do it.
Ever since quitting the big companies and joining startups in 2006 there has been this constant pressure to produce, produce, produce. There’s never enough time and we’re always short on every resource imaginable—so why bother to refactor? It’s more important to get to market! Every microsecond that we don’t get this version of our product out there means potential lost customers or revenue!
While it’s true that sometimes you do have to make sacrifices to rush to the deadline, what I’ve learned in the world of startups is that there is always a deadline. And more often than not they end up being soft deadlines. There is always something that goes wrong and there’s always some business circumstance that pops up at the last moment. So the deadline just keeps slipping out. Eventually someone gets fed up enough and says “OK, we’re going to start cutting features in this release so we get stability!”, and a line is drawn in the sand. It’s like running the 100-yard dash but the finish line keeps moving until everyone realizes that the runners are completely out of breath. Worse yet, after crossing the finish line the announcer says “OK, we’re starting the next round now, so keep sprinting!” This is just unsustainable. You never get the time you need to revise your work. Ever.
So, I’ve taken to a new line of thinking: when you see a problem or an opportunity to refactor AND it’s something that is going to be really important later then STOP and refactor now. Since there’s never going to be enough time you just have to make the time. The PMs and business side hate that. It means more features slip. It means deadlines get missed sometimes. But what I’ve found, especially with my current project (where I’m the primary/only coder), is that the code gets better and better. Sure, it started out a little raw because you weren’t necessarily aware of all the places to modularize, repackage, consolidate, rename. But over time these pain points become obvious. Plus, there’s always improvements in performance, improvements in how you pass objects around, better ways to lay out the user interface. Oh and all the while you are learning new things and new open-source solutions are always being unveiled on the Internet.
Bottom line: it’s better to harden the code at every opportunity.