What Your Child Can Teach You About Server Architectures

A crying child is a very common occurrence in my life. My 4 children range in age from 10 to 6. I know. I am better at math now, but back to the crying child.

One of the first things I learned when a screaming child comes running to me is exactly how to triage the situation. After scanning for blood, you might think the next most useful thing would be to see where the kid is holding on to himself/herself. This can be extremely misleading, though. It turns out children often guard their entire bodies when they are hurt and I can’t always tell at first glance where they are hurt.

Keep in mind that while I am checking them over physically, there is a lot of noise going on. A lot. The white noise volume is high and the snot-filled blubbering essentially assures that asking them where it hurts will provide no additional data. So, what do I do to quickly triage?

I take the kid’s head gently in my hands, one hand on either side of the face. I get down close to their bellowing pie hole. I say in a voice just loud enough to cut through the shrieking without yelling myself, “Put your finger where it hurts.”

It works every time.

Self diagnosing systems are great! I merely have to issue the “Point to what hurts” instruction and the system replies with a runtime generated component identifier.

This is how any server application should actually work. Why must I pour through various transaction logs to see what is locked? Why must I bring up Task Manager 9 times per day in Vista? Reserve resources for a diagnostic thread to execute on command, returning the name of the thing that is locked up. Frankly, no one should be better at diagnosing the runtime environment than the developers who created it.

Just like me with my kid. Kinda.