Sean Corfield has just made a really good post on Test Driven Development
“What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects — 15 to 35 percent longer.”
He quotes a seemingly astonishingly useful article by Microsoft. Some of the conclusions are obvious, some are less so.
Test-Driven Development
I remember one of those 90/10 statistics from university that 90% of the costs of code lie in maintenance. If we take the lower bound of 50% (the one in the article). Then it is always useful to use test-driven development. This is kind of geeky but the only trade-off is between the cost of fixing bugs versus the upfront 35% extra cost. In a normal situation, the time spent solving 90% of you bugs would be approximately 90% of your project budget. As 90% is greater than the 35%, I can see few situations in large software development where test driven development wouldn’t be the most rational approach.
Assertions
“The research team believes that enforcing the use of assertions would not work well; rather, there needs to be a culture of using assertions in order to produce the desired results. Nagappan and his colleagues feel there is an urgent need to promote the use of assertions and plan to collaborate with academics to teach this practice in the classroom. Having the data makes this easier.”
That definitely implies that assertions fit the cost benefit test.
Outsourcing
A really interesting section on outsourcing
“Does distributed development affect software quality? An empirical case study of Windows Vista [...] found that the differences were statistically negligible”
As it was about Vista and software quality there must have been a lot of fun issues to look at. The interesting thing for me was that the out-sourcing must keep organisational cohesion. People must feel comfortable and safe with it.
Sean Corfield also threw in a little segue in his comments to another article about war-rooms being used for development. University of Michigan.
Teams in the war room environments were more than twice as productive as similar teams at the same company working in traditional office settings
We at Smarticles are still in the process of building our war room, but it sounds like a really sensible way to go.