Selling TDD & Pair-programming
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 : http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf
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 :
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
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 ?
> 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?
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.
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.
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.