If you’ve decided to try to tackle an FxCop violation backlog, one of the first issues you’re going to face is deciding which rules to activate when. Here are some general guidelines…
When you first begin the backlog clean-up process, you’re going to need to introduce the FxCop tool to your team (assuming, of course, that you’re not already using FxCop for new projects). In order to focus on mastering the tool and the cleanup process before diving into “difficult” rules, you’ll want to pick a few rules to activate that meet the following criteria:
- The rule itself should be easy to understand with minimal background explanation.
- Violations of the rule should be easy to fix.
- Your code should contain very few violations of the rule.
My favourite introductory rule is DoNotConcatenateStringsInsideLoops. Unfortunately, it’s slated to disappear in Orcas, so you might want to get a start on that backlog cleanup soon if you want to use it. 😉 For finding other candidate “early” rules, the best approach would generally be to count your violations per rule, then look for any rules with a violation count of between approximately 5 and 20 that also meet the “easy to understand” and “easy to fix” criteria.
If it ain’t broke, it don’t need fixin’…
Another thing you’ll want to do fairly early in the process is activate rules for which you have no existing violations. Even though this lock down might seem very important with respect to preventing additional backlog problems, it should probably wait until you’re a few weeks into the cleanup process, and the team is starting to get reasonably comfortable with the whole thing. Don’t worry too much about this delay causing new rule breaking — if you’ve gone this long without breaking those rules, chances are pretty slim that you’ll break them in the next three weeks or so. 😉
Simple as it may seem, there are still a few things to consider as you select “no violation” rules to activate:
- Some of these rules will have no violations because your team has been actively avoiding some problem. Take this opportunity to highlight that they’ve been doing the right thing and confirm what that “right thing” is since newer team members may not be aware of it.
- Some of the rules will have no violations because your project doesn’t touch on the area covered by the rule. For example, if you don’t interact with native APIs, there are several rules around p/invoke calls that you won’t have broken. Given that your team is unlikely to start breaking these “irrelevant” rules, you can safely activate them without too much explanation. However, you should at least mention that you are activating the rule, give a quick description of its significance, and explain why it’s not likely to be violated in the target code base. This approach will ensure that the team is aware of the rule should it eventually become more relevant due to changes in the project scope.
- Some rules (but not very many) will have no violations almost by chance alone and will require more in-depth explanation than you may wish to allot this early in your process. You might want to consider delaying activating such rules until you have a more appropriate opportunity to provide more in-depth training on the rule.
Mix and match
As you start activating rules, you’ll soon realize that some rule violations are a lot quicker and easier to fix than others. For example, fixing a violation of RethrowToPreserveStackDetails usually takes seconds, while there are a few rules for which a fix may take hours. It’s important that your immediate fix backlog contain a mix of problems, both with respect to difficulty and fix duration. The quick and easy fixes will provide small tasks that any developer will be able to perform, and they’re nice little “fillers” for those five minute blocks when you’re waiting on something like a pre-commit test run for another task. They’ll also help keep the momentum going when you’ve got a backlog of “big” problems to address. If you only have big problems in the backlog at any given time, the overall fix rate will be slow, and that’s just plain depressing for everyone.
Some fixes will require considerable knowledge of a particular area of your product, and one approach to handling these would be have developers fix such problems in their own areas of responsibility. However, you may also want to view such fixes as an opportunity for a bit of cross-training. Either way, you should make sure that your immediate backlog doesn’t only contain violations against a limited subset of your product. Any given developer on your team should be able to draw problems from the backlog pool at any given time.
Slow down, you crazy child
Now and then, your immediate fix backlog is going to grow just a bit too big. This usually happens because you’ve activated a rule with a large number of violations and/or for which violations are expensive to fix. In order to prevent the backlog from growing even more, you’re going to have to stop activating new rules for a while. There are basically two things you can do to avoid losing momentum because of this hiatus. The first is pretty trivial, and simply involves having developers fix violations during the time that would normally be allotted to introducing new rules. If you’re concerned that the fix rate has dropped off because developers have fallen out of the habit of working on the backlog, then having everyone work on fixing problems at the same time like this can be one way of “rebooting” the process. However, if developers are already spending the time they ought to be on the backlog, a fix session like this isn’t necessarily a very effective use of anyone’s time.
The other “delaying tactic” is to treat the increased between-rule activation delay as an opportunity to provide more in-depth training, particularly for rules where a lot of background information may be required. It can help quite a bit to divide such rules into themes, with background training on any given theme spanning several weeks. A few obvious themes are:
- finalization and disposition,
- exceptions, and
- code access security.
As you tackle your backlog, you’ll probably start to identify some less than desirable usage patterns that aren’t covered by existing rules. While it can be quite tempting to immediately activate a new custom rule based on such a discovery, don’t forget that you have plenty of built-in rules that aren’t yet active either. Your custom rule should go into the same backlog “pot” as the built-in rules, and it should be activated when most appropriate to your backlog process, which may or may not be when you first discover the problem that the rule covers.
How far, how fast?
Obviously, the rate at which you will be able to activate rules will depend quite a bit on the size of the backlog and rate at which your team will be able to fix violations. However, you should also expect the activation rate to drop off over time as you start to activate rules that are difficult to fix and rules with large numbers of violations. Given that you may also start adding custom rules, the proportion of rules activated may drop even though you’re not inactivating any rules. Nothing exactly surprising in any of that, but it does mean that you shouldn’t use the rate of rule activation as an important indicator of your backlog clearing progress.