3 ms·

One thing I've noticed. TDD takes longer. It just does. You can argue that you are racking up less technical debt in the long term but every consulting gig I've

by S_A_P 9y ago

One thing I've noticed. TDD takes longer. It just does. You can argue that you are racking up less technical debt in the long term but every consulting gig I've been on where TDD was the "directive" often deteriorated because the business does not want to factor in between 40 and 100% extra time to allow proper TDD coding. They want the same somewhat arbitrary and bonus driven deadlines that they always do, and in order to meet them, we usually end up tossing out TDD halfway through and reverting to just having skilled developers get the job done as quickly as possible. THIS is the economic reality of TDD failing. A manager wanting to reduce quarterly spend so he gets his bonus doesnt care that TDD will cost him less over 5 years, he cares that he can get a project delivered on time and under budget...

s73ver 9y ago
Maybe if that bonus was tied to the amount of critical bugs that came back within the next year or so
jldugger 9y ago
> One thing I've noticed. TDD takes longer. It's not just you, there's ample evidence[1][2] that TDD is a tradeoff between delivery time and quality. I think most experienced practitioners would agree this makes sense: when the schedule slips, you can cut testing but you can't cut implementation. Works at all beats trumps works in all cases. In the TDD model, you make that decision up front, as well as the investment in tests. When the schedule slips in development, there's nowhere to cut but the most painful part, so you don't. The schedule slips. To take a contrarian position, TDD fails because it doesn't allow management to revisit decisions as reality deviates from the plan N months ago. This seems like a surprisingly non-agile approach at the high level. [1]: https://pdfs.semanticscholar.org/4dcf/5e7eed29c6707a8e1a415c5a6713a23c1d91.pdf https://pdfs.semanticscholar.org/4dcf/5e7eed29c6707a8e1a415c... [2]: https://www.infoq.com/news/2009/03/TDD-Improves-Quality https://www.infoq.com/news/2009/03/TDD-Improves-Quality

by S_A_P 9y ago

s73ver 9y ago

Maybe if that bonus was tied to the amount of critical bugs that came back within the next year or so

jldugger 9y ago

> One thing I've noticed. TDD takes longer. It's not just you, there's ample evidence[1][2] that TDD is a tradeoff between delivery time and quality. I think most experienced practitioners would agree this makes sense: when the schedule slips, you can cut testing but you can't cut implementation. Works at all beats trumps works in all cases. In the TDD model, you make that decision up front, as well as the investment in tests. When the schedule slips in development, there's nowhere to cut but the most painful part, so you don't. The schedule slips. To take a contrarian position, TDD fails because it doesn't allow management to revisit decisions as reality deviates from the plan N months ago. This seems like a surprisingly non-agile approach at the high level. [1]: https://pdfs.semanticscholar.org/4dcf/5e7eed29c6707a8e1a415c5a6713a23c1d91.pdf https://pdfs.semanticscholar.org/4dcf/5e7eed29c6707a8e1a415c... [2]: https://www.infoq.com/news/2009/03/TDD-Improves-Quality https://www.infoq.com/news/2009/03/TDD-Improves-Quality