The Dark Side of Lazy Programming

In my book on Lazy programmers (all free chapters posted at daconta.us), I cover the good, the bad, and the sometimes ugly side of Lazy programming. In the last article, we covered some of the good techniques (like lazy initialization) and now we turn to the dark side (dramatic, sinister organ music plays).

Luke, come to the dark side!

The dark side of lazy programming has three major categories:

1. Shortcuts and Band-Aids
2. Sweeping dirt under the rug
3. Avoiding architecture

Let’s examine the first category in more detail: Shortcuts and Band-Aids. In the program that I work on, I participated in our Software Improvement Group and often hear a recurring litany of complaints about bad practices like:

“The user interface feedback is woefully inadequate — we bury errors.”

“We need more training on concurrency because we are spinning up too many threads.”

“We need standards on logging levels because there is either too much or too little. Some people use Logger.error() for debugging and then forget to remove it from the commit.”

We then dutifully create confluence pages with standards and best practices which help for a little while until we get a new crop of programmers unfamiliar with our quality standards and prone to taking shortcuts. In the book excerpt, I just posted to my website, I demonstrate three types of shortcuts:

1. Brute Force Programming.
2. Lazy Resource Utilization.
3. Lazy Logging.

On their own, these habits above seem like minor deficiencies — the type of thing a nit-picking “old-codger” would worry about; however, these small infractions of laziness are what lead to the more serious categories of pitfalls — sweeping dirt under the rug and avoiding architecture. So, diligence to the small things will protect your team and the resulting software against a mountain of technical debt. So, be vigilant and don’t fall for those seemingly harmless shortcuts!