Look and ye shall find. Or may be not.

Do you think that you could list the ways you employ to minimize the number of bugs in the software? It could have been an interesting exercise (similar to 5 facts about yourself nobody knows etc). Well, Patrick Smacchia of NDepend fame did it for you – here are seven (like in seven deadly sins :) typical ways to minimize number of bugs in the software.

I liked the post very much (and still do) but eventually I started thinking that I do not agree with some of the things said. So there – my take on those seven.

While I have no argument about Contract, Automatic Tests and Empirical Approach as effective ways of fighting bugs, other categories do not seem to me a bit questionable.

Prioritizing bugs fix over new features development is a good tactic when one can truly estimate the stability of the code. But frequent is the situation where the code is considered to be worth making more stable through bug fixing; but the stability of the code never actually increases. As the stability (increase) cannot always be estimated numerically, this technique to me seems to be giving a big name to somewhat arbitrary decisions of deciding what to maintain and what to leave alone.

Code quality that is supposed to be brought about through changes in programming styles such as LINQ is in the very least arguable. The argument VB is better than C++ since it is easier to understand comes to mind. Very good post on new trends that will revolutionize software development can be found here – I rather tend to subscribe to that view.

Finally, positioning Code Review and Static Code Analysis as tools for finding bugs misses the point. If we talk about doing code review (static code analysis can be thought of as automated code review process) in order to identify bad "smell" coming from certain piece of code (which FxCop does well) or coming from certain modules/design decisions (in which NDepend excels) that is a one thing; but to use code review (in any form) to find actual bugs always was pretty ineffective. While Patrick says so in his post, he still puts code review into his list. I wouldn't – I would rather call that code quality assessment using whatever tools are available (old-fashioned peer code review, static code analysis, Line Of Code counting whatever); and such an assessment would result in devoting more time to testing the questionable areas.

And what will be your take on bug fighting techniques – speaking theoretically?