Code Obsession

At a recent Utah Software Craftsmanship group meeting, I was asked to share my experiences using MSpec and explain how TDD is different from BDD. Since I have been using NUnit for years and MSpec since February, I was able to discuss some of the differences in the two styles of testing. First, A Definition TDD is Test Driven Development. This means writing a test that fails because the specified functionality doesn't exist, then writing the simplest code that can make the test pass, then refactoring to remove duplication, etc. You repeat this Red-Green-Refactor loop over and over until you have a complete feature. BDD is Behavior Driven Development. This means creating an executable specification that fails because the feature doesn't exist, then writing the simplest code that can make the spec pass. You repeat this until a release candidate is ready to ship. At this point, you should stop reading this post and instead go read Dan North's original article on BDD an...

I don't know what to say about this, but that's ok, because this video speaks for itself: (Also, don't get in my way, I guess.)

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...

My kids are headed back to school in just a couple of days and that has me thinking about that what I did over the summer. It turns out, I did a lot of presenting over the last few months. Agile Roots On June 22nd, Zhon Johansen and I presented a hands-on learning experience as part of the Agile Roots 2012  conference. We spent the weeks leading up to the conference preparing a self-paced kata on London (Mockist) Style TDD in JavaScript . Because this was a self-guided kata, we put a lot of time and effort into making the instructions readable and easy to follow. As part of our preparations, I presented the kata at the Utah Software Craftsmanship group on June 6th.  This was a great group experienced with katas, TDD, and group work like the Randori. Because of their comfort with these practices, they provided a lot of valuable feedback. A week later, on June 14th, we presented the kata with additional updates at the Utah .NET User Group . This group was more of a chal...

What is wrong with the picture? First off, he is blatantly disregarding his own safety and that of anyone who happens to use that doorway. His weight is likely causing imperceptible damage to the hinges and the wood of the door frame. He isn't using the proper tools for changing hard-to-reach light bulbs. This is not an expert. An expert has " a prolonged or intense experience through practice and education in a particular field. " This is a guy who pulled off a stunt in which we presume that no one was hurt. Getting away with something once or twice does not make you an expert. It just means you're lucky. How may times have we worked with someone who is an "expert" in a technology when all they have really done is pull of some gymnastic shenanigans then walk away unscathed? We should not be falling for this nonsense.

As you may know, a couple of months ago, one of my friends and teammates posted a couple of blog entries ( here and here ) about the Visual Studio Fakes toolkit. These posts started a brief dialog with Peter Provost, a Microsoft Visual Studio Program Manager Lead. Though the dialog wasn't fruitful, it did start me thinking. If I consider the time spent developing the Fakes library at the very least wasted and most likely harmful to our industry, what would I have the Visual Studio development team working on? What follows is a wishlist of features I want to see in my day to day code editor. Less is More Visual Studio is used by developers working on a wide variety of teams who build a lot of different types of applications. Because of this, it supports many features that are used by a subset of those teams. For example, the TFS team features are integrated into the IDE, though only a portion of .NET dev teams actually use them so are the server explorer and WinForms/HTML/XAML...