Download to read offline
Uploaded byRob Myers
The Business Value of Test-Driven Development
The document discusses the business value of Test-Driven Development (TDD) and highlights the significance of managing technical debt. It references a study showing that while teams experienced a 15-35% increase in initial development time, defect rates dropped significantly by 40% to 90%. Overall, the information underscores the potential benefits of TDD in improving software quality despite initial challenges.
More Related Content
Similar to The Business Value of Test-Driven Development
The Business Value of Test-Driven Development
- 1. 11 March 2016© Agile Institute 2008-2016 1 The Business Value of TDD Rob Myers for <client> 11 Mar 2016
- 2. 11 March 2016© Agile Institute 2008-2016 2
- 3. 11 March 2016© Agile Institute 2008-2016 3 “...having high amounts of Technical Debt is probably the number one impediment…” Dr. Dan Rawsthorne, Exploring Scrum: The Fundamentals
- 4. 11 March 2016© Agile Institute 2008-2016 4 • Design Debt • Quality Debt • Testing Debt • ...ad nauseam
- 5. 11 March 2016© Agile Institute 2008-2016 5
- 6. 11 March 2016© Agile Institute 2008-2016 6
- 7. findings of Nagappan’s IBM-Microsoftstudy • Teams noted a 15–35% increase in initial development time. • Defect rates decreased between 40% & 90%. 11 March 2016 © Agile Institute 2008-2016 7 http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf, Nagappan et al, © Springer Science + Business Media, LLC 2008
- 8. 11 March 2016© Agile Institute 2008-2016 8
- 9. 11 March 2016© Agile Institute 2008-2016 9 real value
- 10. 11 March 2016© Agile Institute 2008-2016 10 roadblocks
- 11. 11 March 2016© Agile Institute 2008-2016 11
- 12. 11 March 2016© Agile Institute 2008-2016 12 Rob.Myers@agileInstitute.com http://PowersOfTwo.agileInstitute.com/ @agilecoach https://www.linkedin.com/in/robmyers64
Editor's Notes
- #2 Intro myself. Agile has a problem.
- #3 Problem: Iterations imply incremental development Change can result in a negative feedback loop - ENTROPY: The Agilist’s Dilemma We have to address this. It’s not easy, until it becomes easy. At first, we’d rather not check the oil…
- #4 ...and I’d add “to products or projects being successful”
- #5 Types of debt They all have a few things in common: Difficult to quantify seemingly expensive to fix, accrued because we don’t want to (or aren’t sure at the time that we need to) pay now,
- #6 One Analogy for the Design The suite of tests preserves all prior behavior while we address design, allowing for Emergent Designs
- #8 Teams noted a 15–35% increase in initial development time. --- Overhead of writing more code (the code we should have been writing). --- Test-maintenance. Decreases over time as product domain settles in, and as prior objects provide help in writing new tests. Defect rates decreased between 40% & 90%. Does TDD Work? Microsoft and IBM… ROI: Quality: defect rate is considerably lower defects quickly detected Throughput of value: future enhancements easier in a dynamic market. Williams TDD found 16% increase in dev time. But only two control teams wrote tests at all.
- #10 Weinberg’s “Are Your Lights On?” Golden ______ OTIS2 data conversion OTIS2 “GUI” conversion Denali Internationalization
- #11 Roadblocks to Adoption Developers skip refactoring, don’t spend the minute to look for and clean up a new bit of code duplication. Inexperienced coaches who confuse the developer-style TDD with the team ATDD Managers waffling over the use of TDD, which limits its effectiveness POs not willing to accept the initial slow-down. …and others.
- #12 What’s expected of management?
- #13 Thank you!