1. University of Southern California Center for Systems and Software Engineering Technical Debt Part II CS 577 Software Engineering Supannika Koolmanojwong

2. University of Southern California Center for Systems and Software Engineering Outline Technical Debt – revisit Technical Debt quadrant Checklist to prevent Technical Debt 2

3. University of Southern California Center for Systems and Software Engineering Technical Debt “is a measure of how untidy or out-of-date the development work area for a product is” Not the deferred requirements http://www.c2.com/cgi/wiki?TechnicalDebt 3

4. University of Southern California Center for Systems and Software Engineering Symptoms of Technical Debt Lack of / poor documentation Untested code Suppressed errors Unshared knowledge between teams or people Confusing code, inconsistencies, “workarounds” Local changes you’ve not committed Code that doesn’t follow coding standards Non-existent or improperly used version control Unstable deployment process Duplicate code blocks Individual code ownership 3 rd party software that needs updated or patched. 4 http://naramore.net/slides/DPC10-techdebt.pdf

5. University of Southern California Center for Systems and Software Engineering Technical Debt “I don’t know what happened, I just changed one line” “We can’t upgrade, It will break” “We can’t upgrade the code, we don’t have time” “We can’t upgrade the code, no one understands it” “Just put in the comment XXX, we will do it later” “Just put in the TODO comment” http://petdance.com/perl/technical-debt 5

6. University of Southern California Center for Systems and Software Engineering Common causes of technical debt Business pressures Lack of process or understanding Lack of building loosely coupled components (hard-coded) Lack of documentation Parallel Development Delayed Refactoring http://en.wikipedia.org/wiki/Technical_debt 6

7. University of Southern California Center for Systems and Software Engineering Technical Debt Error-prone code “.. If I change X, it is going to break Y, I think..” “ Don’t touch that code, last time we did, we spent a week fixing it…” 20% of the code where 80% of bugs are found Hard to understand Dangerous to change because done poorly one in the first place Not rewriting this code is one of the most expensive mistakes that developers make Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUVhttp://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV http://petdance.com/perl/technical-debt/technical-debt.007.html 7

8. University of Southern California Center for Systems and Software Engineering Technical Debt Not easily tested “.. I thought we had a test for that..” Don’t have good automated tests Tests keep falling apart when you change the code Testing costs tend to go up over time as you write more code Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUVhttp://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 8

9. University of Southern California Center for Systems and Software Engineering Technical Debt Code that mysteriously works nobody is sure how or why Might be written by the geek who left the company if nobody on the team understands it, it’s a time bomb Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUVhttp://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 9

10. University of Southern California Center for Systems and Software Engineering Technical Debt Others Forward and backward compatibility –Short term debt Duplicate, copy-and-paste code –How many ? Trackable ? Hard coding Out of date documentation –“We just lost the drive, where are the backups” –If nobody is using it, get rid of it. If people are using it, why isn’t it up to date? Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUVhttp://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 10

11. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration Development Cost % Effort per Phase Technical Debt? Technical Debt? Technical Debt? Technical Debt? Real worldPerfect World 11

12. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration Development Cost % Effort per Phase Technical Debt? Technical Debt? Real worldPerfect World 12

13. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration COTS Integration % Effort per Phase Technical Debt? Real worldPerfect World 13

14. University of Southern California Center for Systems and Software Engineering Technical Debt Quadrant 14 http://martinfowler.com/bliki/TechnicalDebtQuadrant.html Somewhat OK … It lets you hit a deadline It lets you test an experimental feature The code is rarely touched Your code is at the end of the life-cycle Not OK… Sloppy Lazy Careless

15. University of Southern California Center for Systems and Software Engineering Technical Debt Quadrant 15 http://martinfowler.com/bliki/TechnicalDebtQuadrant.html We know we are taking shortcuts, but we do it anyway Sometimes we don’t know any better, or the debt is not our fault -Inexperienced team members -Requirements volatility -Post-release retrospectives -Security patches or updates from 3 rd parties http://naramore.net/slides/DPC10-techdebt.pdf

16. University of Southern California Center for Systems and Software Engineering Technical Debt Quadrant 16 http://martinfowler.com/bliki/TechnicalDebtQuadrant.htmlhttp://naramore.net/slides/DPC10-techdebt.pdf

17. University of Southern California Center for Systems and Software Engineering To tackle the technical debt Discover –Use good practices –Checklist, peer review, V&V Estimate Break Down Task & Track 17

18. University of Southern California Center for Systems and Software Engineering Managing Technical Debt Use good technical practices –TDD, Test automation, continuous integration –Refactoring, risk analysis, V&V Use a strong definition of done Properly understand technical debt economics –Cost of taking on the debt Cost of additional work Interest payment Cost of delaying the development of future products –Benefit that we may receive 18 http://innolution.com/blog/managing-the-accrual-of-technical-debt

19. University of Southern California Center for Systems and Software Engineering Checklist - Code related Well comment? Follow code style standard ? Carefully look at overly complex code –A couple layers of indenting Follow MVC pattern? LOC / class or method –The longer the worse Duplicate code anywhere ? 19 http://www.scrumalliance.org/articles/451-technical-debt-for-pms

20. University of Southern California Center for Systems and Software Engineering Checklist - Platform / architecture / build Rely on third party? –When was the last time we upgraded these components? Rely on outdated libraries? –May no loner work Standard IDE configuration? –What about other developer? How long does it take to build ? –Long build – developers lose focus Configuration? –Build in one machine ? Need separate machines? 20

21. University of Southern California Center for Systems and Software Engineering Checklist - Test Can QA team build / run automated tests? Any automated testing tools ? What % of code is covered by automated test? How do you do continuous integration? 21

22. University of Southern California Center for Systems and Software Engineering Estimate Cost of taking on the debt –Cost of additional work –Interest payment –Cost of delaying the development of future products Benefit that we may receive 22 http://naramore.net/slides/DPC10-techdebt.pdf

23. University of Southern California Center for Systems and Software Engineering Breakdown Loan = cost to fix Interest rate = adverse impact on development Every task breaks down into 2 categories –Debts where we continue paying interest –Debts where we pay the principle VB-concept –Paying it off by focusing on the highest interest rate 23

24. University of Southern California Center for Systems and Software Engineering Task and Track How can we make it visible? –Bug tracker, task board 24

25. University of Southern California Center for Systems and Software Engineering What Practitioners say about TD Short-term benefits versus Long-term Pain –Mostly intentional decisions to tradeoff –Short-term thinking reaction to the pressure –What shortcuts can you make to get the product out faster  resulting in increased complexity, poor performance, low maintainability, fragile code, reliability and stability 25 A Balancing Act: What Software Practitioners Have to Say about Technical Debt, Erin Lim, Nitin Taksande, Carolyn Seaman, IEEE Software, Vol. 29, No. 6, 22-27, 2012

26. University of Southern California Center for Systems and Software Engineering What Practitioners say about TD Software Quality versus Business Reality –System’s unpredictability –Cut back some activities - review –On several occasions, technical debt is good Deliver on time for the trade show Catch the shopping window Prototype to secure investor funding 26

27. University of Southern California Center for Systems and Software Engineering What Practitioners say about TD Customers’ expectations vs Their needs and wants –Customers don’t know what they want, not clarifying their intention –On the other hand, release product faster to get customer feedback –Uncertainty over market’s direction Becomes technical debt when receive new info –Commitment to the customer took precedence 27

28. University of Southern California Center for Systems and Software Engineering What Practitioners say about TD Measuring Debt and communicating its consequences –Not easy, impact is not uniform –Usually matter / visible to developers more than customers –Need to show tangible number to convince managers –Once they understood TD clearly, they were cooperative 28

29. University of Southern California Center for Systems and Software Engineering What Practitioners say about TD A coherent code base versus just getting stuff done –Developers see TD as bugs, defects, issues –Managers see TD as risks –People with “getting stuff done” attitude tends to incur more technical debt 29

30. University of Southern California Center for Systems and Software Engineering Lesson learned Strategies to deal with TD Do nothing – if it ain’t broke, don’t fix it –The debt might not ever become visible to the customer Use risk management –Allocate 10% of each release cycle to address TD Customer expectation management –Have open dialogue Conduct audit with the whole team and track them 30