UnitTests must always score 100%. That is, you may not release anything that breaks the classes you edited, or any classes that use them.
AcceptanceTests test the system from end to end, and their scores improve as the system evolves more and more functionality. You graph the AcceptanceTests scores, preferably daily.
By keeping the system integrated all the time, you go faster because you don't have those awful days when you put tens of classes together for the first time and nothing works.
By keeping the system correct all the time, you go faster because errors are easier to find when you've only changed one or two things.
By keeping the scores visible you build confidence that the system works and is improving, and make introduced errors show up at the earliest possible moment.
This sounds like MicrosoftCorporation's sync-and-stabilize development model. I heard about it first a few years ago through some papers published by the Sloan school of management. Since then, I've changed our departmental development process to match it and it works beautifully.
Is there a reference to this, preferably on the web? -- RonJeffries
There is a nice article by SteveMcConnell (author of CodeComplete) titled "Daily Build and SmokeTest". It is available online at <http://www.construx.com/stevemcc/bp04.htm> and explains this practice in the context of MicrosoftCorporation. -- ErnestoGuisado
There was a book (MicrosoftSecrets) that described it in some detail. -- PeteMcBreen
Essentially, Microsoft arrived at it the same way that I suppose ExtremeProgramming did. The philosophy of sync-and-stabilize is to find a stable point and stay there. They do daily builds and tests. If you break code, you can't move on until it gets fixed. Development is divided into milestones no more than a few months long.
ChryslerComprehensiveCompensation's ExtremeProgramming "iterations" are three weeks long. In that interval we implement maybe 30 user stories. Of course we're using Smalltalk. YMMV. -- RonJeffries
A year or two ago, Microsoft stunned many people by starting to deliver their development environment and tools by quarterly subscription with rather large functional upgrades. That is one hell of a feat. They actually cut back because many shops were not ready for that degree of tool churn even though they maintained backwards compatibility with everything. -- MichaelFeathers
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006