« Microsoft Online Offering – First Impression
Hard to find error creating SPWeb through API »

Thursday, February 19th, 2009

SharePoint and TDD – The other view

Posted in SharePoint, Testing  |  Comments


My friend and fellow SharePoint MVP Eric Shupps has been promising to enter the conversation, started a number of years ago by Spence Harbar, and provide his wisdom and views on why he thinks TDD in SharePoint is just wrong!  It has been debated over email and over a SharePint for many many months.   Finally Eric has put pen to paper (or fingers to keyboard) and joined the conversation.

SPTDD: SharePoint and Test Driven Development, Part One

I now know why it took Eric so long to get his post out,  it’s taken me an hour to even read it.   As with any good debate Eric managed to get me pondering his views, what I see as misconceptions and ideas and I will be coming back with a number of posts in response.  Sorry I just can’t write that much in one blog post :)

I will start by countering a specific part of the of Erics post for the moment;   TDD has it’s origins in Extreme Programming but it is not intrinsically linked to pair programming.  I think Eric has been mislead by some more zealot supported of TDD on this.  He did however miss one of the main benefits of pair programming in his complete dismissal of the approach which is Shared Knowledge.   Later in the post he talks about lack of knowledge, poor quality developers, and also the ability to be able to actually code against SharePoint before you try something so difficult as unit testing.   Pair programming can help in this regard – but it’s something you really need to have a desire to make work.   I have used it,  it’s not for everyone and you will always have personality clashes!  I have found it to be very useful in specific areas and in small chunks.  If you do get a few really good pair programmers I think you can see improved productivity – the reality however is most people never give it long enough to see the benefits.

This entry was posted on Thursday, February 19th, 2009 at 1:41 am and is filed under SharePoint, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • pair programming in his complete dismissal of the approach which is Shared Knowledge.lack of knowledge, poor quality developers, and also the ability to be able to actually code against SharePoint before you try something so difficult as unit testing.
  • And pair programming requires patience. I think that's what makes it not-for-everyone, because we all have different limits of discipline and patience.

    Actually in the same way that Pair Programming requires discipline, it is somewhat like TDD, isn't it?

    Anyway, it all comes down to the fluffy idea-bucket we call professionalism. It combines all the skills, experience and mindset. If you strive to be a professional, you need to grow in multiple facets, and these too are pivotal examples.
  • Rick/Casey, both very good points. Doing pairing needs skills, training and experience to get the best. Much like doing SharePoint development.
  • Thank you for splitting the ideas of TDD and Pair Programming.

    One other note. Pair Programming will fail to be productive/effective quite often when someone hasn't been taught how to pair. Much like any other activity, if you haven't learned how to do it correctly from someone who has done it successfully, you'll have a tougher time getting it to work correctly.

    Trial and error is painful with pairing.
  • Pair programming requires a team of developers - not a group of individuals. When you have a team, who can think alike, can critique each other without damaging egos, and who all have a desire to learn - then pair programming is a great way to work.

    The biggest inhibitor to pair programming is insecurity.
blog comments powered by Disqus