A quick point of mention: The general community that pushes TDD/Agile/Scrum can, in my experience only, be a bit pushy. Constructive comments are welcome, but any personal attacks, or vulgar comments will be mercilessly deleted.

<Added Later>

Eric Shupps and Andrew Woodward both wrote a long blogposts in response to this. Eric and Andrew are both extremely smart guys, and I hold them in high regard.

I tried leaving a comment on Eric's blog, but it didn't go through .. so I am writing it here instead.

Eric says -- "As usual, Sahil is nothing if not incendiary, but his basic premise is that the actual amount of code written for the average SharePoint project doesn't warrant the overhead of a structured development process (he just happened to choose TDD in this instance)"

I am being misquoted here. A structured development process is MORE necessary in SP projects than .NET projects, because things such as TDD are HARDER to apply. I never said that you should use bad dev methodologies with SP projects, only that the ROI of TDD specifically on SP projects is lower than .NET projects.

</Added Later>

Okay so here we go! I was at NDC last week, and there were a lot of very intelligent people there in the speakers room or otherwise. As I was walking around on the floor (which frankly I prefer to do than sitting in the speakers room – where everyone is a speaker and hardly anyone is a listener). While on the floor, multiple people asked me a very straightforward question - “What do you think of TDD in SharePoint?”

Well, I think it isn’t worth the effort.

There is nothing wrong with TDD, and in many projects it is quite beneficial. But I completely disagree with the viewpoint that it is the only way of doing things, and every other way is wrong.

Lets take a step back and consider TDD and it’s brothers and sisters. Lets look at everything in perspective, Agile, Scrum, and everything in between. People have used the waterfall methodology for a very long time, and many have expressed their frustrations with it. The basic premise/issue of waterfall is that you need to catch your changes early in a project, because as you discover changes in a project in later stages of a project, the cost of change to implement such a change is much higher. But we know that in the real world, change occurs. So all these methodologies, focus on reducing the cost of change.

So, in order to reduce this cost of change, there is an upfront and ongoing cost, of implementing procedures and practices that help you reduce the cost of change – remember, nothing is free!? So there is a cost, to reduce the cost of change. And thus, if the cost of change is greater than the cost/investment required to reduce the cost of change, then it makes sense to use it for your projects … otherwise it doesn’t!

So it all boils down to, what are the characteristics of a project that help you identify, in which projects, the investment/cost to reduce the cost of change, is lesser than the cost of change itself!

The answer is larger, complex projects with tonnes and tonnes of code!

So, now lets take a typical SharePoint project. Of course there is a range and gamut of SharePoint projects, but lets pick the average summation of them all. A usual SharePoint project involves many things,

• Customer communication and prototyping – usually much much more than a typical .NET custom dev project.
• Plenty of attention to the IT Pro side, where you decide logical and physical layouts of your servers, networks, and your site collections. Custom dev .NET projects are usually simpler to setup and plan.
• A significant effort in branding – usually greater than your typical .NET project, simply because the master pages and CSS and JS of SharePoint are much more complex.
• Focus on scalability, when balancing between requirements, and best practices, and experience!
• Writing some code
• Establishing roles within your team, which is different from the nature of the SharePoint project. Usually this is more involved in an SP project than a custom .NET dev project, simply because there is a higher overlap between ITPro and Dev in the case of SP.
• Training required – your business users will need training on the project ~ again, usually more significant than a simple .NET custom dev project.
• Architecture, and functionality bargaining per RUP for COTS – where there are many ways of achieving a goal, and the way picked is a delicate balance between budget, demands, and technology.

Thus in a typical SharePoint project, the portion where TDD is actually applicable is very small – which is the writing code part. In most, not all, SharePoint projects, we write code as small bandaids across the system, to cover that last mile – we don’t write code to build the entire platform, in fact the emphasis is to write as little code as possible, while meeting the requirements.

So already, the applicability of TDD as a total percentage of the project is much smaller.

Now, lets look at the code we write for SharePoint. These small bandaids that can be independent of each other, are comprised of some C#/VB.NET code, but a large portion of the code is XML files. These large portion of XML files, especially the most complex parts, define the UI – something TDD is not good at testing anyway. Yes I know attempts have been made, but attempt != standard. And the parts that are even pure C#, we deal with an API which does not lend itself well to TDD. You can TDD SharePoint code, but it’s just much harder.

So you have to ask yourself, that this 5% of the actual project effort, where you WILL indeed write code, which is possible, but is difficult to make test driven, in that 5% is the cost of reducing change, worth dealing with the actual cost of change?

In a rare borderline scenario, I bet the answer will be yes! But in most scenarios, the answer is usually no.

So, TDD + SharePoint 2007? Well – screw it! Not worth it IMO.