Distinction Driven Design

One of the most frustrating issues I have with doors (and apparently it’s genetically inherited by David!) is their inherent direction ambiguity. Looking straight at a garden variety door- can you tell me which way it opens? Does it open towards you? Away from you? Does it swing both ways? The only practical way to determine the direction of this interface is by testing.
Would you care for an Api in your programming language of choice that contains such vagueness? Consider a series of DataAdapters with methods like Process, Do, OpenOrSave… Now some consider putting a label on a door a good enough solution. But that’s just like plugging a hole in a dam with your finger. Another one will spring right up. Some people can’t read, some don’t understand your language and most of us don’t bother to read. When was the last time you read code comments? When the damn thing stopped working, right? Sure I read those– right after I crash my head against the “pull” label.
So I’m watching David successfully navigating all sorts of door handles (push, pull, turn or raise handles) while still having problems figuring out which way the door swings and it got me thinking. There’s something inherently wrong about out door designs. If David can figure out how to turn off my computer he should not have problems with 19th century doors should he?

Handling

One of the most important aspects of interacting with the environment is shape recognition and object handling. Not surprisingly many of the so-called didactic toys supposedly teach your baby how to distinguish, grab and hold various shapes.
But simple cubes and pyramids are easy. The most difficult shapes are food items. You see it’s easy to recognize, grab and bite a sphere (provided it fits in your mouth!) but food items are more interesting.
I was watching David eat a cookie. This particular cookie is square shaped and as such is easy to recognize and hold. With each successive bite though – it changes shape. It becomes a square with a bite taken out, then it’s a kind of a triangle with a jagged edge, next it becomes almost a trapezoid… The wonderful thing is – it’s still a cookie and David has no problem understanding this. I know it’s common sense to us but that’s because you’ve learned that food items rarely change into non-food items just because you’ve taken a bite (interestingly, David does not recognize a banana without the peel).
An item that changes shape presents a difficult handling problem. You can teach a robot to hold an apple but that won’t help it hold a cherry. David must continually modify his gripping technique and be attuned to dangerous cookie fault lines. One false nip, one careless pinch and the cookie crumbles and escapes to the floor! Still, utilizing the Failure Driven Approach™ David more or less successfully eats a cookie by himself. A breathtaking testament to the triumphant progress our project is making. Go David go!

The Ministry of Failure

It’s interesting to observe emerging behavior in David, seeing his ideas and solutions not provided by me or mom. You begin to see how much your life is constrained by common sense, how your vision narrows with the accumulation of knowledge. It’s inspiring!
David’s learning path is not so much of following guidance – something we are taught throughout our lives. He trusts no authority and tests even the unlikeliest theories. He might like the taste of a squashed banana – but he will try to see if it tastes better if he squashes it himself, with my Logitech (cordless) mouse, while leaning against the TV and singing...
David’s an avid believer in The Ministry of Failure. To become better, you need to fail. To quote Niels Bohr: »An expert is a man who has made all the mistakes, which can be made, in a very narrow field.« Perhaps this is the next development paradigm that will surpass TDD (and if so – I claim copyright!). I call it the Failure Driven Development.