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.