Rock Hymas

In typical waterfall software engineering, the development team goes away for a while and writes a bunch of code. They usually do this after a bunch of planning to estimate how long it will take to write the features they’ve decided to work on. Usually, near the end of their coding time they start cutting corners to get things to work, and if they’re lucky the software will compile and seem to work reasonably well.

At this point it is time to write the code for the Quality feature. This feature presents some challenging when you approach it:

1. The Quality feature affects all code in the product. It may require work in every class, every file, at every level of depth, and written by every developer on the project.


2. The Quality feature has a huge test matrix. Basically, think of the cross product of all the test matrices of all the features ever added to the project.


3. The Quality feature has an unknown scope. Scope is defined only as quality assurance finds bugs and the severity, reproducability, and frequency of those bugs is determined.


4. The Quality feature determines the success of the product. No other feature, no matter how cool and amazing, can make a product successful long-term if that feature does not have quality.

In the latest IEEE Software, Ron Jeffries and Grigori Melnik present some of the research done on the effects of practicing TDD on both code quality and effort expended. With only a couple of exceptions, the studies summarized show that practicing TDD increases the effort (i.e. time) required to do the work of writing code, and also increases the quality. Although the numbers vary from project to project, the implication is that you spend some more time to get higher quality code. In essence, you have one more feature that you’re developing, the feature called Quality. That feature takes some amount of time to write, and it is roughly equivalent to the increased effort required when practicing TDD. Measuring the difference in time or effort expended can provide some idea of the cost of Quality as a feature.

Quality is a feature, like performance, that can sometimes be very hard to tack on after the fact. Implementing the Quality feature while writing code through TDD and other good practices can increases our understanding of how much effort it requires. Because of the unique challenges around the Quality feature, leaving it to be done later not only decreases that understanding, but it also increases the effort required significantly.