Habits that Help Code Quality
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. If you like posts about static analysis, code quality, and the like, check out the rest of the blog.
When I’m called in to do a strategic assessment of a codebase, it’s never the result of everything being awesome. That is, no one calls me up and says, “we’re ahead of schedule, under budget, and knocking it out of the park, so can you come in and tell us what you think of our code?” Rather, I get calls when something isn’t going according to plan and the business people involved want to get some insight into what underlying causes there are in the code and in the team’s approach.
When the business gets involved this way, there is invariably a fiscal operational concern, either overtly or lurking just beneath the surface. I’ll roll this up to the general consideration of “total cost of ownership” for the codebase. The business is thus asking, “why are things proving more expensive than we thought?”
Typically, I come in, size up the situation, quantify it objectively, and then use analogies and examples to make clear what’s happening. After I do this, pretty much without exception, the decision-makers to whom I’m speaking want to know what small things they can do, internally, to course correct. This makes sense when you think about it. If your doctor told you that your health outlook wasn’t great, you’d cross your fingers and say, “but I can fix it by changing my diet and exercise a little, right?” You wouldn’t throw yourself on the table and say, “cut me open and make sure whatever you do is expensive!”
I am thus frequently asked, by both developers and by management, “what are the little things we can do to improve and maintain code quality.” As such, this seems like excellent fodder for a blog post. Here are my tips, based on years of observation of what correlates with healthy codebases and what correlates with distressed ones.
