Stop me if this sounds familiar. (Well, not literally. I realize that asynchronous publication makes it hard for you to actually stop me as I type. Indulge me the figure of speech.) You work on a codebase for a long time, all the while having the foreboding sense of growing messiness. One day, perhaps when you have a bit of extra time, you download a static analyzer to tell you “how bad.”
Then you have an experience like a holiday-time binge eater getting on a scale on January 1st. As the tool crunches its results, you wince in anticipation. Next, you get the results, get depressed, and then get busy correcting them. Unlike shedding those holiday pounds, you can often fix the most egregious errors in your codebase in a matter of days. So you make those fixes, pat yourself on the back, and forget all about the static analyzer, perhaps letting your trial expire or leaving it to sit on the shelf.
If you’re wondering how I got in your head, consider that I see this pattern in client shops frequently. They regard static analysis as a one time cleanup effort, to be implemented as a small project every now and then. Then, they resolve to carry the learning forward to avoid making similar mistakes. But, in a vacuum, they rarely do.
Continue reading Adding Static Analysis to Your Team’s DNA