Okay, that's really just a hook to get you in the door. Let me complete my thought:

TDD is total crap if you don't really do TDD, but get stuck on Faux-TDD

In the last four weeks the project I'm working on has grown from 3 libraries to 12 (it's probably a bit bloated).  It has gone from 30% unit test coverage to about 75% unit test coverage.  (The white-papers I've skimmed more or less say 70% to 80% is good and that getting above that is not cost effective unless you're writing fighter-jet or medical device software.)   We're successfully implementing an MVP based on the in-depth work Vijay did looking into approaches.  We are coding against interfaces not implementation classes, using an IOC tool and writing unit tests using a mocking framework.  And, most importantly, we're trying really hard to implement TDD.

I'm going to go ahead and say, we've done everything we can in he way of employing tools and patterns to make TDD happen - save one thing: writing tests before we code.  This is kind of the classic Software Engineer response: learn a tool, get some numbers, bang some stuff out to get it going.

Finally the light has come on with me and TDD. I totally get-it from a process perspective. I totally get-it from a qualitative perspective. And as a software engineer, I am innately averse to fear-based coding. To be perfectly honest I'm not entirely there either. I've fiddled with TDD - in so far as most of us have. Exploring the novelty of writing a test, running it to failure and then coding it to success. There were/are several issues, but the one that was second on the list is best expressed: "so what, I have a lot of tests"

Well, due to some prodding by my adopted boss and some ribbing from a fellow blogger (Jonk), I've started to find TDD actionable. I've "seen the light" all along, but how to make it real was always the problem. The other day I wrote a method called CityStateZip() on an Address class. You get the picture, you always want that pretty one line of the address for display but constantly doing the string.Format() gets really old. Yes I am aware that some of you out there just realized that in your mind I 'adulterated' a business object with display logic. All I have to say it bite me. It's a standard format, standard to the domain of Addresses in general. So dismount your separation of concerns high horse and lets move on. Proud of myself (um, yeah) I checked it all in and went about my business (What no code review? Bite Me). The next day my adopted boss, let's call him Tony, said, "Hey, you guys gotta watch those tests. You checked in a method CityStateZip and didn't add a test for it."

Jonk asked me to write up this portion of a dog and pony show I do from time to time.  It’s the bit where I pretend to be a source control expert and tell other people what to do.  I’m usually pretty successful, but only because I am quick with a witty response while I compose a more suitable (read plausible but not necessarily correct) answer.

Today’s subject, “why we branch when we release” is some thinking around the problem – How do I release code and still have the ability to move forward on the next feature and yet not lose the ability to patch the release if I need to.

Let's break this down to the component requirements so we can be sure to address them all:

• a simple source control process around releasing code
• easy ability to continue development of new code after releasing
• ability to patch on released code and re-release without worrying about new development, after the release, will be included

With those requirements in mind let's discuss what the "normal" development process looks like from a source control perspective.

thanks Kelly and the kind people over at dilbert.com

Scott Guthrie's blog has some details about the release.  I'm a bit behind on this one, but some of the highlights I keyed in on:

ASP.NET AJAX and JavaScript Support

.NET 3.5 has ASP.NET AJAX built-in (no separate download required).  In addition to including all of the features in ASP.NET AJAX 1.0, ASP.NET 3.5 also now includes richer support for UpdatePanels integrating with WebParts, ASP.NET AJAX integration with controls like <asp:menu> and <asp:treeview>, WCF support for JSON, and many other AJAX improvements.

VS 2008 and Visual Web Developer 2008 also now have great support for integrating JavaScript and AJAX into your applications.  You can learn more about this from my blog posts here:

• VS 2008 JavaScript Intellisense
• VS 2008 JavaScript Debugging
• VS 2008 ASP.NET AJAX Control Extender Support
• VS 2008 JavaScript Intellisense for Silverlight

My plan today is to see if I can't develop a basic Silverlight 1.1 application.  I have this idea for a rich interactive display on top of XPlanner (everyone's favorite project tracking tool at my office) called TaskBored that would give you a view of open stories and the tasks associated with them as if it were all sticky notes.  The desire for this view came out of our planning process, and while we've pretty much left this technique behind as impractical the view of the work ahead it produces is useful.