Tuesday, January 16, 2007

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.
Delicious Bookmark this on Delicious


  1. i've seen so many examples of this, but i digress...

    In companies which have/pretend to have code reviews, some of the standards used in the reviews very often address what can be in code so that it is understandable to everyone. in addition to the normal "good" standards are items that prohibit certain coding practices. i've seen:

    Fortran 77 only (this was in 1990)

    restricting use of certain system calls (popen, dlsym, dlget, ...)

    limiting use of operators like the ternary operator and comma operator in C

    I lean to the "if you don't understand it, too bad" camp. However, i no longer lament the eventual "TP-ifying" of the code. I got a lot of insight into this coming back to Alcatel. Code i wrote 10 years ago is still in use, but it's been munged and kludged in the intervening years and handed to overseas contractors.

    Instead of growing more efficient and elegant, it just grew in the random directions of immediate needs.

  2. I have never seen the term 'TP-ifying'. I'm interested in hearing you expound on the topic if you're willing to share.

  3. "TP-ifying" means treating the code with the same respect as toilet paper, referring to the newspaper lining in the bird cage.

    of course i said "more efficient and elegant", maybe i should have left out the more ... may not have been efficient or elegant except in my memory of it ;-) Code gets better the longer ago you wrote it?


I reserve the right to delete inappropriate comments at my discretion