Several years ago, a coworker of mine made a statement that I still consider pretty profound. To paraphrase, he said that his career goal was, over his lifetime, to delete more code than he wrote.
It’s a simple statement that at the time I thought was a pretty good idea – after all we were about a year into coalescing a whole load of separate code bases into a single one and we’d already done a lot of slashing of redundant stuff. But the more code I write and the more I think about it, the more I think that his goal is nothing short of software genius that we should all strive to achieve.
I’m going to call the measurement of this goal a developer’s Delete-Write Ratio, or DWR, calculated quite simply as [lines deleted]/[lines written]. If you do a lot of deleting, it’s going to be > 1. If you do more writing you’re going to have a DWR < 1.
I imagine that over the span of a career the number is going to start really low as a fresh developer who thinks he knows everything but really knows close to nothing and then creeps up as you gain knowledge. I’m also willing to bet that very few developers ever reach a value of 1.0, so if I achieve even close to a 1.0 DWR I’ll be really happy.
Of course when you spend a majority of your time working in an existing code base, it’s usually a lot easier to find “opportunities to delete” than when writing new code. Since a large amount of what I seem to write is from the ground up it’s difficult to keep my short-term DWR above one. I’d propose that developers who are primarily writing new code should amend their goal to make it as difficult for the next developer to achieve a DWR above 1 as possible.
What that means is that, as a developer, you need to justify the existence of the code you write. This doesn’t mean you need to write cryptic code that others can’t read but it does mean that the code you write needs to have purpose. If two sections of code have the same or similar purpose, then you’re making it easy for someone else to refactor and raise their DWR.
So what can we, as developers trying to make our way through our projects and meet the deadlines foisted upon us? There are the easy things, like using existing code instead of reinventing the wheel and constantly looking for opportunities to refactor not just existing code but also code as we write but more important is to discipline ourselves. Don’t give in to schedule pressures that make you think that copying that code file and making a few tweaks will get you toward your goal. Use inheritance and base classes or refactor to a generic.
Any time you find yourself using copy-and-paste a big red flag should go up. In fact, I think an awesome Visual Studio add-in that would aid code quality would be something that prevents copying and pasting any more than 2 lines of code at a time. Seriously, if you are pasting more than a couple of lines of code, it’s very likely that you’ve got an opportunity to refactor.
Even though our lives revolve around the code we write (at least our lives with respect to our jobs), code really is the enemy. The more code you have, the more bugs you have and the higher your support costs. Obviously the perfect, utopian-as-unicorns software would be that which meets all of your customers’ needs and takes zero lines of code to do so. Until we figure out how to work that kind of magic, though, we have to settle for less-than-perfect and lay down some code. But when you’re writing that code ask yourself, “what is this doing to my DWR?”