Defects: Pay More Attention to What, Less to Who

Software defects have been with us forever, and while DevOps and agile can reduce the number of defects generated, it is unlikely this number will ever get to zero for a given organization—and even if it does, it won’t likely stay there. Simply put, we’re developing increasingly complex systems on increasingly short timelines. The reduction possibilities that DevOps offers cannot completely combat this combination.

But the quest to keep defects down is necessary. The goal should always be “Less, not more.”

One of the things we have historically done is associated defects with developers. It is natural to want to know “who broke the entire payroll system,” but quite often “who” is the wrong question.

A huge benefit of both agile and DevOps is that it allows us to look closely at where the process fails and determine why. While every developer in a shop knows “you should avoid modifying that module,”—and those are the easy ones to target for early bug reduction—there are other modules and source files that might be a hidden source of a certain percentage of defects. Using the defect tracking toolset to keep tabs on where bugs are occurring might show that the problem is a given developer, but more likely it will show that the problem is a given set of source.

So if you are not already, it is time to start tracking defects closely and looking for patterns. There are some great documents out there about relatively common break points that might be useful. However, reviewing your own data is more useful, as it isn’t about common—it’s about actual problems in your source pool.

This is all part of the process for agile and DevOps, I’m just saying it a different way than the usual “blameless” discussions because I think they fail to connect for some shops. Of course blameless is great, the point here is focus on problems—whether that is blameless or not depends upon which problem you find you have.

Meanwhile, keep cranking it out. If you’re working on a viable product, then defects are an annoyance, but not something to gnash your teeth over. You are developing a viable product, after all.

— Don Macvittie