We recently had some Microsoft PFE's (Premier Field Engineers) in to Harris Corporate to give us the crash cource in Team Foundation Server.  Apparantly Microsoft has a whole department (Premier Field Engineering) dedicated to customer's like Harris who back up a truck full on money to Redmond each year for licensing.  And what a department it is.  We traded in some of our support hours for the class as it has been a pretty good year for things not going too wrong.  The class was taught by Hamid Safi who was being shadowed by Cory Foy from the Tampa office.  Both guys were incredibly knowledgeable about TFS and almost any other Microsoft product we aksed about.  The class size was quite small and we got the opportunity to go off on some tangents when the in depth TFS discussion was beating our attention spans into submission.

Cory gave the presentation on the Testing portion of TFS / Visual Studio Team Edition where he used a great little Bowling Score class to demonstrate testing.  The discussion then worked its way down to the Agile / TDD.  His initial class was rudimentry and simply added scores.  Test cases were written for several of the simpler scenarios like frames of all zeroes and frames that did not include strikes or spares.  Youc an actually read about this in Cory's Blog entry here: http://www.cornetdesign.com/2006/11/bowling-revisted.html#links.  The demonstration and interactive portion of the talk began when we started covering the spare and strike cases.  Cory went into covering the spare scenarios and we quickly came up with a solution.  But while designing the solution, it became clear to me that the way we were implementing it was not very 'friendly' for implementing the upcoming strike cases.  And this is where the fun began... Cory preached the Agile / TDD gospel here: solve the problem you are workin on and then move on.  I was a bit resistant to his at first but also see its wisdom.  More time than I care to admit, I get bogged down in trying to design out the entire solution for eevery possible case before I get heavy into coding.  And I consequently do not start coding soon enough, do not have prototypes ready on time, and generally cut down on the time I have available to code.

Looking at the world with Agile / TDD glasses on is kind of nice.  I don't necessarily need to have the weight of the whole app or system on my shoulders at once.  I concentrate on getting done what needs to be done now and adding or refactoring in the next features that come down the pipe.  I shouldn't be afraid to write code that I will be throwing away in a few weeks.  The important thing is not the code but an understanding of the system that is being built and its rules.  Well written code will be adaptable to a degree, but when there is a signicant change to the system's requirements, we can't be afraid to throw that code away while retaining its tests and wisdom.

I am going to put an Agile / TDD book on the Christmas list.