Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

7 bad programming ideas that work

Peter Wayner | Aug. 16, 2016
Cheaper, easier, faster, safer -- sometimes bad habits are better than good enough

Anyone who has listened to a teenager, sports commentator, or corporate management knows the connection between words and meaning can be fluid. A new dance craze can be both “cool” and “hot” at the same time. A star player’s “sick moves” don’t necessarily require any medical attention. And if a company is going to “reorganize,” it’s not good for anyone, except perhaps the shareholders -- even then it’s not always clear.

The computer world has always offered respite from this madness. No one stores “one” in a bit when they mean “zero.” No one types if x = 0 when they really want to say if x != 0. Logic is a bedrock that offers stability in a world filled with chaos and doublespeak.

Alas, when you get above the ones and zeros, even computer science isn’t so clear. Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it’s too hard to do things the right way. In other words, sometimes bad is simply good enough.

There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it’s the way to go. If we’re stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there.

Here are seven truly bad programming practices that all too often make perfect sense.

Quick and dirty code

Few things can kill a project like poorly designed and poorly documented code. Even if your slapped-together stack stands up, maintaining it will be a nightmare. And anyone who inherits your steaming pile of bits will be a sworn enemy for life.

Then again, quick and dirty code has its place. In fact, the pursuit of clean, thoroughly engineered code can be costly. I once worked with a programming manager who looked everyone in the eyes and cited a long list of ways that our software needed to be cleaned up. Our old code may have been running, but the company would dole out another two months of budget to make sure the lines of code were presentable. Sometimes our programming manager would ask for six months’ worth of budget and she would get it. After all, who wanted unclean code?

Not everyone has access to that kind of budget, and few want to tell budgeting managers to cough up another N months of developer time because clean code is best.

Worse, cleanliness is often a slippery concept. One programmer’s clean code is another’s overly complex code. Often cleaning up code means adding new abstractions and layers that make it clear what the code is doing. This can quickly become TMI. Sometimes quick and dirty code is better than complex “clean” code that is paired with documentation on par with "War and Peace."


1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.