CS 577b Software Engineering II -- Introduction 23 April 2017 Technical Debt CS 510 Software Engineering Supannika Koolmanojwong © 2002-6 USC Center for Software Engineering

Outline What is Technical Debt? Technical Debt Patterns Technical Debt Calculation & Estimation Technical Debt – Industrial perspective

Technical Debt Example “Guys, we don’t have time to dot every I and cross every t on this release. Just get the code done. It doesn’t have to be perfect. We’ll fix it after we release.” “We don't have time to reconcile these two databases before our deadline, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Ref: Steve McConnell – ICSE 2013

Total cost of ownership a financial estimate whose purpose is to help consumers and enterprise managers determine direct and indirect costs of a product or system. including the costs to research, develop, acquire, own, operate, maintain, and dispose of a system ‪www.comindwork.com

Total Cost of Software Ownership www.dtbusiness.com ‪newtecharticles.com

Potential total cost of ownership Computer hardware and programs Operation expenses Long term expenses HW and SW Network Server Workstation Installation & integration Purchasing research Warranties and licenses License tracking - compliance Migration expenses Risks: susceptibility to vulnerabilities, availability of upgrades, patches and future licensing policies, etc. Infrastructure Electricity Testing costs Downtime, outage and failure expenses Diminished performance Security (including breaches, loss of reputation, recovery & prevention) Backup and recovery process Technology training Audit Insurance IT personnel Replacement Future upgrade or scalability expenses Decommissioning

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

Single System Development Perspective Choices driven by potential Market share Future opportunities Technical debt Cost of failure to provide needed capability

Technical Debt Code Debt Deficit programming Software Decay CodeSmell Toxic Code Technical Debt Software Decay coined by Ward Cunningham Design Debt Technical Inflation

Ref: Zadia Codabux and Byron J. Williams Ref: Zadia Codabux and Byron J. Williams. Managing Technical Debt: An Industrial Case Study

Technical Debt Observations “Agile Project Management”, Jim Highsmith, second edition

Types of Debt “Managing Software Debt: Building for Inevitable Change”, Chris Sterling Technical Debt These are activities that a team or team members choose not to do well now and will impede future development if left undone Quality Debt There is a diminishing ability to verify the functional and technical quality of software Configuration Management Debt Integration and release management becomes more risky, complex and error-prone Design Debt The cost of adding features is increasing toward the point where it is more than the cost of writing from scratch. Platform Debt The availability of people to work on software changes is becoming limited or cost-prohibitive. www.psmsc.com

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

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

Technical Debt intentional technical debt unintentional technical debt cost to taking short cuts unintentional technical debt making mistakes Conscious decision to optimize for the “present” rather than the “future” cost of not dealing with these short cuts and mistakes will increase over time.  Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phjvB5A9

http://pkruchten. files. wordpress http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

http://pkruchten. files. wordpress http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

http://pkruchten. files. wordpress http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

http://pkruchten. files. wordpress http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

Outline What is Technical Debt? Technical Debt Patterns Technical Debt Calculation & Estimation Technical Debt tool – Industrial perspective

Technical Debt Architecture or the platform technology mistake Scalability, reliability Foundations are poorly design you don’t find out until too late (operations phase) no choice but to start again or rewrite big chunk to keep it working Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV

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#ixzz1phnGFlUV http://petdance.com/perl/technical-debt/technical-debt.007.html

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#ixzz1phnGFlUV

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#ixzz1phnGFlUV

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#ixzz1phnGFlUV

The Cost of Undetected Defects Operation  Disposal 70% 85% 95% Committed Costs 100% 100% 90% Cost to Extract Defects 3X-6X 20X-100X 500X-1,000X 80% 70% 60% Production/ Test Cumulative Percentage of Life-Cycle Cost 50% 50% 40% Requirements errors get progressively more expensive the longer it takes to find (and fix) them. As shown in this graphic, although the percentage of total life cycle costs is relatively low in the early phases of the project, the “committed costs” rise dramatically. We make early design decisions, vendor selections, architectures are nailed down and a whole host of other system constraints are defined very early in the life cycle. This means that undetected requirements errors will progressively require more and more re-work and re-design the longer it takes to find these errors. 30% Development 20% Design 20% Concept 15% 10% 8% 0% Time Reference: Defense Systems Management College (DAU)

Development Cost(Perfect World) % Effort per Phase Analysis Design Implementation Test Integration

Classification of Defects Analysis Design Implementation Test Integration Defect Insertion Defect detection & Removal Defects Typical Defect Profiles Implementation Defects

Development Cost(Real World) % Effort per Phase Analysis Design Implementation Test Integration

Development Cost % Effort per Phase Analysis Design Implementation Test Integration Real world Perfect World

Development Cost % Effort per Phase Technical Debt? Technical Debt? % Effort per Phase Technical Debt? Not enough information in this diagram to determine whether these are technical debt. The dip in the middle could represent technical debt from trying to move things along, but paying for it in integration and test. Technical Debt? Analysis Design Implementation Test Integration Real world Perfect World

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

COTS Integration % Effort per Phase This one shows that a decision must have been made that there was no real need to perform the System Definition activities. This represents Technical Debt. Technical Debt? Analysis Design Implementation Test Integration Real world Perfect World

Fixing technical debt 80/20 rule 20% initial build 80% clean up

Outline What is Technical Debt? Technical Debt Patterns Technical Debt Calculation & Estimation Technical Debt – Industrial perspective

Financial debt vs Technical Debt Interest payments extra effort in future development because of the quick and dirty design choice continue paying the interest suffer for performance, problem is still there pay down the principal refactoring the quick and dirty design into the better design; also reduce interest payments in the future http://martinfowler.com/bliki/TechnicalDebt.html

Technical Debt Cost Estimation Principal = Repair Effort Interest = Maintenance Effort [Nugroho et al 2011] [Curtis et al 2012] Debt (in man days) cost_to_fix_duplications +  cost_to_fix_violations +  cost_to_comment_public_API +  cost_to_fix_uncovered_complexity +  cost_to_bring_complexity_below_threshold +  cost_to_cut_cycles_at_package_level Ref: Nugroho et al 2011, An Empirical Model of Technical Debt and Interest, MTD 2011 Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

No sample less than 10KSLOC 700 applications 158 organizations 357 MLOC No sample less than 10KSLOC Conservative - Assume all violations would be fixed within one hour Weighted - varied the hours needed for fixing within each severity category, More realistic - based on data observed in several IT organizations. Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

Average Technical Debt per LOC = $3.61 Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

Ref: Curtis e al 2011, Estimating the Principal of an Application's Technical Debt. IEEE Software

Technical Debt within each technology http://www.castsoftware.com/research-labs/technical-debt-estimation

Outline What is Technical Debt? Technical Debt Patterns Technical Debt Calculation & Estimation Technical Debt – Industrial perspective

Sonar Mainly manage the software quality SQALE – Software Quality Assessment based on Lifecycle Expectations

Nemo - An open source tool – by sonar http://nemo.sonarqube.org

Sonar – SQALE plug-in http://www. sonarsource

Developers’ 7 Deadly Sins Bad Distribution of Complexity Duplications Lack of Unit Tests No Coding Standards Not Enough or Too Many Comments Potential Bugs Spaghetti Design http://docs.codehaus.org/display/SONAR/Developers%27+Seven+Deadly+Sins

Developers’ 7 Deadly Sins Bad Distribution of Complexity Duplications http://docs.codehaus.org/display/SONAR/Developers%27+Seven+Deadly+Sins

Developers’ 7 Deadly Sins Lack of Unit Tests No Coding Standards http://docs.codehaus.org/display/SONAR/Developers%27+Seven+Deadly+Sins

Developers’ 7 Deadly Sins Not Enough or Too Many Comments (time consuming maintenance) Documented complex or not straightforward pieces of code Readable unit tests scenarios that will help the developers understand the code Documented API that will help external developers understand how to use those API Respect of coding standard such as naming conventions Potential Bugs http://docs.codehaus.org/display/SONAR/Developers%27+Seven+Deadly+Sins

Developers’ 7 Deadly Sins Spaghetti Design Hunting for cycles Checking your own architecture rules Managing your libraries Checking the single responsibility principle with LCOM4 (Lack of Cohesion of Methods) RFC (Response for Class) – checking coupling (complexity of class in terms of method calls) http://docs.codehaus.org/display/SONAR/Developers%27+Seven+Deadly+Sins

x = = x http://www.moovweb.com/blog/technical-debt-infographic/

Ref: Zadia Codabux and Byron J. Williams Ref: Zadia Codabux and Byron J. Williams. Managing Technical Debt: An Industrial Case Study

Back up charts

Fixing technical debt Big Bang Dedicated Team Boy Scout no new features for a year? Really?  spend some time cleaning up the mess Good ? Dedicated Team Have another team dedicated Good ? 80/20 rule ? Boy Scout remove technical debt little and often If no tests, add some. If poor test, improve them. If bad code, refactor it The boy scout rule – leave the camp cleaner than you found it http://www.javacodegeeks.com/2011/11/dealing-with-technical-debt.html#ixzz1pjQ8bQpF

Fixing technical debt Think time & risk & $$$ No gold-plating Unnecessary task that no one wants BigResearchUpFront vs BigDesignUpFront

Technical Debt vs Agile : Bad Quick and dirty approach Scalability vs DoTheSimplestThingThatCouldPossiblyWork Just-in-time Scalability change the architecture in response to actual customer demand Wasted Code http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html

Technical Debt vs Agile : Good Get feedback faster Smaller batches http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html

Technical Debt vs Lean : Good Less waste, less debt Just-in-time nature http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html

Technical Debt vs NDI : Bad Product Development Leverage Your product is fortified by others Open-source, COTS, Services Pros: Faster Cons Code understanding Different coding styles, architecture, quality No direct control http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html