Letting Go

I was having a discussion on irc the other day with apeiros about a number of topics and we had a minor tangent about control:

apeiros_  : I don't like it
apeiros_  : simply because it inverts control
apeiros_  : and causes havoc on bug detection
apeiros_  : surprises me actually that you're not one of
            those who'd prefer having control
zenspider : actually, I'm fairly anti-control
apeiros_  : with your variant, it *might* be that you *might*
            have wanted it, but maybe not.
zenspider : "might" is key... that is the lack of control...
            I'll let the objects sort it out.
apeiros_  : so your objects know more than you?
zenspider : yes... they often do
apeiros_  : ouch, then.
zenspider : not ouch... that's their job
apeiros_  : to know more than you?
apeiros_  : I doubt that :)
apeiros_  : you should have the whole picture.
            objects should only know what their concern is.

Tonight I came across a quote that struck a chord with me (no pun intended):

"The thing about musical instruments is that it should be on the verge of falling apart. That is where the line is. If it's on the edge of falling apart, you've probably made a pretty good instrument."

Danny Ferrington, Master Luthier, DVD Extras on The Ladykillers.

The message I was trying to convey was very related. If you build a guitar that is too strong, it won't actually move any air and no (or bad) music comes out. If you build your software in a similar manner, it won't do anything or it will do it so poorly you don't want to use it (and you certainly don't want to work on it anymore).

Instead, think of objects as having their own responsibility. It is your job to bring objects together, but let them do their jobs w/o micromanaging. My best software has always been written such that I bring objects together, and just say "now, go" and let them do their thing.