, , , , , , ,

xkcd #2030 by Randall MonroeI cracked up when I saw this recent xkcd cartoon. Randall Munroe rarely fails to deliver, but this one especially caught my eye. It’s painfully on-point and quite dismaying on at least two points:

Firstly, that it should still be this bad given all the time, money, and attention, it has received is reason alone for dismay. Part of the problem here may be that we haven’t admitted how hard software is to get right.

But, secondly, software is central to our lives now — far more than airplanes, and even more likely than elevator rides. You might ride an elevator, at most, a dozen times a day, but software enters your life more times than that.

Especially if you use a mobile computing device!

It might have to do with having learned software design back in the 1970s when resources were expensive and scarce. Memory, for example, was minuscule compared to, not just today, but 20 years ago. At one time 16K of RAM seemed like a lot.

Likewise, the first 5 Meg hard drive I saw for a PC blew my mind. So much space! That’ll be impossible to fill up!

And, the legend is, Bill Gates once said, “640K RAM is enough for anyone!”

It’s possible learning to write code in such lean times gave one an innate sense of necessary elegance.[1] Or maybe it was hard to hide behind cruft — there wasn’t any room for it!

I suspect the over-use of libraries has something to do with it, too. I saw a co-worker once import a decent-sized Java library just to use a CSV parser — easily written code amounting to a dozen lines or so.

In fairness, there is a counter-argument: “Re-inventing” your own wheel risks adding bugs of your own creation, whereas using a tested library gives you bug-free code.

Ah. But what if the library wasn’t that well tested — you’re trusting someone else to get it right and may have no access to (or no time for) seeing the test results or the code.

And in the case of actual “re-inventing,” I would lean towards a library myself. Don’t waste the time. But this isn’t re-inventing wheels. This is building them yourself when it’s faster, easier, and more reliable.

Assuming you can code without shooting yourself in the foot, which turns out to be less likely than we’d like. And which is the point of this blog post. (As it turned out, it was probably best that co-worker used the library.)


Which is a big part of the problem: Bad Coders.

Generally they’re people who’ve taken to programming for reasons other than “the call.” They thought it would be lucrative. Or it was the thing now days.

The really good programmers I’ve met are those who took to it strongly and immediately. Those for whom it was like walking through a door to a new, magical land.

Those who went on to take it very, very seriously. A true calling.


Fact is, software is hard. Really, really  hard. It requires serious effort to get right.

Although here’s a scary thought: Those airplanes and elevators mentioned in the cartoon? They increasingly rely on software.

I remember the outrage caused by early installs of a high-tech elevator management system at the corporate offices. That software was a different kind of bad. Not the bad of bug, but the bad of failed human engineering.


Which is some regards is a stronger complaint I have: Software that sucks to use. But that’s a rant for another time. For now, I’ll leave you with something Carl Sagan once said:

“We’ve arranged a global civilization in which the most crucial elements — transportation, communications, and all other industries; agriculture, medicine, education, entertainment, protecting the environment; and even the key democratic institution of voting, profoundly depend on science and technology. We have also arranged things so that almost no one understands science and technology. This is a prescription for disaster. We might get away with it for a while, but sooner or later this combustible mixture of ignorance and power is going to blow up in our faces.”[2]

This is even more true today, and there’s now a double-gap: The one between how well most people understand their technology — the gap Sagan mentioned — and the gap between our increasing need for good, correct software and the reality of the software industry today.

We. Are. In. Trouble.

[1] A decent working definition of (engineering) elegance: A solution achieved with minimalism, effectiveness, and symmetry. A solution that is so clearly correct it hints at being the best possible.

[2] Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark, 1995