The things we know we don't know

I'm going to open with a quote from Donald Rumsfield, of all people:

As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know.

Ever since I wrote my first batch script for the Amiga 500 on one Christmas morning in the 1990s, this expression has perfectly captured my development as a programmer.

That Christmas morning was the only time in my entire career when I could say that the set of known knows was larger than the set of known unknowns. I read the little white technical manual, cover to cover, and for a few breathless moments, shrouded in the glorious perfection of my own magnificent ignorance, my knowledge was complete.

It didn't last. Soon curiosity to go beyond the manual took over and it was clear there were things that were not contained with it. Ever since then, the fraction of things I know compared to the things I do not know has shrunk on a daily basis.

Today, I stand here at 27 as an atom. If the sum of my entire knowledge of programming could be represented as a single grain of sand, the sea bed of every ocean on earth would capture the things I don't know about the field. The things I don't even know I don't know, is probably immeasurably larger.

It seems almost rude not mention the Dunning-Kruger effect at this juncture, yet I don't want to distract myself by it too much. It's clear that as time as gone on, cocksure certainty has given way to qualified doubt.

In fact, this doubt affects everything we do. There is a doubt paralysis that occurs where you are so aware of the limitations of your own knowledge that you're afraid to work on anything for the fear that you're programming sub-optimally.

  1. Do I use NHibenate or do I use Entity Framework?
  2. Do I use a recursive decent parser or a LL parser?
  3. Do I use Quick Sort or Merge Sort?

It's even worse in that when you start a project, you can never really anticipate what area of the code you will call technical debt later on. This leads to a sort of object model agony, where you're so cautious about creating a dependency you will regret later on, that you redesign the redesign of the redesign in the hope of avoiding traps that are inevitable anyway.

This is the horror of the things we know we don't know.

And throughout all this careful deliberation, your project refuses to exist. It isn't there. It's bubbling around in the back of your head never making it in to the world because you're so scared of your own shadow.

And then I had come full circle. The 13 year old Simon with his Amiga 500 got somewhere, in spite of his stunning ignorance, because a project that exists in reality - however flawed - is better than one that exists as a fantasy.

In a world where every day the horizon of what is unknown grows, the best we can ever do is develop with incomplete information.

  1. Sometimes we will have to make design decisions that we know to be ultimately flawed, in the name of bringing something in to existence that might otherwise have not.
  2. Sometimes we will make decisions that have an unanticipated effect later on.
  3. Sometimes, we will not even actively decide on something that later on becomes crucial.

Surrender in the face of these uncertainties is subjecting us ourselves to creative poverty. Existence, at the end of the day, is a feature and not a bug.

It is better for your project to imperfectly exist than to have never existed at all.

  1. 2011-04-15 14:40:00 GMT
  2. #Programming
  3. Permalink
  4. XML