Fostering good code vs enforcing it

During my time with a previous employer I learned many lessons that one is confronted with when on team with a non-trivial percentage of permanently-junior-coders (my code word for those people Joel Spolsky would put in a rubber room away from production code.) One particular lesson I learned was the folly of trying to enforce good code by not only taking steps to foster ‘good’ code, but to also prevent bad code. The senior members of the team (including myself) agreed that a particular coding ‘act’ was a pretty strong code smell. And we decided to use a somwhat more complex classpathing arrangement to prevent any code from being able to give off that particular code smell. After awhile this started to rub me the wrong way when I realized certain sacrifices were being made in order to keep the safety net. But before much came of it I moved onto greener pastures with my current employer.

Well, some time later I learned that the safety net was abandoned. And not only was it abandoned, but the way it came to be abandoned was that one of the permanently-junior-coders had simply (and likely unknowingly) broken the safety net. Just brushed it away with a simple mouse click. And not only that, but no klaxons sounded or anything when it happened, so significant time had elapsed between the net being bypassed before anyone even knew it. Upon learning this I started to think a little about that experience. Trying to learn what there was to learn.

I had read Joel Spolsky’s book “Smart and Gets Things Done” at the suggestion of my fellow blogger Barry. And what Joel says about the “rubber room” has begun to hit home with me. There are folks who will claim the permanently-junior-code can be put to good use in many cases. And I’m not going to make a claim they are ALWAYS wrong. However, having senior coders spend time and effort making those permanently-junior-coders effective is a cost. And that cost should be weighed against the benefits to be gained by having the senior coders work on real code. To be sure I’m not saying senior coders shouldn’t have to make good readable maintainable code (I’m not trying to justify coding myself some job security.) But they shouldn’t have to make sacrifices that are only necessary to benefit the permanently-junior-coder.