I’m a lazy person. I consider it one of my best qualities, and it’s because I’m lazy that I’m a good developer. This may seem odd at first, but consider that much of software development is abstraction, which is really just a nice way of saying “finding ways to reuse things you’ve done before to avoid having to do as much now.”

If I spend a coffee break today automating a common task and I’m able to shave even a few minutes off it, I may earn myself an extra coffee break tomorrow and every day after. This is just the concept of investment, which is already widely understood in business.

Or is it? False economies are all around us. One of the fastest ways to improve the work that you do is to be conscious in eliminating these false economies. Let’s look at a few examples.

Perhaps the most common false economy in development is copy-and-paste programming, also known as snarf and barf (I like to call it paste-driven development).  We all do this from time to time: a method above has a few lines of code that are almost what we need, so we copy them to where we’re working, make a few tweaks, and away we go. This false economy is very seductive (“why type something all over again if it’s mostly the same?”).  But it has three fatal flaws.

First, there’s often not as much in common as you initially think. If the passage is short there is probably less you will have to change, but there is also less reason not to just type it out. As the pasted section grows longer, the amount that must change increases, as does the chance of error.

In my experience, developers spend far more time dealing with trouble caused by copy-pasta errors than they would have spent simply typing the code in the first place. If you find that isn’t true spend some time improving your typing speed.

Second, duplicating the code is a replacement for the real solution, abstraction. It is all too common for classes to accrete by the gradual addition of many repetitive elements.  Fighting these forces requires constant refactoring and a disavowal of PDD.

A common programming idiom is Don’t Repeat Yourself.  Frequently developers will apply the Rule of Three: you can do something twice, but once you do it a third time you must abstract it. When a passage is pasted once, it is almost inevitable that it will be pasted again. This is what leads other developers to the Rule of Two: there are only three numbers: zero, one, and infinity.

Most importantly, pasting code numbs the mind, and a developer’s mind is her greatest asset. Pasting is a substitute for thinking. Part of this has to do with abstraction as mentioned above, but it goes far beyond that. When you paste code you actively prevent yourself from considering the problem you are trying to solve.  That is, after all, the very point of the clipboard.

A special case of paste-driven development is Google-and-paste programming. This unfortunate style removes the developer entirely from the development process.

Another common false economy in development is something I refer to as haste-driven development.  The conditions are all too prevalent: deadlines are imminent and a partial solution is in place. It seems like if we do things the down-and-dirty way “just this time” we can put a band-aid on the problem. Other times I see developers practicing haste-driven development as a matter of course, probably because they are so used to the process.

HDD manifests in many ways: writing lots of code and leaving the tests for later, growing a single method rather than composing multiple, failing to refactor code to reflect new information.

This last one is the worst for the long-term maintainability of your system. Software development is a learning process, and the software itself must come to embody the collective knowledge of the team. This means that as the team learns new information, it must be incorporated into the working software or inevitably it will be lost to the frailties of human memory or organizational change.

This essay was inspired by this page on Ward’s Wiki.