Trust In Thee

I subscribe to a blog about coding whose audience seems to be .NET developers. I keep asking myself why I keep it in my list of feeds. The answer comes in posts like this one where they discuss what to do when a design surpasses the ability of the coders that maintain the application. It's an age-old problem that has been around since programming began and will be alive and kicking far longer than you or I.

I'd say there are at least two flavors of this. There is the code written by the Code Cowboy who feels that if you can't read his code then tough luck. I actually ran across an example of this where the said coder left a warning in the comment for the afflicted function. To paraphrase it said "Warning, really nasty code ahead. Don't touch anything you don't understand. Don't say you weren't warned." This essentially expresses the opinion "If it was hard to write, it should be hard to read."

The second is a bit more thoughtful. For those applications that are big enough and have been around long enough to need a good size maintenance team, it's possible for some design retro-fits to outstrip the capabilities of some of the support staff. While it is true that it might indicate that the design is too complex, more often than not the design expects developers to understand some nuance of the language. Virtual destructors anybody? How about multiple inheritance? Run-time-typing? It would be one thing if the issue was design complexity. It's quite another to declare that you don't trust the support staff to understand the platform for which they are responsible.

What would drive a Codewright to lower their expectations of their fellow coders? To answer that, ask yourself this question, how many times have you seen a poorly thought out bug-fix or enhancement that not only made the code messier but where a more seamless solution was in plain view and it is obvious that the code monkey that did it actually did more work and the code ended up more brittle than before? Seeing, time after time, well-designed code mangled by some fix where a simpler and easier-to-support solution was visible can destroy the resolve. Why code to high standards when you can expect your well thought out code change to be treated like newspaper lining a bird-cage by the next code monkey to get hold of it?

When it is so easy for mediocre programmers to find work and companies are so willing to hire with an eye to quantity instead of quality, hope becomes a rare jewel spoken of in whispers. Despair sets in and you reach for the opium of conformance.

Have Design, Will Travel

In the article I've linked to, the author discusses how we need to change our understanding of design. For some reason we tend to make our disagreements into horse races or battles where we arbitrarily define sides and then feel compelled to identify ourselves with one side over the other. This restricts our perspective and encourges irrational arguments. "Waterfall sucks, Iterative is the way to go" or "XP doesn't work in the real world that's why I do Agile".

The duty of a Codewright is to understand the pros and cons of the tools and techniques available to him and choose the right one for the job at hand. To do otherwise is to blindly follow in the footsteps of those who have gone before us. The sense of security we may get from knowing that our trail-blazers made it to the end of the road and so will we, won't help us when we realize that they took the hardest and longest route over the mountain instead of going around it and we've just signed up for the same thing.