How to Get Developers to Adopt a Coding Standard

Editorial Note: I originally wrote this post for the NDepend blog. Head over to their site and check out the original, here.  While you’re there, have a look around at the other posts; if you enjoy static analysis, you’ll enjoy what’s there.

If you’re a manager, there’s a decent chance that the subject of coding standards makes you want to bang your head against a wall repeatedly.  If you’re a developer, you can probably understand why this is true of your manager, if you think about it.

The group coding standard has the following properties.

• It’s extremely technical and granular.
• Developers tend to squabble about it.
• If it produces any business value, it does so obliquely and theoretically, from management’s perspective.

Thus, if I’m a manager, there’s this inscrutable document out there that causes my team to argue, and whose existence I must take on faith to be a good thing.  As you can see, it doesn’t start out on my good side.

Does It Matter?

There are all manner of opinions and arguments to be found on the internet as to why a coding standard matters (or doesn’t).  I’ve wrote about the subject myself from time to time.  So, without belaboring the point, I’ll make the quick business case for it.

The purpose of a coding standard, at its core, is twofold:

1. It promotes maintainability by making all code look similar and familiar to all developers.
2. It standardizes approaches that promote correct code (and avoid incorrect code).

Thus, on the whole, the coding standard makes the total cost of ownership of the codebase decrease by some amount ranging between 0 and “indeterminate.”  As an outside party, you simply have to take on faith that there is an ROI and that the amount of time wasted in arguments, complaining, and compliance is offset by the reduced troubleshooting and onboarding times.

And, in my experience, it generally is.  Notwithstanding pouting and bickering that happens early in the project and makes life unpleasant, it’s better to have these things than not to have them.  The key, then, becomes minimizing the cost of having the standard.  And you do this by securing compliance with the least amount of heartburn for all involved.

So how do you do that?  How do you convince the developers to buy in with a minimum of resistance and friction?

Read More

How Code Review Saves You Time

Editorial note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at their offering.

Physical labor is one of the most strangely enduring mental models for knowledge work.  Directors and managers of software development the world over reactively employ it when nudged out of their comfort zones, for instance.  “What do you mean ‘pair programming’ — we’ll get half of the work done for the same payout in salary!”  And that’d be a reasonable argument if the value of software were measured in “characters typed per minute.”

Most of the skepticism of activities like unit testing and code review originates from this same “knowledge work as labor” confusion.  The core value of software resides in the verbatim contents of the source code files, so stuffing all of the features in them ahead of the deadline is critical.  Testing and reviewing are “nice-to-haves”, time and budget permitting.

The classic response from people arguing for these practices is thus one of worth.  It goes something like this: “sure, you can cut those activities, but your quality will dip and there will be more escaped defects.”  In other words, these ‘extra’ activities pay for themselves by making your outfit look less amateurish.  That argument often works, but not always.  Some decision-makers, backs truly to the wall, say “I don’t care about quality — my job depends on shipping on June 19th, and we’re GOING to ship on June 19th, whether it’s a finished product or whether it’s a bag of broken kazoos and cyanide with a bow on it.”

I’d like to take a different tack today and fight a time argument with time arguments.  Instead of “sure, code reviews take extra time but they’re worth it,” I’d like to explore ways that they actually save time.  Whether they save more time than take is going to vary widely by situation, so please don’t mistake my intent; I’m not looking to argue that they’ll save you net time, but rather that they are not exclusively an investment of time.

Read More

How to Actually Reduce Software Defects

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Have a look around while you’re there and see what some of the other authors have written.

As an IT management consultant, probably the most frequent question I hear is some variant of “how can we get our defect count down?” Developers may want this as a matter of professional pride, but it’s the managers and project managers that truly burn to improve on this metric. Our software does thousands of undesirable things in production, and we’d like to get that down to hundreds.

Almost invariably, they’re looking for a percentage reduction, presumably because there is some sort of performance incentive based on the defect count metric. And so they want strategies for reducing defects by some percentage, in the same way that the president of the United States might challenge his cabinet to trim 2% of the unemployment percentage in the coming years. The trouble is, though, that this attitude toward defects is actually part of the problem.

The Right Attitude toward Defects

The president sets a goal of reducing unemployment, but not of eliminating it. Why is that? Well, because having nobody in the country unemployed is simply impossible outside of a planned economy – people will quit and take time off between jobs or get laid off and have to spend time searching for new ones. Some unemployment is inevitable.

Management, particularly in traditional, ‘waterfall’ shops, tends to view defects in the same light. We clearly can’t avoid defects, but if we worked really hard, we could reduce them by half. This attitude is a core part of the problem.

It’s often met with initial skepticism, but what I tell these clients is that they should shoot for having no escaped defects (defects that make it to production, as opposed to ones that are caught by the team during testing). In other words, don’t shoot for a 20% or 50% reduction – shoot for not having defects.

It’s not that shooting for 100% will stretch teams further than shooting for 20% or 50%. There’s no psychological gimmickry to it. Instead, it’s about ceasing to view defects as “just part of writing software.” Defects are not inevitable, and coming to view them as preventable mistakes rather than facts of life is important because it leads to a reaction of “oh, wow, a defect – that’s bad, let’s figure out how that happened and fix it” instead of a reaction of “yeah, defects, what are you gonna do?”

When teams realize and accept this, they turn an important corner on the road to defect reduction.

Read More