Ayende recently answered the question what the bare minimum aspects of Agile project would be? His opinion is: Ship it Often.

Without surprise, most of developer would instead have answered with TDD. Personally, I cannot answer this, as I cannot answer if in a good meal the main course is more important than the dessert.

I wrote about this subject a year ago in the article How to avoid regression bugs while adding new features? Basically, I wanted to underline with this article the empirical facts that:

• Code that works in production will likely continue working properly in the future as long as it is not touched.
• The vast majority of new defects introduced by a new release come from refactored and added code since the last release.
• As a consequence, before releasing the team should focus its attention on refactored and added code since the last release (i.e the diff).

This indirectly advocates for the principle of small iterations and ship it often. The shortest is the iteration, the smallest is the diff on which to focus on. This is one of the top goal for the development of NDepend. On the release notes page, we can see that we did 11 major releases and 19 minor releases during the last 24 months.

By focusing our attention on diff I concretely mean:

• Code review diff.
• Smoke test features corresponding to diff in code.
• Write unit tests to ensure high coverage on diff.

This is just common sense! At this point, the need for high tests coverage is joining the need for short iterations. Because when iterations are short, the amount of fresh code to test is relatively small and this is the best motivation to actually write tests.

NDepend can help both code reviewing diff, and also ensure high coverage on diff. For code reviewing diff you can use the build comparison feature coupled with the ability to plug a source code diff tool to NDepend. More on leveraging Code Reviews with NDepend can be found in this post.

For ensuring high coverage on diff you can mix the build comparison feature with the import of test coverage metrics. I wrote a full blog post on this, Are you sure added and refactored code is covered by tests? Basically the idea is to use the following CQL query to ask for changes not properly covered by tests:

SELECT METHODS WHERE            // Select methods where

  PercentageCoverage < 100 AND  //  not 100% covered by tests and

  (CodeWasChanged OR            //  was refactored or

   WasAdded)                    //  was added.