Coding standards are a waste of time. If you agree with that statement, you’d probably have a lot of support from other developers who feel the same way. After all, programmers are smart people. They shouldn’t need someone watching over their shoulder telling them how to do their job, right?
Developers Rule, Or Should They?
A developer who says “don’t tell me how to do my job” may be fine in your organization. It just doesn’t work if you’re on my team. It tells me that the programmer cares more about doing his own thing than about the team or the customer. Because a standard will by nature disallow certain practices, it will definitely be an irritant. The key question for me is whether that irritation will result in a developer stand-off or will be accepted as part of the process for the good of the end product.
Skinning A Cat
“There’s more than 1 way to skin a cat”. While that’s true (having never done it myself, I’m guessing it’s true), it’s just not true here. A standard says “this is how we do it here”. It doesn’t mean that there are no other viable possibilities. In fact, the standard may not rank 1st in every developer’s opinion. The key is that the standard was pre-decided, which is an expensive process in terms of time. By simply implementing the standard, there’s a built-in time savings.
A Real-World Example
Let’s talk session variables. In a web app, these are the settings that store information specific to a user for that login (oversimplified, don’t judge). One particular project I remember had an abnormally large number of poorly implemented session variables, and we were starting to see bugs in our production code because of this issue. Specifically, we had code that resembled this: Session[“my_key”] = myNewKeyValue . This value was being set all over the place and meant something different depending on what part of the app you were using. That’s bad.
To fix the problem, I had to take some time and figure out how we should actually be using session variables in this project. I decided that there would be 2 types of session variables: session variables related to a single page and session variables that were related to the site. Those were the only options, and the names of the variables were required to match their scope (page or site). After the session variable mess was cleaned up throughout the project, we didn’t see the same type of bug. Problem solved. Standard implemented.
Coding Standard Overkill
If implementing a standard solves 1 problem, implementing 10 standards will solve 10 problems, right? Wrong! Before you go crazy with implementing all possible standards, you need to ask what problem each standard is solving. Your 10 standards may solve 5 problems, which means you’ve got 5 standards that do nothing but add overhead. Plus, remember that each standard is by nature an irritation to developers. Without a really good reason to put the policy in place, you’ve just added job stress for no reason whatsoever.
How Standards Speed Up The Dev Process
Think of an assembly line. Now think of how that same process would look if the product was being produced without the discipline of the assembly line. The end product would likely be different every time and there would be a lot of chaos. Only disciplined processes can safely be sped up. You can speed up the assembly line by tweaking parts of the process. Attempting to speed up the non-assembly line version only produces more chaos, more sub-standard products, and causes more frustration. While churning out code has more variation than an assembly line product would, the point is that having an undisciplined process, improvements cannot be made.
If you’re on board with the idea of implementing standards but don’t know where to start, ask yourself where your biggest problems are. Look at the types of bugs you’ve been fixing for 6 months. Listen to what your developers are complaining about. Come up with code samples that show the way you expect the code to look. Most importantly, start today. Coding standards that you’re planning to implement next week will probably never get implemented.