Geeks With Blogs
On the Ledge The general evolution (and occasional regression) of a .NET developer

First of all, the folks I used to work with will be glad to know that Panda Express is selling their Orange Chicken sauce at their restaurants.  Unfortunately, it does not come in 2 liter bottles or six packs.

On topic, the posts I've made here lately have gotten me thinking about the idea behind standards and/or best practices.  I noticed a refrain in many of my posts, although it was unintentional - the idea that a given situation dictates the best solution as opposed to taking a pre-determined solution and applying it to the situation.  While I think most sane people would agree this is generally a good way to go about development (and perhaps a lot of things in life in general), there are some ramifications for ideas like code standards that may be a challenge to work through.

Code standards and practices have some key advantages.  They enforce code quality (or at least, the standard's definition of code quality).  They provide a pre-existing level of familiarity when people come to a new area of the codebase.  It is often relatively easy to automate the testing and generation of code according to particular standards.

The problem, though, is that dictating firm standards (and especially specific practices, tools, or techniques that a developer must use or avoid) forces a one-size-fits-all solution that might not be the best solution for what you're trying to accomplish.  In fact, it's possible that your standard, which is great 90% of the time, is a crippling hack the other 10%.  In that 10% of the time, isn't it best for the company and your software not to use your standard?

In other words, I believe a standard should never be created or enforced for the sake of having a standard.

Standard coding practices are not inherently good.  You can have bad standards.  You can have pointless standards.  You can have standards that are good some of the time, and not so good otherwise.  Standard coding practices are only useful insofar as they provide and protect certain values.  They don't have value all by themselves.  They have pragmatic, not inherent, value.

If those values are better provided and protected by defying a standard or having no standard at all, then that's exactly what you should do, and it boggles my mind how many blogs I read or stories I hear where someone is just convinced that slavish devotion to a standard, practice, design pattern - whatever - is something that should never be compromised, as if there's something inherently unethical or dangerous about that.

A solution to a problem needs to be evaluated on its own merits, and the objection, "But that's not our standard," is not a valid objection on its own.  You have to remind yourself what that standard is buying you in this situation, and then see if the alternative also provides that for you or provides something that is worth the trade-off.  This is always a valid discussion to have.  To rule out solutions -purely- on the basis that they are non-standard is the last refuge of not having to think or make educated, calculated decisions about what's best.  Anybody can parrot a document or an article - very few people can think critically about code and how to solve problems with it.

There are some common objections I've read or heard about deviating from standard practices, and I'd like to address them, briefly.

"We'll have all different kinds of code and methodologies in our solution."

I have yet to see the project where this is never the case.  If you have a common codebase with two people working on it, you're going to have different kinds of code and methodologies; I don't care how much you try to legislate it.  In fact, this often happens with just one person.  Trying to fight this is something like trying to get communism to work.

The other side of this objection is the assumption that having different kinds of code and methodologies in the same codebase is inherently bad, and I'm not sure that's the case, anymore than having different kinds of tools in your toolbox is inherently bad.  To be honest, a codebase that is completely monolithic in its code structures probably lacks any kind of innovation and has many circumstances where the code used is not the best for the situation - like trying to hammer all your nails in with screwdrivers.  It can be done, but it's also stupid.  No standards document is going to make using screwdrivers to hammer nails anything but stupid if you could just as easily have obtained and used a hammer.

"Our people aren't going to understand different styles of code / more advanced methodologies."

It amazes me how much a company is willing to suck in the name of accommodating their employees' level of aptitude.  While that may sound harsh, and while I admire companies trying to retain their employees in a bad economy, it's never a viable excuse to say, "Methodology X would be a lot better, but the people we've got will never be able to understand that."


So, one has to ask what the actual problem is.  Is it that your employees are literally not mentally capable of learning new ways to do things?  Is it that they're capable, but they're unwilling?  In either case, I'd have to ask why you're so committed to holding on to people who are either incapable of becoming more skilled or refuse to do so.  If your employees can get to a level of dealing with different styles of coding and they are willing to do so, then this objection falls.

Developer teams always have different levels of ability in them, and the way to most effectively direct a team like this is not to bring everyone down to the lowest common denominator, nor is it even to create a midpoint.  The way to effectively direct a team is to give people responsibilities commensurate with their skill levels and have a plan in place to increase their skills and give them different kinds of tasks if that is their desire.

Some people may be perfectly happy doing little bug fixes.  Fine.  Use them for fixing little bugs.  But if you orchestrate your standards for application development based on your lowest level of competence, well, guess what kind of product you're going to produce.

Once again, I find that this objection has more to do with laziness than anything else.  Companies do not exist to pay salaries; they exist to make money.  If you doubt this, find the report that your company distributes to shareholders and see how much attention is given to profit and loss versus how well you're doing at increasing the number of employees.  If a new methodology seems too complex for most of your crew to work with, then put a plan together to get them to a level of understanding.  If that's impossible, then you may find that you need to reorganize or perhaps even eliminate some people.

I'm not saying just to boot people out the door who can't hack it.  As a former trainer, I believe in bending over backwards and exhibiting all the patience you can muster with someone who's willing to learn and work hard.  But what I am saying is that you've bought an express ticket to Stupidville if the primary value of your standards is that they protect the least skilled of your workers from ever being confused.

"What's the point of having a standard if we allow people to deviate from it?"

This is actually an excellent point.  What -is- the point of having a standard way to do something if it turns out that the best solution, at least part of the time, is to do something different?  But the assumed answer here is that the practice should promptly change in favor of the standard.  I would argue that the best answer is the other way around.

If you find that your standard isn't the best solution, you should change it to the best solution.  Otherwise, you should get in touch with those other people going to Stupidville so you can get a group discount.

What is probably more common, however, is that you discover that your standard is pretty good in many situations, but there's one or more where it isn't, and the question is whether or not you should allow exceptions in the name of implementing a better solution.

The first thing I have to say is that it's worth considering that standardizing that practice isn't a good idea.  If there are multiple ways of doing it, and some of them are the best in one situation and others are the best in another, that sounds like a prime candidate for not standardizing, or at least offering a defined list of acceptable options.  If your standard is hurting you, why have it?

If, for whatever reason, that's not an option (maybe you have a standardized practice for establishing standards and are stuck in a space-time continuum paradox), then we go back to the original point - what is the standard getting you in this situation?  What is the deviation getting you?  Which one is worth more?  If what the deviation gets you is worth more than what the standard gets you, on what planet does it make sense to enforce the standard?

Experientially and logically, it seems to be that there are very few one-size-fits-all solutions in development.  Naming conventions and the like are probably harmless enough and provide some value, but you are heading into dangerous waters when you being to mandate practices or forbid the use of others.

Every situation is going to have different parameters, and every solution should be weighed on the basis of whether or not it provides the most value in that situation.  And if some upstart developer challenges the standard by producing actual reasons why her solution is a better choice for solving her problem, you'd better come to the table with something better than, "Well, it's not our standard."

Posted on Monday, September 28, 2009 2:20 PM Miscellaneous , Architecture | Back to top

Comments on this post: Code Standards Can Kill You

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © ledge | Powered by: