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

1 comment

Send me notifications when other members comment.

Please create a username to comment.

  1. "Display matches with no game data."
    You can find the solution in CH09_Matches_Not_Played_Yet (1 row).
  2. "Display all tournaments and any matches that have been played."
    You can find the solution in CH09_All_Tourneys_Match_Results (174 rows). how can i get the result?
Cancel

-ADS BY GOOGLE

SearchServerVirtualization

SearchVMware

SearchVirtualDesktop

SearchAWS

SearchDataCenter

SearchWindowsServer

Close