The Daily Build

Here are some simple things you can do – today – to find and prevent bugs in your code. These take very little effort to implement and do not cost any money. (And typically don’t require management approval.)

1. Turn on warnings.

This is a no brainer. Your compiler can tell you when you’re doing things that are dangerous. I’ve found countless bugs from compiler warnings. Sometimes the warnings are annoying because the compiler barks about legitimate code, but once you’re in the habit of coding to avoid warnings it really isn’t that bad. Plus it saves a lot of time in the long run.

2. Make warnings break the build.

After you’ve turned on warnings, eradicate them from your code, and then set up your build so that it fails if there are any compiler warnings. If you use GCC, this is as simple as adding -Werror to your compile flags. With other systems, you may have to parse the build output to search for warnings.

If you skip this step, warnings can creep back into the build unnoticed.

3. Review your code.

Before you even compile a change, manually review it. Spend some time looking at it. A thorough review takes more time than you might think. Five or ten minutes per line of code is not unreasonable. If you are using a defect tracking system, look through the history of defects you have made in the past to know what kind of defects you tend to create. Put these in your checklist. Review your code against the checklist. Then, for every function call that you’ve added or changed, look at the definition for that function and verify that you’re passing the right number and type of arguments.

I’ve worked on a few systems that are not consistent about using 0-based or 1-based arguments, even in the same module, so part of my checklist is to verify whether each argument is 0-based or 1-based. This part of the review has saved me from several embarrassing bugs.

4. Get a review buddy.

Connect with one or more of your peers to review each others’ code. Keep it informal – you won’t need to get management approval. Promise yourselves that you will promptly turn around requests for review. Tell your reviewer what kinds of mistakes you tend to make, and what kind of mistakes you already found in your own review. Over time your review partner will learn what your weaknesses are and can look for those types of defects. You should also seek and provide feedback on these patterns of mistakes to prevent them in the future.

It may be worthwhile to make a couple of different review partners. Different people will have a different focus, find different defect types, and it allows you to spread out the load. It also exposes you to different thinking styles as you read more code from a variety of people. Lastly, if one of your review partners leaves the company, you will already have an existing partnership that you can rely on.

5. Track all of your defects.
   • Date
   • Where found (file, class, and/or function/method)
   • How found (self, compile, peer, test, qa, field)
   • “Type” – some brief description to define the type or category of defect

You are probably already using a bug/issue tracker like Bugzilla or Jira. These are great for tracking issues found in QA or in the field. But they don’t really track defects. One issue in QA may be caused by several defects in the design or code, or one defect may cause several issues in the field. There is no 1:1 correlation.

These systems also miss all of the defects that you catch before your code gets to system test or released to the field. Set up a spreadsheet to track every defect you find in your self reviews, peer reviews, compile, and unit test. (You can track this in a notebook in a pinch, but sifting through the data is more tedious.) Keep track of:

Every couple of weeks, or once a month, generate a graph of the data. Look for files/classes/functions that generate a lot of defects, these may be candidates for rewrite since they are obviously hard to maintain. Look for defect categories that cause you problems. Brainstorm ten strategies to reduce your worst defect category. Implement the top one or two. Thank your review partner for finding so many defects. (Or, if one of your partners isn’t finding much, you may decide to send more “business” to one of your
other reviewers.)

Related posts:

1. One Simple Step for Avoiding Shallow Reviews It's your job as a reviewer to find as many...
2. 9 “Must-Have” Tools for Software Teams The items below are useful systems based on my...
3. Data vs Code I’ll take an array over a giant switch-case statement...
4. Who Else Wants Better Short Term Memory? In “Talent is Overrated”, Geoff Colvin at one point...
5. Set Your zsh Prompt Since the beginning of time, all the cool kids have...