False Economies: What I've Learned as a Developer

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. A false economy is an action that saves money or time at the beginning, but proves to be much more costly or time consuming in the long run. One of the fastest ways to improve your work is to be conscious in eliminating these false economies. Let's look at a few examples.

Paste-driven development

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, because "why type something all over again if it's mostly the same?" However, this approach has a few fatal flaws.

First, there's often not as much in common as you initially think. If the passage is short there is less you will probably 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 copying and pasting is an acceptable option, you should improve 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 paste-driven development.

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, a developer’s mind is their 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. 

A special case of paste-driven development is Google-and-paste programming. This unfortunate style removes the developer entirely from the development process. That is, after all, the very point of clipboard. 

Haste-driven development

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.

Haste-driven development manifests in many ways: writing lots of code and leaving the tests for later, growing a single method rather than applying a composition, 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 blog post was inspired by this article on Ward's Wiki.

Are you looking for cloud application development? For over 10 years, Bluewolf's custom application development team has helped businesses build innovative cloud applications that make organizations more efficient and innovate their business processes.

 


Bluewolf, an IBM Company, is a global consulting agency and proven Salesforce strategic partner that builds digital solutions designed to create results. Now.

Get The Best of Dreamforce