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 ?
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 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.