Google have been publishing some of their internal tech talks for a while now, and I recently came across this little gem; “Predicting bugs in code changes using SCM information “. The concept proposed by this video is that you can use the combination of your source control check-in logs and defect tracking history to identify where the areas of lowest quality code are and focus your testing efforts on them.

In Code Complete, Steve McConnell espouses some statistics that: “80% of errors are found in 20% of a project’s code.”, and “50% of errors are found in 10% of a project’s code.”.

This leads me to a logical conclusion that with a little bit of thought and planning with VSTS, you could identify the 20% of code that has the most defects logged against it and focus your testing efforts there. However like everything, once you start measuring you begin squeezing the balloon, and effecting the system that you are measuring.

According to a recent Microsoft webcast, VSS 2005 (I am yet to see and play with the product), VSS 2005 has several new key features:


  • Http based remote access
  • Performance improvements
  • Support for a Copy-Modify-Merge development model in addition to the current lock-Modify-Unlock model of the current version.
  • Prorogation of renames/deletes
  • Support for 3rd party merge modules
  • Support for unicode and multiple languages