Assessing Test-Driven Development at IBM

Author(s): E.M. Maximilien and L. Williams
Venue: Proc. Int'l Conf. Software Eng. (ICSE)
Date: 2003


Methodology: TDD
Company: IBM Retail Store Solutions (RSS)
Type of project: JavaPOS Device Drivers
# of developers: 9
Language: JavaPOS
Team Domain Experience:
Collocation: Distributed
Code Size (KLOC) New; Base; Total: Na, 71.4, na
Junit code (KLOC): 34
Automated test of code: 86.00%
FVT Effort: 50.00%
Test Cases/ Total LOC: 0.476 TC
Defects/KLOC: 4

The productivity number was slightly below 400 LOC/person-month. The credit to this productivity was due t o the new use of Microsoft Project Central which the team believe has improved the project management practices and kept the developers consistent about making visible progress on their tasks. Some of the learning that came out of this includes the following. Start TDD from the beginning of the project and assure the team that the practice will have ultimately minimal impact to their productivity. If the team is new to TDD introduce automated build test integration towards the second third of the development phase in order for the team to adjust and become familiar with TDD. Prior to this, all developers should run all of the test cases on their own local machines. Whenever a defect is found, add a new test case that would detect that defect and have it added to the test build. The outcome of this study seems to be successful and had a positive impact on the project.