I needed to know…

Backup Package Well I am finally getting around to publishing the Backup Package that I have been using on my current day job project. Back in September we had a build server die on us. It was not difficult to get a replacement up and running though we did lose the history of the build project. That is to say that the CCNet build logs and state file were lost. I was able to rebuild the state file by hand but the log files were just plain lost. I created this simple Backup Package to keep us out of this kind of trouble in the future. One of the main reasons that I remembered to sit down and release this Package was that same projects build server died again this week and this time recovery was complete. Anyway I have uploaded the Package zip to the Google Project Hosting service and created documentation for it as well. ...

Analytics Package Screen Capture Gary Feldman pointed out that it would helpful to see what the display of the Analytics Package was to decide if one wanted to be a guinea pig. This is a very tailored version. I doubt that other projects would have any need for some of this data. For example, this project experienced a bug in VS.NET 2005 devenv command line builds for VB.NET (shown as compiler bug). ...

Playing for Real, More Than a Scoreboard For the umpteenth time I am working on getting my organization to adopt TDD. We have been directed to figure out how to adopt unit testing. So regardless of TDD or some other way we will be writing unit tests. So we will have some kind of objective like increase the number of unit tests. Point being there will be a measure. This measure will need to be on a public scoreboard because if it ain’t we are just playing around. A scoreboard communicates that you are serious. So you need to have a scoreboard that exudes seriousness. I have been working on a Analytics Package for CI Factory. This package will add yet another plugin link to CCNET’s web page bringing our configuration to a grand total of 10 links on the build page. There is an overwhelming amount of information on the build page. To make matters worse we have more to add, MSTest has no detailed report page and we have not added FXCop into the mix yet. The scoreboard is likely to be lost in this sea of information. ...

Tipping TDD I have been working for some time on getting my organization to adopt TDD. I began with manipulation. That did not work, yet I remember it working so well for the characters in Robert Jordan’s Wheel of Time series. In an effort to find a better way I read How to Win Friends & Influence People by Dale Carnegie. This book helped me to begin to see that to influence people they must feel that you genuinely care about them. I read many other books along these lines as I have listed in Personal Growth Reading and More Personal Growth Reading. Recently I have been researching other aspects of how to instigate adoption of TDD. Malcolm Gladwell’s The Tipping Point: How Little Things Can Make a Big Difference and Albert-Laszlo Barabasi’s Linked: How Everything Is Connected to Everything Else and What It Means offer information on how to spread an idea. ...

AsyncExec and WaitForExit: Speeding Up The Build To Do More I have been working to bring the build time for our developer facing build to something less than 5 minutes. I recently got it to less than 5. Currently it does none of the nice fancy stuff like run Simian, NDepend, or FXCop. I have been experimenting with an extended exec task: asynexec. It wraps the core exec task starting base.ExecuteTask in a new thread. It has one additional attribute that must be set: taskname. Taskname is used to track the thread. This enables the other task that I created: waitforexit. These two tasks can be used in concert like so: ...

Breaking with old ways I read Eli’s posts Firing Events Made Easy and How To Isolate Future Instances last week and it hit me that this was ground breaking. The capability that he demonstrates in these posts open doors that were previously shut without refactoring. That is to say that your tightly coupled winform can now be programmatically tested with in frameworks like Fit and xUnit. This has got to be the sharpest mocking tool available for .NET. ...

Do You Smell That? So there has been this enormous discussion on the Yahoo TDD Group about testability: it was kicked off by Marcus. I used this dialogue as an opportunity to explorer something my gut has been bothering me about. My gut has been trying to warn me that TDD, as I understand it, provides inadequate direction, or maybe support is a better word, to newbies as far as testability is concerned. Why is testability of concern when things are clearly testable? It is TDD that we are talking about after all. Well read the Test Automation Manifesto (TAM) first then finish reading this post. You might also find the preface to xUnit Patterns relevant as well. In my experience I have seen adoptions of TDD fail because the of the same things that Gerard is talking about in TAM and xUnit Patterns. Gerard focuses on the test code, the fixtures and supporting class that test the product code. This is where my gut comes in. The test code is half the problem. The test subjects, the product code, is the other half of the problem. If a test subject is hard to test this will increase the effort to create and maintain the tests that exercise the test subject. Such a test subject is testable, it has low testability. This extra effort can jeopardize the success of the project and may precipitate the business need to drop the practice of TDD. The chances of this happening are greatest on projects where the TDD is new to the team. There are several things that can be done to reduce the risk of this happening for such a team. I think an experienced coach is probably the best way to reduce the risk. Unfortunately this is not an option for many teams. If possible the team should add or exchange for experienced TDD developers and pair with them. This new blood will need to play the role of a leader. When these things aren’t possible what is a team to do? Hope and pray? I hope not. ...

A Tune-Up for TDD? If you have read many of my postings to the Yahoo TDD group you may have noticed that I feel that TDD is too difficult to learn. This is of great concern to me. I work in a large company on a large project. I think it should be of great concern to the rest of the Agile community too. It seems to me that TDD presents the greatest risk to successful adoption of an Agile methodology by large projects/organizations. My gut has been pointing me in the general vicinity of testability for just over a year. About a month ago I realized why. The fifth step of TDD, refactor out duplication, is the culprit. The fifth step is geared toward a master not a beginner. Identifying duplication is not as simple as it might sound. Much more than copy and paste duplication is targeted. Behavioral duplication is the real target. Seeing this type of duplication is much more of a right brain activity than a left brain activity. This was the realization. This was the crack in the dam. ...

A Different Approach to CCNET Statistics At work on my current project there is some question as to how well the current build process is working? Some people are saying that there is contention for the build. We have a one person at a time, serialized, synchronous build system. The build times have been as high as 15+ minutes. If there is a contention issue this would be a real productivity problem. How can we know this is the case? The perception that this is happening and it actually happening can be different issues. So we need some hard impartial data to tell the story. ...