Given the rapidly increasing demand for software products in practically every field, the effectiveness of software development is becoming more and more crucial. In recent years, many methods have been developed to address this issue. One of them is test-driven development (TDD).

The basic idea is charming. As the authors explain in the introduction: programmers think through the design before actually writing the code. The idea sounds nice and logical, but does it really improve any of the characteristics of effective development, like code quality, productivity, and maintainability?

It is a credit to the authors that they check this in a practical experiment and present real figures, although derived from a rather small sample. The idea of their experiment is quite simple. They selected three commercial projects with well-defined and comparable specifications from the telecommunications domain for the same external customer. Through “equal quality targets and requirements on time to market[,] ... all three projects demanded equal structures and experiences” from their project teams.

Two projects are run using a (classical) test-first process, and one uses test-last as the most significant characteristic of TDD. Thus, by measuring project execution and results metrics, like quantity of produced code (software and test), number of defects found before and after delivery, and code complexity, TDD can be compared with the test-first process.

The authors admit of course that three projects are too few to obtain strong results. Nevertheless, there are some very interesting indications. It is not surprising to learn that external code quality is improved through TDD. However, the price paid is decreased productivity. This in turn is partially balanced by improved maintainability, and thus decreased costs in the long run. Improved software complexity certainly contributes to this maintainability.

There is another interesting part in this study: the authors interviewed the engineers in the TDD project for their impressions and feedback. Although most of them confirmed the additional effort required to follow the TDD method, compared to the test-first process, they clearly acknowledged code quality improvements.

Besides presenting the study and its results in detail, the authors dedicate an entire section to comprehensively reviewing background information and TDD-related work. They also discuss challenges to the validity of their results--again, one challenge is obviously the small size of the dataset.

Nevertheless, this paper is a very interesting investigation of the practical impacts of TDD on software development effectiveness. It merits a large audience and more empirical studies in the industry.