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?