Minimize the number of different routines called by a class.
One study found that the number of faults in a class was statistically correlated with the total number of routines that were called form within a class (Basili, Briand, and Melo 1996). The same study found that the more classes a class used, the higher its fault rate tended to be. These concepts are sometimes called "fan out".
Code Complete - Steve McConnell, page 150 paragraph 4There is evidence that doing TDD takes about 15% longer than not doing TDD (George and Williams 2003). But there is also evidence that TDD leads to fewer defects. Two studies at Microsoft found that the number of bugs found went down by 24% and 38% with the use of TDD (Sanchez, Williams, and Maximilien 2007, 6). So, yes, TDD may take longer initially, but the time will come back to the team in the form of reduced bug fixing and maintenance time.
Succeeding with Agile: Software Development using Scrum - Mike Cohn, page 158 paragraph 1QSMA calculates a productivity index for the projects in its database. This index takes into consideration effort, schedule, technical difficulty, and more and is an attempt to help make cross-team comparisons more meaningful. In his comparison between agile and traditional projects, Mah found agile projects to be 16% more productive, an increase that he found to be statistically significant.
Succeeding with Agile: Software Development using Scrum - Mike Cohn, page 11 paragraph 5The QSMA study comparing 26 agile projects to a database of 7,500 mostly traditional projects found that agile projects have a 37% faster time to market.
Succeeding with Agile: Software Development using Scrum - Mike Cohn, page 14 paragraph 3David Rico's research bears out the claim that agile teams produce higher quality products. In his survey of 51 published studies of agile projects, he found a minimum quality improvement of 10% and a median improvement of 63%.
Succeeding with Agile: Software Development using Scrum - Mike Cohn, page 15 paragraph 3