Swept

Can you hear these things around your project?

• "What's our recommended practice for handling these?"
• "Where can I find good sample code for that?"
• "That's the same problem we found in the last code review.  And the one before that."
• "That proof of concept is great.  We don't have time to change the whole codebase over right now, but let's do this way from now on, and we can convert the old stuff as we get around to it."

Every time we decide to improve our practices or technologies, our project becomes more out of date.  Every case of the prior, deprecated practice or technology is now wrong.  Fifteen minutes ago, it was best practice.  From this moment forward, it's legacy code.

• The larger the project is, the larger the "wronging" effect of improvement becomes.
• Current team members need to unlearn old practices, and learn the new ones.
• New team members need to learn the modern practice, rather than the widespread obsolete code.
• As the team grows, each developer knows less of what's happening right now--which includes new improvements being decided on.

A natural enough urge when grappling these problems is to decide "we'll document our current accepted practice, and make sure that new code follows it."  Unhappily, when we try to make this work, we find that it becomes something like:

1. Compose a document of all the things we'll either
   • want to do again, or;
   • want to change in the future.
2. Maintain that document, and everyone's awareness of it.
3. Decide on a policy, spend the effort to enact, maintain, enforce the policy.

This course is intellectually difficult, expensive in effort, aggravating, and bound to fail.  We wanted to find a tractable technical/awareness nudge to take the place of such a heavyweight bureaucratic labor.

Swept lets the team define what obsolete code looks like, and what the recommended changes are.

Change rules can point to external references:

• URLs for a local wiki or a technical document
• (upcoming) A diff of two SVN commits of a file, to display what the changes to fix the issue are
• (upcoming) A file in the current project

As developers edit files, a Visual Studio Addin shows a to-do list of issues found in the currently-edited code.

(upcoming) Command-line triggered project statistics reporting

• Each issue, and the list of files it's found in
• The total issue count of the project
• Comparison of issues found in this build versus prior builds

The team still needs to decide how they want to behave, given this information.
A team just finding its feet may be satisfied if no new cases of a difficult problem can appear in the code.

A team grown into this practice might

• Forecast effort and choose targets based on extent and benefit of a change
• Quickly assess upgrade targets of opportunity in the course of other work
• Propose and refine improvements by discussing change rules