“Perl is a write-only language” — Mark Roddy, during a discussion of Microsoft’s inf testing tool, written in perl. He wasn’t the first to say that, but it was particularly appropriate. Having a six-figure number of lines of production perl to keep up with, I can relate.
I spoke with the principal designer of PreFAST while at the MVP summit, and we had a really interesting conversation about static analysis tools. Coders inside of Microsoft have really embraced the use of PreFAST, and the tool itself just keeps getting better and better. I now use PreFAST regularly, on every driver I work with, as often as makes sense.
One other tool I use regularly for driver development (well, all development, really) is PC-Lint from Gimpel Software. These guys have been in the Lint business forever, and the product is great. It’s terribly picky and overly pedantic, but once you get used to living with its warnings and ambient noise level, it becomes easy to work with. It certainly pays for itself in time spent, according to the principle that a minute of time spent seeking out bugs during development is worth an hour or better spent debugging after the product has shipped.
So, I’d heartily recommend using both tools during your development cycle. I find them to be complimentary – lint catches C/C++ issues, and PreFAST seems to catch more Windows-specific issues (although that may be a result of the order in which I usually employ them). Static analysis tools take some getting used to, but they’re worth it in the end.
Adi Oltean has a great article up called “Supportability is not a feature.” I have been beating this drum for a while to whomever will listen, both inside my organization and oustside. I’d go so far to say that supportability is not only “not [just] a feature”, it is King Of All Development. [Apologies to Howard.]
Among the conversations I had yesterday with Microsoft people, one of the most interesting was with the team that supports the static analysis tools. The point was made (and re-made) that a bug’s cost (monetary and in human resources) increases substantially after the ship date. Debugging takes longer, because you’re dealing with e-mail and phone calls (and maybe a remote desktop session if you’re very lucky) and crash dumps, and because you haven’t thought about the code with the bug in months (assuming you have a sane release cycle), and because you have now gifted the whole of humanity with your software defect rather than just imposing it on QA. The cost of goodwill alone can be huge. Ask Microsoft about the “reliable repro” they had of a recent bug. That repro is more commonly known as “Blaster”. Not pretty.
I’d only add one thing to Adi’s analysis: part of maintainability is in the software development infrastructure. Your development system has to be able to grow and change with the changing world around it. New employees can’t be asked to go download an old DDK, apply various patches from a different, old SDK, add the in-house components, etc. – What happens if there’s a new DDK version that’s incompatible with the old headers? The “FrankenKit” approach (as Mark Roddy called it yesterday) is unmaintainable. You must have a stable, forward-looking development environment.