The Limit of Acceptable Terribleness (and coding)
This article about how awful programming is has been making the rounds, amongst my non-coding friends as well. It’s a great article, using witty analogies to describe the absurd underpinnings of the technical systems we take for granted. For instance:
“Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we don’t have the slightest clue what’s wrong with it, and it’s really easy to induce coma in computers and have their built-in team of automatic doctors try to figure it out for us.”
At times, it’s so true and slightly terrifying that it becomes more alarming than funny:
You can’t restart the internet. Trillions of dollars depend on a rickety cobweb of unofficial agreements and “good enough for now” code with comments like “TODO: FIX THIS IT’S A REALLY DANGEROUS HACK BUT I DON’T KNOW WHAT’S WRONG” that were written ten years ago.
Now, when reading this, you might think that we should stop the world, pay down our tech debt (what programmers call this backlog of work that we’d need to do to feel good about ourselves and sleep soundly at night), and then have a big party because the internet is Fixed! As awesome as that sounds, unfortunately you’d end up hitting The Limit Of Acceptable Terribleness (TM). That is, in any system there is a line of ‘good’ness below which people will address the problem but above which people will take shortcuts and procrastinate and generally decrease the ‘good’ness of the system. Thus, our system invariably ends up at the Limit Of Acceptable Terribleness.
That was a bit abstract, but this limit occurs in many places other than code quality. For instance, the cleanliness of an apartment will be just at this level; any messier than the Limit and a roommate will bite the bullet, tidying up and throw the gross bulging tupperware out from the back of the fridge. Above that level, the roommate will think nothing of leaving the cream cheese knife in the sink, even though the dishwasher is a few feet away.
So how is this different from a generic optimization problem? Well, it’s a subset of optimizations in which there’s sort of a ‘kink’ in the optimization, caused by an inelastic desire for the system to be ‘better’ than the Limit.
My favorite example (and one I’ll write a blog post on in the future) is commute times. People will continue to go for the cheaper house, the larger backyard, etc as long as their commute is shorter than about 2 hours. This causes a problem when you update a highway, for instance – within a decade or two, the average commute time creeps back up to what it was as more and more buy houses farther away, counting on the fast transit time. The engineers were trying to achieve shorter commute times for everyone, but hit the Limit. However, even if you could get land for much cheaper 2.5 hours away from the city, people who have to regularly commute won’t build a house there – the commute would be worse than the Limit and no amount of stainless steel kitchenware can persuade the commuter. Their commute would simply be an Unacceptable Terribleness. Again, the reason this is interesting is that tradeoff is not continuous between house location / size / price and commute time, causing a situation of Just-Barely-Acceptable-Terribleness.
The reason that the internet is so bad behind the scenes is that it is just barely Acceptably Terrible and if it were any less terrible we’d make a new language like Ruby for fun or profit and just end up right back at the Limit of Acceptable Terribleness. For those of us who haven’t achieved the zen of the Limit, everything is terrible. For those of us who have, “It’s just the way things are”. For those of us who think everything is awesome, please stop coding. Please?
2 thoughts on “The Limit of Acceptable Terribleness (and coding)”