tag:blogger.com,1999:blog-4863981320393275450.post43234833461629479..comments2011-07-19T19:54:13.071+03:00Sarit Rosenthal-Aviramhttp://www.blogger.com/profile/04647991154558467187noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4863981320393275450.post-28968432829947800432011-07-19T19:54:13.071+03:002011-07-19T19:54:13.071+03:00Fixing a bug in TDDis really easy. Fixing a bug without tests is really hard and incurs the risk of introducing new defects, as the post mentioned. It&#39;s already a stretch to compare different projects, but comparing the time to fix hypothetical defects, you might be asking too much. i too would love to see this data, but it would take experiments, not just observation of production projects.Olivierhttp://www.blogger.com/profile/03518973924850625239noreply@blogger.comtag:blogger.com,1999:blog-4863981320393275450.post-43426858034571999612009-08-02T23:08:18.445+03:002009-08-02T23:08:18.445+03:00I absolutely agree with you that TDD has advantages and I like to do it myself. But the graphs have a problem: They compare time with defects. But we need to compare time with time. So the question is how much time does fixing the defects that remain in non TDD project cost? Is it less or more than the overhead induced by TDD? <br /><br />Is there more data available on the parallel projects, because we would have to compare maintenance times too.Peter Koflerhttp://www.blogger.com/profile/09597605582212160361noreply@blogger.com