What Compsci textbooks don't tell you: Real world code sucks

Bodged code, strapped-on patches, beellion dollar screw-ups... and that's the good stuff

The Power of One Brief: Top reasons to choose HP BladeSystem

Crappy software: Is it bad programming, or is it 'too good'?

The most common reason for the existence of bad software is bad programmers. Good software, misleadingly, is usually easy to read, but it’s not easy to write. There are an awful lot of developers out there who never learned the correct way to do things. Maybe they’re so enamored of a particular technology or coding technique that they insist on using it whether it’s appropriate or not (“If the only tool you have is a hammer…”). Maybe they’re in over their head on a project with a huge number of moving parts. Maybe they’ve been forced to pick up an unfamiliar language at a moment’s notice. Or maybe their thought processes just don’t translate into logical, supportable code. The best technologists will usually seek out the least boring work, or the highest compensation, but even the most exciting project may be staffed with bad programmers merely because budget constraints, or stinginess, prevented the firm from shelling out for more talented ones.

At the other end of the spectrum, many projects are sabotaged by developers who are “too good” — that is, people who insist on coding everything in the most complicated and impenetrable way possible. This may be because they feel the constant need to show how much they know, or because doing things the simple way is just not interesting enough. As one friend of mine, a heavyweight who has had to rewrite many terrible applications, once said to me: “They think that if they’re not writing 80 lines of code to add two numbers, they’re not using their education.”

In my experience, these people can cause more harm than anyone else. I’ve seen developers use the most tangled object-oriented techniques to do things that could have been accomplished much more easily with a trivial 10-line function. In C++, an everything-but-the-kitchen-sink language used heavily on Wall St, templates (to give just one example) enable this kind of behavior by allowing you to create the most esoteric generic classes imaginable.

In one case where I had to take over development from a C++ guru who felt the need to do everything in the most opaque, “sophisticated” way possible, his components simply had to be scrapped and rewritten from scratch. I couldn’t begin to understand the code, and neither could a colleague who was one of the best C++ developers I’d ever worked with. Four solid months of work in the trash bin.

If the original developer had stayed with the firm and finished the project, that would only have deferred the day of reckoning, since no one could ever have taken over support of this monster. (The joke name on Wall St for this kind of situation is “job security”: The sole expert on this system could never be sacked.) But even if the code had been marginally comprehensible, support would still have been a nightmare for anyone but the original developer, and it’s likely that a new person would have broken things by trying to make changes to delicate classes that he didn’t fully grasp.

Time-savers and face-savers

Another source of bad code is laziness. For programmers, there’s “good” laziness, which drives them to build tools that will relieve themselves and others of unnecessary drudge work — that’s what we’re here for, after all. And then there’s “bad” laziness, the kind that leads programmers to cut corners or do things in the quickest possible way, rather than taking the three extra hours to do them right. This always comes back to haunt someone—possibly the person who takes over six months later and doesn’t know that this tiny block of exceptional code exists, or why. Patches, almost by definition, are changes made without thought to the long-term consequences, and often sloppily, because they’re usually considered “temporary.”

For the record, however, I don’t think I’ve ever seen anyone go back and clean up a quick-and-dirty fix made two years previously just because it was the right thing to do. If the system is working, almost no manager will pay just to have you recode a piece of it “the right way,” without adding any new functionality. There’s always something more important that needs to be done—until that quick-and-dirty fix blows up and (because it’s urgent) gets replaced by another quick-and-dirty fix. To some lazy programmers, it must be said, none of this matters: They take the easy way out precisely because they know they won’t be around when their time bomb explodes.

There are languages that by their very nature make it easier to write bad code. As much as I love APL, a powerful language I once worked in that makes heavy use of Greek letters and other cryptic symbols, it’s easily abused, and I’ve seen some horrific APL systems written by people who hadn’t been trained properly.

(Unfortunately I had to support one such system early in my career. I prayed every day for a quick, painless death.)

Conway's famous Game of Life in Dyalog.com's one line of APL code

If, as an exercise, you wanted to write a program that no one in the world could make heads or tails of, the K language would make that a breeze: I once worked in a group that had a large codebase in K (which as it turns out is a distant, ugly relative of APL), and it never took me less than a half hour to decipher any one line of it.

As mentioned above, C++, despite its superficial similarities to Java, is infinitely easier than Java to write impenetrable code in. And one language I’ve been warned about, though I’ve never had the opportunity to use it, is Haskell, an offshoot of ML. According to a friend in academia who’s studied it, it’s “the Taliban version of ML,” in which it’s all but impossible to write readable code.

This Haskell line prints all the powers of 2 as explained on Stackoverflow

Ultimately, the greatest enemy of good programming practices is time. One of the reasons the code in your textbook is perfect and the code where you work isn’t is that the author of the book was allowed, or forced, to do things right.

In the real world, tight budgets, shortsighted managers, and unreasonable expectations from non-techies almost always conspire to make developers do things too quickly. The final product may be good enough now, and be perfectly understandable to the people who’ve just written it, but all that will change in a year, when there are new requirements and a new set of developers grappling with the hastily-thrown-together code. Additionally, the codebase in even a small production system can be orders of magnitude bigger than in most textbook examples, and large systems are far from easy to build. Despite protestations to the contrary, projects greater than a certain size and complexity (see the Reuters article cited above) are almost guaranteed to fail in some way without sufficient time for planning, design, testing, and adult supervision.

All the above aside, there’s one simple and completely painless way to prevent future generations from cursing you when they look at your code: Include some comments! ®

Securing Web Applications Made Simple and Scalable

More from The Register

next story
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
prev story


Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.