Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The 7 most vexing problems in programming

Peter Wayner | Nov. 8, 2016
Here be dragons: These gnarly corners of the coding world can be formidable foes, even for seasoned pros

It’s been said that the uncharted territories of the old maps were often marked with the ominous warning: “Here be dragons.” Perhaps apocryphal, the idea was that no one wandering into these unknown corners of the world should do so without being ready to battle a terrifying foe. Anything could happen in these mysterious regions, and often that anything wasn’t good.

Programmers may be a bit more civilized than medieval knights, but that doesn’t mean the modern technical world doesn’t have its share of technical dragons waiting for us in unforeseen places: Difficult problems that wait until the deadline is minutes away; complications that have read the manual and know what isn’t well-specified; evil dragons that know how to sneak in inchoate bugs and untimely glitches, often right after the code is committed.

There will be some who rest quietly at night, warmed by their naive self-assurance that computers are utterly predictable, earnestly churning out the right answers. Oh, how little they know. For all the hard work of chip designers, language developers, and millions of programmers everywhere, there are still thorny thickets of programming problems that can bring even the mightiest programmers to their knees.

Here are seven of the gnarliest corners of the programming world where we’d put large markers reading, “Here be dragons.”


It sounded like a good idea: Break your program into independent sections and let the OS run them like separate little programs. If the processors have four, six, eight, or even more cores, why not write your code so that it can have four, six, eight, or more threads using all of the cores independently?

The idea works—when the parts are in fact completely separate and have nothing to do with one another. But once they need to access the same variables or write bits to the same files, all bets are off. One of the threads is going to get to the data first and you can’t predict which thread it will be.

Thus, we create monitors, semaphores, and other tools for organizing the multithreaded mess. When they work, they work. They merely add another layer of complexity and turn the act of storing data in a variable into an item that requires a bit more thought.

When they don’t work, it’s pure chaos. The data doesn’t make sense. The columns don’t add up. Money disappears from accounts with a poof. It’s all bits in memory. And good luck trying to pin down any of it. Most of the time developers end up locking down big chunks of the data structure so that only one thread can touch it. That may stem the chaos, but only by killing most of the upside of having multiple threads working on the same data. You might as well rewrite it as a “single-threaded” program.


1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.