Links

Why

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:

Compose a document of all the things we'll either

want to do again, or;

want to change in the future.

Maintain that document, and everyone's awareness of it.

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.

Specifications

Visual Studio 2008
.NET Framework 3.5
et c.

Swept

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

Team work

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