The dangers of utopia

If I waited for perfection... I would never write a word (Margaret Atwood).

(Like this article? Read more Wednesday Wisdom!)

I regularly sit in meetings where people say: “Well, of course, in an ideal world …”. After that ignominious start they typically go on to say things like: “We wouldn’t have two power strips fail at the same time”, or: “Customers wouldn’t send the same request twice within the same second”. Whatever they say, it is usually something that, though rare, definitely happens in practice. Might be rare, but definitely happens. When I hear a sentence like that, I often cannot control myself and then respond with: “In an ideal world none of us would have to have jobs”, because, let’s face it, we all literally have jobs because the world is far from ideal.

In an ideal world, all code would have perfect unit test coverage and so we would get away with using programming languages that are less than ideal when it comes to compile-time detection of errors. But then again, in an ideal world, there wouldn’t be any bugs in the code in the first place, so unit tests would be unnecessary.

In an ideal world, hard disks wouldn’t fail at inopportune moments so we wouldn’t have to write transaction logs to be able to recover from crashes. But then again, in an ideal world we might still have to write these logs in order to implement a high-throughput system. But, thinking some more, in an ideal world we might not need to do that, because computers would surely be fast enough to deal with any rate of requests without resorting to all sorts of tricks. In an ideal world, there are no bottlenecks.

In an ideal world, there would be no CPU bugs related to speculative execution. But then again, in an ideal world, there would be no attackers that would try to glean private data through micro-architectural side-channel attacks, so the bugs wouldn’t matter. But, thinking about it some more, in an ideal world you wouldn’t need speculative execution because the CPU would always pick the right branch to execute and would never have to discard the results from executing a mispredicted branch.

Would an ideal world have reality television? Doesn’t reality television exist only  because the world is not ideal and full of people who are definitely not ideal? In an ideal world, wouldn’t we all marry a multi-millionaire? But then again, in an ideal world, wouldn’t we all be multi-millionaires? But, thinking about it some more, why would an ideal world even have money to begin with? In an ideal world, wouldn’t everything just be free? And would that be ideal? In an ideal world, can I have a nuke? Or would I also be ideal in an ideal world and not want one?

The ideal world is maybe not a very interesting world. But then again, if it is not an interesting world, how can it be ideal? It seems that an ideal world would have to have enough actual problems to keep things interesting, but also great solutions to these problems that are just attainable and possible to implement perfectly, without any errors or bugs. Clearly, the ideal world is not easy to define and neither does it seem attainable. Which is another indication that we do not live in an ideal world, because in an ideal world, the ideal world would be easy to bring about.

We clearly do not live in an ideal world and neither do we know what a truly ideal world would look like, because it seems to me that a lot of what gives life meaning and purpose comes from the fact that the world is decidedly not ideal. So why do we keep referring to the ideal world?

The ideal world comes up often in code reviews. “In an ideal world”, code reviewers write, “this code would be structured like <this>.” But, as we have seen, the world is not ideal. We have to make this change and we have only limited time to improve the things around it. If not, where are we going to stop? What would the world look like if every one-line change would result in a complete refactoring to make the code ideal? Every code change requires a careful balance between just making it work and making things better.

Here is another place where the ideal world is mentioned more often than is useful: Design discussions.

The usual impetus for a design discussion is a non-ideal situation. All design discussions deal with some problem that needs to be solved and there are some thoughts floating around on how to improve the situation. Design discussions are firmly rooted in the thought that we live in a non-ideal world, because otherwise why would we be talking about solving some problem? Clearly, a world with a problem is not an ideal world.

Or is it?

Anyway, way too many design discussions seem to be predicated on the fact that we can actually move to the ideal world; if not for the world as a whole, then at least in this particular corner of it. These design discussions are completely hijacked by discussions about an ideal solution for the problem at hand, rather than just a good solution that would make everything better and that pays appropriate attention to the amount of time and money we have to execute this project.

I am not interested in “what we should really do”, unless that is something that we can actually do within the various real-life and far-from-ideal constraints that we have to deal with. The ideal solution might be hideously costly to implement and we don’t have that kind of money. Or it might take ten oodles of time to build, but we have only two oodles available. Or it might need everyone who works with the system to have twenty years of experience with the technology involved, but that technology has only been around for three years. Real life constraints suck, but they are real. Too many projects fail because of completely unrealistic expectations of what we will be able to do.

There is often really no need for the new system to be ideal. Sure, it needs to be good. It definitely needs to be better than what we have, but it does not have to be perfect. This is true for code reviews too: The new code (after the change) needs to be good, but just like new system designs, it does not have to be perfect.

We cannot afford the ideal world, but fortunately we usually don’t need it.

Here is a slightly tangential but still fun anecdote: Once upon a time I was doing some consulting with an international law firm that did a lot of interesting cross-border legal work, often in the field of corporate restructuring. Sometimes this led to teams of lawyers in Amsterdam, New York, London, Paris, Tokyo, and Hong Kong to be sitting in a video conference and enacting confidential legal documents at exactly the same time to make sure that the move to a new corporate structure was as much of a “big bang” as possible. Quite often the scope of their work involved material nonpublic information so there was an obvious need for secrecy.

I was talking to them about email encryption and using SSL and VPNs. One of their internal IT people was convinced that we needed to invent our own encryption algorithms because RSA and IDEA (the golden standards at the time) were already hacked by NATO, the CIA, and the NSA, and therefore offered no protection. I pointed out to them that inventing your own credibly good encryption algorithm is very hard and takes a lot of time and maybe we should use the best of what was available today until such time as our own crypto technology was ready (which I guessed would be never). I also pointed out that I thought that if the CIA wanted some information, they would probably not mount an attack on our encrypted communications; instead they’d probably just make an appointment with the senior partners where they would request some “voluntary” cooperation. Or they’d go to the home depot and buy a $5 wrench to beat someone up until they gave up the key.

It is okay for your design not to be perfect. It’s okay for the codebase not to be perfect. I am not here to make everything perfect, I am just here to make things better. Never let your critics compare your work to utopia.