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?

Multiple inheritance issue

It turns out I was wrong about baby class inheritance. In addition to the abstract baby class (,which is responsible for most of your problems!) babies inherit a few things from both you and your partner. It’s a classic case of multiple inheritance and all that jazz.
The most important feature of any MI system is conflict resolution. How does the inheritor decide which inheritee implementation of a common method to use? Predictably – it tends to use the worst possible configuration it stumbles upon. What does that translate to?
For example: Mom likes to keep it neat while I like to crumple paper before throwing it in the tin can. The resulting combination at breakfast time is David keeping his part of the table neat by crumpling his toast and eggs and throwing them in the direction of the tin can.
I guess we have a few bugs to iron out here…

David’s Toribash

At toddler stage you’ll see a rapid development of your baby’s mobility. Early stages of motion control will seem uncanny like Toribash. Each movement is overdone, each countermove over amplified and the end results wonderful and often scary. There is no gradient of control, if a limb needs extending - it is extended to the full. Whether your head is in the way or not.
Toribash effect isn’t limited to physical movements only. The same effect can be observed in your baby’s psyche. If laughter is required - it’s as loud as a train, if there is cause for tears -they flow a waterfall.

Interfacing the environment

I’ve been reading Joel Spolskys User Interface Design for Programmers which is a useful paradigm shift for most programmers and it got me thinking…

I have quite a far amount of trouble keeping David from pressing the reset (and off!) button on my computer. Why is that? Why is he so interested in pressing that particular piece of plastic? He certainly has no idea of what it does or that it does anything.

It’s because the button invites pressing. It’s designed by professionals to look like something that can or rather should be pressed. That’s why David feels the need to turn knobs on the oven, handle the remote control, open closed drawers and rarely plays with his toys.

Toys designers got it all wrong. It’s not about the vivacious colors or the high pitched sounds. It’s about usability. So I’m off to buy some toys with interfaces!

Basic design flaws (part II)

Subtitled: Inheritance

Despite what you might have learned at sex class – your baby does not inherit from you. Babies inherit from an abstract baby class. The bad news is over 90% of class methods are abstract and need implementation. The other 10% need redesign.

As you may have noticed – the designer of the abstract baby class had no clue and surely had no experience in OOP. Case in point is the “eat (object food)” method. You might think that putting any object as food would do. Certainly there’s nothing in the method signature that suggests otherwise. You would be wrong! You see, babies need different kind of food objects at different stages in their development. You’d think the almighty class designer would consider other solutions to the problem, but nooo. It’s up to you to know how your baby works and what to feed it and when. Talk about encapsulation…

As previously stated, the baby does not inherit from you. You see, none of your class methods will work in a baby. You need to write them from scratch. The good news is none of your spouse methods are implemented. So she needs to program them too.

And guess who’s a better programmer!

Basic design flaws

Subtitled: Structured error (non)handling

Babies are purely designed classes. They suffer from basic design flaws which must be corrected before they are ready to be let out into the world without supervision. Case in point is the umbilical cord. You know what the umbilical cord is? It’s a classic case of broken encapsulation.

When a baby error occurs it’s caught and wrapped into the most general exception you can imagine and thrown out at you to handle. Not only do babies not even attempt to handle the problems themselves, they even hide any error information that may or may not be known to them. The only message that gets through the communication channel is a loud audio signal designed to wreak havoc on your nervous system.

The stack trace usually returns a simple: “…error at Baby.Sleep(54000);”.

So debugging babies is next to impossible. It’s more akin to voodoo science then debugging. You do A and the baby does B. Great! What you don’t realize is that you doing A has more chance of causing rain then for your baby to do B again. You see, your baby is probably not even reacting to your A. She stopped crying because there was a slight movement in her bowels she’s now investigating. You could be levitating in a lotus position and she wouldn’t flinch.

Also – babies tend to develop much quicker then you can follow. Whatever worked yesterday is old news. Sounds that stopped the crying instantly now only make it worse. How is a developer versed in structure, logic and control expected to deal with this? Well, think of it as working on a team project. Except you and your “team member” don’t communicate and he keeps changing your code without telling you about it. Now that is a familiar situation isn’t it?