Code Obsession

Unfortunately, this time is it me. I wrote about the differences between how I perceive TDD and BDD . Unfortunately, I didn't do my research. Instead I based my understanding on hearsay and assumptions. I knew that Dan North had coined the term and I should have looked for his easy to find blog post . Instead, I got most of my knowledge of BDD from discussions at local user groups. This almost always took the form of "Tool A is a TDD tool while Tool B is a BDD tool." Because I found this to be a fairly uninteresting distinction, through the course of several discussions, I effectively invented a definition of BDD that I found more valuable to me and my team than "using Tool B means we are a BDD shop." When I saw a discussion of the topic on Twitter, I interjected myself and asked for clarification. Luckily, I asked good netizens ( Avdi Grimm , Angela Harms ) rather than trolls and I got some helpful advice. So, I was able to learn a valuable lesson this we...

So you've probably heard this ancient aphorism, but what does it have to do with software development? Very few of us deliver software in isolation. We generally have customers, managers, testers, designers, operations, and fellow developers on our development and delivery teams. Because we have to interact with all of these other people, it is in our best interest to know who we are, what motivates us, and what our strengths and weaknesses are. For the last couple of years, I have intermixed a few books and videos on psychology with my standard technical fare in an effort to get to know myself better. It appears that many in our industry are doing the same. At the Agile Alliance 2011 conference, Dr. Barbara Fredrickson spoke about Why Care about Positive Emotions? . Linda Rising has spoken about The Agile Mindset at several conferences including Agile Roots 2012. At the recent WindyCityRails conference, Steve Klabnik spoke on Development and Philosophy . And many members of m...

What follows are three stories of actual distributed teams that I have been on. These are my stories and my version of events. Others involved may tell different tales. · · · A Tragedy in 3 Acts Act I The Scene It was my first agile project! I didn't know it though. None of us knew what we were doing, but we knew that anything that got in the way of satisfying our customers had to go. We were pretty good. We were so good, in fact, that our corporate entity took control of the project. The Team With two developers, our field-support/QA person, and our saleswoman/business expert, this was a small, tight team who enjoyed strong support from our executive sponsor. The Tools The developers employed a tactic of working together (we might call it pairing now). We released more than once a week and we all worked directly with our customers daily. We also met daily to discuss sales, installations, features, and bugs. How it Felt It felt amazing. We had many happy customers and we wo...

I recently posted about how to use a custom MSBuild file to run web.config transforms in your continuous integration process. This is the methods we have used on a couple of my previous teams. At Pluralsight , we use a different method. We do our 1-Click deploys through a custom web application that takes the output of our TeamCity builds as it's input. As we built our deploy tool, we chose to avoid calling shell processes. This meant finding an alternative to the MSBuild file for web.config transforms. What we came up with is the following. using System.IO; using Microsoft.Web.Publishing.Tasks; namespace SiteDeploy.SiteConfiguration { public interface IConfigFileGenerator { void TransformWebConfig(string environmentName, DirectoryInfo sourceDirectory, DirectoryInfo targetDirectory); } public class ConfigFileGenerator : IConfigFileGenerator { const string webConfigFileName = @"web.config"; public void TransformWebConfig(string environmentNam...

TL;DR It doesn't matter what process you follow, the people involved will cause the success or failure of a project. In the beginning, there was chaos. Developer were making software, but business couldn't really manage it. Then came waterfall. This was nice because it was easy to manage. And luckily, we now had computers to manage the schedules, because they were always slipping. When it was realized that developers are virtually incapable of estimating how long it takes to do anything longer than a few months (or more often days), clever managers came up with a solution: shorten the cycle! It was called the spiral method, and it is an iterative waterfall. Sure the schedules still slipped, but they didn't slip as much because the iterations were shorter. Thus was the Spiral method born. While the managers were trying to fix waterfall (because they loved it's predictability) other smart people were trying other ways to solve these problems and learning from ...

In my last post, I showed how web.config transforms can be used to manage the complexity of config files in an ASP.NET project. One thing that often comes up in mature environments is that certain parts of the web.config are need to know only. Examples include production database passwords, payment gateway authentication keys, etc. Of course, this isn't restricted to production environments, but is most common there. Fortunately, there is a solution to this built right into the ASP.NET engine: Encrypted Config Sections. Once the sensitive sections of the web.config transform files have been encrypted, the files can be added to source control and tracked just like any other file in the project without fear that the sensitive data will be mishandled in any way. In order to encrypt the files, access to the production web server is required. All the following steps must be performed in an elevated (run as administrator) command prompt or they will fail with no useful exception info...

One of the nice features that has been around for a while in .NET is web.config transforms. If you are unfamiliar, these config transforms allow you to create a base config file and then use transform files which only contain the differences between different deployment environments. Here is an example of a very simple web.config: <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="WebTransform" value="Raw/Dev"/> ... </appSettings> </configuration> And here is the web.QA.config transform file that would update the key when deployed into the QA environment: <?xml version="1.0" encoding="utf-8"?> <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <appSettings> <add key="WebTransform" value="QA" xdt:Locator="Match(key)" xdt:Transform="Replace" /> ...

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...

There has been a lot of conflict about the Microsoft Fakes library recently. My coworker Jim Cooper posted  VS11 Fakes Considered Harmful and  VS11 Fakes Considered Harmful (part 2) on our company blog. Peter Provost, the program manager for Visual Studio, responded with  Visual Studio Fakes Part 2 - Shims  on his blog. Rich Czyzewski, systems architect at Fidelity, recently shared his thoughts on the library here  Noninvasive Unit Testing in ASP.NET MVC4 – A Microsoft Fakes Deep Dive . I interacted briefly with Peter when he called Jim to discuss the library, but I haven't said much publicly. Today I posted the following on Rich's blog and decided to share it here too. It is important to remember what automated testing is actually for. The primary goal it to get code that is maintainable. I think that the Fakes library, like Type Mock and Just Mock** before it, is a very powerful tool for dealing with poorly-structured, legacy code. Unfortunately, like any...

My younger brother has decided to learn to program computers. He asked were to start, so I pointed him at the Ruby on Rails Tutorial and the Pickaxe book. After finishing the tutorial and part of the book, we had this conversation via text message: Him : So, I really like rspec. It just makes sense to write code that way. Me : That's awesome! :-) Him : I think I told you that I finished that book and have been working on pickaxe. I just did the rspec section, and I don't understand how people would want to jump into a program without writing tests beforehand. Me : I know, right? But people do. Him : Writing tests before let's you break it up into easy to accomplish goals and when you get one to pass you know it works. And if something you do later breaks it you know right away. Me : Yep. I know. And yet, a lot of people don't get it. I took away 2 thoughts from this conversation: Don't be afraid to start with testing early in educating a new d...

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...

As you may already know, my last day with STG will be Feb 21st. This was a big decision for me that is probably surprising considering how much I have loved working here. Software Technology Group I have nothing but praise for STG . If you aren't aware, STG is a local contracting/consulting firm. Despite the challenges of the distributed workplace, I always felt like an STG employee rather than an employee of my client. The office staff puts a lot of effort into successfully making consultants feel like a valued member of a larger team. They reinvest in their employees through in-house training, conferences, shared technical resources, evenings out with your spouse, family activities, etc. STG provides a lot of opportunities of developers who like to experience new work environments and challenging problems in their work as contractors, but want the safety of a regular pay check and great benefits. I can't emphasize enough how well STG has treated me while I have been there...