1 / 30

Technical Debt Part II

Technical Debt Part II. CS 577 Software Engineering Supannika Koolmanojwong. Outline. Technical Debt – revisit Technical Debt quadrant Checklist to prevent Technical Debt. Technical Debt. “ is a measure of how untidy or out-of-date the development work area for a product is ”

dot
Download Presentation

Technical Debt Part II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Technical DebtPart II CS 577 Software Engineering Supannika Koolmanojwong

  2. Outline Technical Debt – revisit Technical Debt quadrant Checklist to prevent Technical Debt

  3. 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

  4. 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 3rd party software that needs updated or patched. http://naramore.net/slides/DPC10-techdebt.pdf

  5. Technical Debt http://petdance.com/perl/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”

  6. 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

  7. Technical DebtError-prone code Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV http://petdance.com/perl/technical-debt/technical-debt.007.html “ .. 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

  8. Technical DebtNot easily tested Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV “ .. 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

  9. Technical DebtCode that mysteriously works Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 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

  10. Technical DebtOthers Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV • 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?

  11. Development Cost Technical Debt? Technical Debt? % Effort per Phase Technical Debt? Technical Debt? Analysis Test Integration Design Implementation Real world Perfect World

  12. Development Cost Technical Debt? % Effort per Phase Technical Debt? Analysis Test Integration Design Implementation Real world Perfect World

  13. COTS Integration % Effort per Phase Technical Debt? Analysis Test Integration Design Implementation Real world Perfect World

  14. Technical Debt Quadrant Not OK… Sloppy Lazy Careless 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 http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

  15. Technical Debt Quadrant 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 3rd parties http://martinfowler.com/bliki/TechnicalDebtQuadrant.html http://naramore.net/slides/DPC10-techdebt.pdf

  16. Technical Debt Quadrant http://martinfowler.com/bliki/TechnicalDebtQuadrant.html http://naramore.net/slides/DPC10-techdebt.pdf

  17. To tackle the technical debt • Discover • Use good practices • Checklist, peer review, V&V • Estimate • Break Down • Task & Track

  18. 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 http://innolution.com/blog/managing-the-accrual-of-technical-debt

  19. 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 ? http://www.scrumalliance.org/articles/451-technical-debt-for-pms

  20. 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?

  21. 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?

  22. 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 http://naramore.net/slides/DPC10-techdebt.pdf

  23. 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

  24. Task and Track • How can we make it visible? • Bug tracker, task board

  25. What Practitioners say about TD A Balancing Act: What Software Practitioners Have to Say about Technical Debt, Erin Lim, NitinTaksande, Carolyn Seaman, IEEE Software, Vol. 29, No. 6, 22-27, 2012 • 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. Lesson learnedStrategies 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

More Related