Managers don't speak C++, refactoring and some of them don't trust the programmer's "feelings". To sell TDD to them, we have to speak the management language of costs, deadlines and delivery delays. Apply some management language and you'll be able to start the TDD.
Killer argument tips:
1) Extra testing saves at least some time of the final test round
2) Extra testing improves the code quality at least a bit
3) If extra testing is applied to the most important components and interactions, it takes not that scary amount of time
Therefore even in the worst case the time spent on the extra testing will be partially compensated with the better quality and smaller final testing efforts. And in the best case, both quality and delivery time will be improved significantly.
How do these arguments sound to you? Did you succeed in translating the programmers' issues into the management language?
RSS feed
Comments
Boss is sold, now how do I deliver?
What happens if the boss is sold, but now I have to be the evangelist to the group? I've read about and been sold on TDD for awhile, but I've never been part of a group that practiced, nor really practiced TDD on my own projects (mea culpa...)
TDD has to become part of a culture of development. How do I get that going, both for myself and for my group?
-cjw-
Demonstrate yourself and educate
Charles, I don't know any other ways then educate and educate by example.
I found that two things work well:
1) getting good coach to educate people and guide them with TDD for an iteration or two;
2) starting TDD on its own, periodically demonstrating the results and being eager to help. When people see your real world success, they are more eager to repeat it. This way people will most probably start not with unit-tests (because starting a lot of unit testing usually requires changes in the way people design code), but module-level TDD is a good first step
Post new comment