Soluble Code

I had a discussion with someone today that reminded me of this post by Scott Bellware. Go read it: Soluble Code.

Specifically we were discussing design conventions and how they help (or hinder) the people that follow them (or don't). Once again I had to make the point that code is read far more often than it is written. It's important to have solid conventions in place so that we can understand each other and work towards common goals. Otherwise the end product will have all of the permanence of the Tower of Babel.

I've noticed a strange cognitive dissonance with some programmers. On the one hand they claim to value code clarity. But on the other hand when they get stuck they labour under some misapprehension that it really won't matter what goes on behind the curtain because no one else will ever see it; or so they believe. These seem to be the same programmers who have difficulty grasping the Law of Leaky Abstractions and who cannot be trusted to design a sensible API with more than 3 functions in it because they'll try to make it "simpler" by squishing all of the behavior together with as many "helpers" as possible.

Trying to hide ugly and complex code is just a sure-fire way to ensure that you're stuck with it for life because no one else on the team will be interested in maintaining it. So don't do it. It makes me sad because I have only occasionally been successful in reaching out to these programmers and teaching them to think more critically about what they're building.

Of course I too suffer from occasional delusions. I like to believe the fiction that insoluble code will eventually get ejected from the system (like dietary fiber). But it does seem to take quite awhile to digest sometimes...

P.S. Oh yes, and No Broken Windows!