Skip to main content

Selling TDD & Pair-programming

Last post 01:11 pm August 29, 2014 by Ian Mitchell
4 replies
05:10 am August 29, 2014

Hi folks,

My question is not about Scrum but about some common practices behind Agility.
I'm trying to sell some XP practices to the teams around me.

Everybody is buying Continuous Integration very easily.
Everybody is buying a little of pairing, but I hardly can say they practice pair-programming. And the managers always think about pair-prog = 2x more money to pay for the same line of code !

I've found this interesting study from Cockburn & Williams about this topic :

My main issue is to sell the TDD.
I have to struggle with the managers about the cost of automated unit-test, but I've found some ammunition, for instance with this study :

The developpers are buying automated unit-testing quite easily but they are always coding their unit-test after the source code.
They are still using unit-testing as a testing practice instead of trying to use TDD as a design practice.
Obviously, the study is comparing TDD with non-TDD, but I can't find ammunitions in order to convince people to go from "unit-testing after coding" to real TDD.

Do you have any advice ?

06:10 am August 29, 2014

> they are always coding their unit-test after the source code. 

Do they *always* do this?

What is the current level of code coverage, and what suggestions are they making for coverage to be improved?

08:15 am August 29, 2014

Yes, always :-(

In my company, we are developping in Java. JUnit usage is not largely adopted.
The few "agile" teams are just discovering JUnit, and they like it.
The code coverage oscillates among the projects from 50% to 75%.
In France, we fear unemployment, so when you have a job, you keep it. The consequence is we are "old" developpers here, and like every old people, we have our (bad) habits and it is very difficult to change.

The teams reaching above 50% of code coverage are very happy with that.
As a way to improve, some teams have something in their DOD like "code coverage should not goes down", but it is still very focus on testing with JUnit and not having better design & quality using pure TDD.

I don't want them to reach 90% of code coverage with JUnit, I'd like them to try real TDD, without compelling them to it.

09:27 am August 29, 2014

How good/bad is quality? It's harder to sell TDD if quality is perceived a good enough and bugs does not increase over time. Suggest to the team that you try it for some sprints and then evaluate.

01:11 pm August 29, 2014

How about approaching this from the angle of traceability? BDD and TDD are good ways of linking requirements through to code, and thereby of controlling technical debt. The PO or other senior organizational stakeholders may value this even if the Dev Team members currently don't.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.