Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Is it acceptable to write sloppy, inefficient, bloated code -- or just easy?

Decades ago, legend has it, many programmers got paid based on the number of lines of code they wrote. The more you produced, the better you were perceived to be. The inevitable result, not surprisingly, was mountains of bloated, inefficient code. Are we coming back to it?

Once organizations wised up to the foolhardy belief that those who produced the most code were the best, the push was on to write tight, concise, efficient code. After all, in the mainframe days when you typically had only 64 kilobytes of magnetic core memory to work with, throwing more iron at slow-running applications was a very expensive — and usually impossible — proposition. Though tools existed to exercise all the code in a program for logic errors (including hopefully never used exception processing routines), analyzing code for inefficiencies — such as poorly designed “perform until varying after” loops in Cobol — was something of a magic act.

What eventually changed was the plummeting cost of compute resources and memory. Once you were able to throw a shelf full of inexpensive Compaq Systempro servers and NetWare 2.15 at a problem, it was often easier to solve slow execution with more hardware than it was to hunt down poorly written lines of code. And now with megabytes of memory available for programs to run in, the need for memory management (anyone remember writing overlays?) began to disappear.

I fear the problem of bloated code, slow execution, and software quality is not getting better. We’ve made it easy — and perhaps necessary — to create inefficient code.

Today, we have business cycles that demand huge changes in application functionality almost weekly instead of once every two years. There’s simply not enough time to go back and fix inefficient code that was rushed out the door. Compute resources, including processing power, gigabytes of memory, and petabytes of storage, are so cheap as to be nearly free in comparison to mainframes. With cloud, it’s easy to scale infrastructure resources by orders of magnitude and do it almost instantaneously. No-code / low-code tools are generating code for us, but how good is that code? With streaming analytics we can examine everything, whether it’s central to the direct creation of revenue or not. Developers can easily tap into an enormous number of reusable libraries with a full understanding of what they do but no insight into how well they do it. Even with the API explosion that is upon us, we scrutinize their security while their performance efficiency likely is never called into question.

Is the idea of writing phenomenally tight code simply passé? Are you continually under the gun to get your code working, ship it, and move on? Are you proud of the code you write? No doubt you’ve thought about this before. Share those thoughts with us; we’d like to hear from you.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I'd ask what's the basis for this (any objective source or this anecdotal observation)?  Also I'd ask who is the arbiter of what's sloppy or not?  Finally, I'd suggest since most companies are "doing more with less" (in all senses of the word "less") that this, combined with the easy availability of system resources, added to the fact it can take a lot longer to optimize to the nth degree, makes it unrealistic (undesirable, even?) to do this type of optimization on anything other than critical code.
Over the years I have seen a lot of  "down and dirty" programs and applications. Most of these were written as one time use. They were held on to just in case they were needed again.. They may not be the cleanest or most efficient but they work. IF time ever permits the luxury of being able to go back and performance tune these it would be nice. 
The larger problem with down-and-dirty programs and applications written for one-time use is that many live on to see another day, another year, or sometimes, even another decade. When code runs error-free, few dare to tread — or re-tread — for fear of breaking something that is not in need of repair. 

It's hard to disagree with the premise that slow code which works is better than tight code that crashes. On top of that, application maintenance was often the domain of junior programmers just learning the ropes while those with heavy experience always seemed to work on something new.