Does your organization actively practice test-driven development (TDD)? Chances are, the answer is no- at least based on the results of a survey distributed at Stelligent’s TDD roundtable, which found that the majority (84%) of the survey respondents aren’t practicing TDD, and 79% said they do not measure code coverage for development projects.
Interested in gaining insight on the findings, Colleen Frye of SearchSoftwareQuality.com wrote a great article, “Barriers remain for test-driven development” asking several of the roundtable attendees why TDD wasn’t being practiced and what it would take to get organizations to do it.
When asked to elaborate on why the adoption is still slow going, Bobby Pantall, Lead Technology Consultant at CC Pace Systems Inc., remarked:
Organizations haven’t been sufficiently informed of the business benefits of TDD. In our experience, there is a popular misconception that it’s wasteful to spend so much time writing tests instead of pure functionality.
Luke Majewski, Director of Application Architecture at Intalgent, added:
The common thread when we have this discussion with other developers is their companies don’t do it because it doesn’t make sense financially. It isn’t until you complete a project fully, with good test coverage, that you really appreciate what it does.
What are your thoughts? Is your organization practicing TDD? If not, why?
December 10th, 2007 at 11:40 pm
I have written a post on why organization is not adopting TDD:
http://itscommonsensestupid.blogspot.com/2007/12/why-tdd-not-practice.html
December 17th, 2007 at 10:00 am
When tests are written apart from the ‘pure functionality’ mentioned, there’s a good chance they’re written after the functionality exists. With TDD, the tests are the code (or to put it another way, the code is squeezed out of the tests in an attempt to make the tests healthy). It’s very important to do this since as developers, we’re acknowledging our ability to introduce flaws into what we create. The fact that code does not just appear on the canvas, but goes through an internal filter of thought and collaboration (if pair programming is sought) in which any single implementation may be acceptable (some better than others) produces one or more lines of code conceived and presented in a very different manner from the normal process. We’re trusting tests to inform us when/if something’s wrong (bugs) with what we’re creating and constantly changing (refactoring) as a feature is brought to fruition.
There are a number of great teachers on this wide subject. Kent Beck probably says it best in his “Test-Driven Development” book.
January 11th, 2008 at 3:48 pm
[…] unknown wrote an interesting post today onHere’s a quick excerptChances are, the answer is no- at least based on the results of a survey distributed at Stelligent’s TDD roundtable, which found that the majority (84%) of the survey respondents aren’t practicing TDD, and 79% said they do not measure … […]