What is the Right Length for a Project?

I’ve seen many comments on the topic of estimation in the past year, and I’m starting to notice some trends and assumptions in them. One of the common assumptions is that, given a particular team and amount of resources, there is a correct length to a project. A twin to this one is that there is a correct estimate that contains the same end date as the subsequent actual project performance. (Continued)

Why I Practice TDD

I was reading Laurent Bossavit’s book, “The Leprechauns of Software Engineering—How folklore turns into fact and what to do about it,” and came across his mention of “Comparing the Defect Reduction Benefits of Code Inspection and Test-Driven Development” by Jerod W. Wilkerson, Jay F. Nunamaker, & Rick Mercer. This struck me as an odd thing to study. Not only is Test-Driven Development not primarily about defect reduction, but the populations of defects it might reduce are likely to be very different from population of defects reduced by code inspection.

I then took a look at my own list of TDD studies and noted that most of these studies were focused on external quality as measured by absence of known defects, and time it took to develop the functionality. Keith Braithwaite, at Agile 2007, reported on internal quality, specifically Cyclomatic Complexity.

Quality and productivity are, of course, important things. And they’re easy to sell to some managers. Who could be against them? And I certainly wouldn’t continue to practice Test-Driven Development if it added defects or took a significantly longer time to create functionality. But that’s not why I practice TDD. (Continued)