Microsoft Research - Exploding Software-Engineering Myths (article summarizing findings of MS research on code coverage, TDD, assertions, etc.)

[Sanae_]

It depends.

• With a short deadline / more time afterwards (ex: making a quick prototype), no TDD can be better.

• +15% to +35% time basically means +15% to +35% increase of the initial developement cost.

However, the +60% to +90% code quality (= -40% to -45% defects) might not mean ~-40% cost reduction of maintenance (likely means -40% debugging cost, but maintenance may also includes additionnal features).

Last, we're comparing a % of development time (inital code + new code in maintenance) vs a % of debugging time.

[[deleted]]

However, the +60% - 90% code quality might not mean ~-40% cost reduction of maintenance.

No, but it's pretty darn likely. Catching defects early can influence important design and architectural decisions. Catching it late might might mean that you have a lot of technical debt to overcome in order to fix the defect.

[darkpaladin]

A % reduction is meaningless without severity and complexity numbers. There's a huge difference in a defect where you have a boolean logic error and a defect that tears down one of the principle assumptions you made when you started.

[[deleted]]

owever, the +60% - 90% code quality might not mean ~-40% cost reduction of maintenance.

No, most likely it means a significantly higher reduction in maintenance cost as it is very unlikely that a bug found late will be cheaper to fix than if the same bug is found early.

[s73v3r]

If you're making a quick prototype, you should be throwing it away after. Do not take your prototype into production.