Laziness is not a virtue of a programmer

In the late 1980:s Larry Wall stated that one of the three virtues of a programmer is laziness (the other two being impatience and hubris). With that in mind he created Perl, or possibly the order of the two events were the other way around.

After about 10 years of doing software development commercially I would like to argue that laziness is not a virtue of a programmer. My intention here is not to dis Larry based on a line taken out of context. Larry is after all much of a hero to an entire generation of system administrators and programmers. Perl also came to drive many of the first attempts at e-commerce and interactive web application, making a large contribution to the development of the web as we know it today. So, with that in mind, it is apparent that laziness can help you go places. But being lazy can also get you into all sorts of trouble.

Laziness may not be a virtue, but it sure seems to be an integral part of human behavior. I have to fight my own laziness everyday. When you have a task to complete it is often very tempting to do a fulhack* here, add an extra if-statement there, and hardcode some piece of information over in that end, i.e. do things that you know are wrong, but are very appealing for some reason. The right thing to do in these situations is typically something along the lines of rewriting a few more lines of code, extract a method, move a scattered responsibility to the class where it really belongs, etc.

The shortcuts are quick wins; you fix a problem momentarily and you can move on to other tasks. But as these quick wins starts to accumulate, it becomes even harder to stay away from them: "The code is ugly anyway, another one of these won't really matter now, will it?" This is the Broken window theory in action. And soon, your code is full of ugly hacks. Hacks that make the code hard to read, hard to understand and hard to maintain. Hacks that increase the entropy, or Technical Debt. All these things lead to a system that is more difficult and expensive to maintain. A system that is hard to change and extend with new functionality. A system that smells and no-one wants to work on.

So just stop being lazy. Pair-programming is a great tool to help you out here. It is much harder to write intentionally ugly code when someone is looking over you shoulder (or even stealing the keyboard).

Tim Ottinger has written an interesting piece on code as a liability.

Larry Wall on the virtues of community: Diligence, Patience, and Humility

*a 'fulhack' is a Swedish term for an ugly piece of code that you know is bad. But despite this you write it and leave it in the system you are working on, usually because you're too lazy to do it the nice way. A fulhack is typically annotated with some sort of code comment where the author clearly states that it is a fulhack, admits guilt and that way tries to escape responsibility. Which of course doesn't work...