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

2. University of Southern California Center for Systems and Software Engineering Wednesday Oct 30 Team Presentation Each team will briefly introduce your project Team 3 – OCD: Boundary Diagram, Business Workflow, Project plan (5 minutes) Team 4 – Prototype (10 minutes) Team 6 – Prototype (10 minutes) Team 13 – Prototype (10 minutes) Team 14 – Prototype (10 minutes) Team 16 – Prototype (10 minutes) Team 15 – Risks & Configuration Management & Quality Management Strategy (5 minutes) 2

3. University of Southern California Center for Systems and Software Engineering Outline Total Cost of Ownership Technical Debt 3

4. University of Southern California Center for Systems and Software Engineering What are the cost of a software? Think about the whole life cycle 4

5. University of Southern California Center for Systems and Software Engineering 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 5

6. University of Southern California Center for Systems and Software Engineering Potential total cost of ownership Computer hardware and programs Operation expensesLong 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 6

7. University of Southern California Center for Systems and Software Engineering 7

8. University of Southern California Center for Systems and Software Engineering Relative* Total Ownership Cost (TOC) For single system life cycle (TOC-SS) ~5% architecture investment ~25% architecture investment * Cumulative architecting and rework effort relative to initial development effort

9. University of Southern California Center for Systems and Software Engineering Technical Debt coined by Ward Cunningham

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

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

12. University of Southern California Center for Systems and Software Engineering Interest paymentsextra 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 principalrefactoring the quick and dirty design into the better design; also reduce interest payments in the future http://martinfowler.com/bliki/TechnicalDebt.html 12

13. University of Southern California Center for Systems and Software Engineering http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf 13

14. University of Southern California Center for Systems and Software Engineering Technical Debt intentional 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#ixzz1phjvB5A9http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phjvB5A9 14

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

16. University of Southern California Center for Systems and Software Engineering 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#ixzz1phnGFlUVhttp://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 16

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

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

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

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

21. University of Southern California Center for Systems and Software Engineering Technical Debt Cost 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 http://docs.codehaus.org/display/SONAR/Technical+Debt+Calculation average $3.61 to $5.42 per line of code. Example of Technical Debt Calculation 21

22. University of Southern California Center for Systems and Software Engineering Technical Debt Observations “Agile Project Management”, Jim Highsmith, second edition 22

23. University of Southern California Center for Systems and Software Engineering Types of Debt “M anaging 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 23

24. University of Southern California Center for Systems and Software Engineering 70% 85% 95% Committed Costs Cost to Extract Defects 3X-6X 20X-100X 500X-1,000X The Cost of Undetected Defects 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Cumulative Percentage of Life-Cycle Cost 15% Design 20% Development 50% Production/ Test 100% Operation  Disposal Concept 8% Reference: Defense Systems Management College (DAU) Time 24

25. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration Development Cost(Perfect World) % Effort per Phase 25

26. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration Defect InsertionDefect detection & Removal Design Defects Integration Defects Typical Defect Profiles Implementation Defects Classification of Defects 26

27. University of Southern California Center for Systems and Software Engineering Analysis DesignImplementation TestIntegration Development Cost(Real World) % Effort per Phase 27

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

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

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

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

32. University of Southern California Center for Systems and Software Engineering Fixing technical debt 80/20 rule –20% initial build –80% clean up 32

33. University of Southern California Center for Systems and Software Engineering Fixing technical debt Big Bang –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 33

34. University of Southern California Center for Systems and Software Engineering Fixing technical debt $$$Think time & risk & $$$ No gold-plating –Unnecessary task that no one wants BigResearchUpFront vs BigDesignUpFront 34

35. University of Southern California Center for Systems and Software Engineering 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 35

36. University of Southern California Center for Systems and Software Engineering Technical Debt vs Agile : Good Get feedback faster Smaller batches http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html 36

37. University of Southern California Center for Systems and Software Engineering Technical Debt vs Lean : Good Less waste, less debt Just-in-time nature http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html 37

38. University of Southern California Center for Systems and Software Engineering 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 38

39. University of Southern California Center for Systems and Software Engineering http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf 39

40. University of Southern California Center for Systems and Software Engineering 40 http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

41. University of Southern California Center for Systems and Software Engineering 41 http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

42. University of Southern California Center for Systems and Software Engineering Enablers and Inhibitors of Technical Debt For a new single system For an existing single system A system of systems 42

43. University of Southern California Center for Systems and Software Engineering Top 10 Inhibitors – Similarities 43 A New Single SystemAn Existing Single SystemA System of Systems Requirements Volatility Lack of Interoperability UnprecedentednessHigh numbers of external interfaces Lack of / incompatible standard & protocol Delayed authority to proceed/start with fixed milestone UnprecedentednessRequirements Volatility Infeasible schedule/staffing profileVague RequirementsUnprecedentedness Lack of Domain ExperienceEmbedded poor quality softwareHigh numbers of external interfaces Technology VolatilityConflicting StakeholdersInfeasible schedule/staffing profile High numbers of external interfaces Delayed authority to proceed/start with fixed milestone Inability to test across systems Vague RequirementsInfeasible schedule/staffing profile Delayed authority to proceed/start with fixed milestone Under average people / Personnel Capability Technical debtLack of Domain Experience Technology ImmaturityInteroperability / compatibilityTechnology Volatility

44. University of Southern California Center for Systems and Software Engineering Top 10 Inhibitors – Differences 44 A New Single SystemAn Existing Single SystemA System of Systems Requirements Volatility Lack of Interoperability UnprecedentednessHigh numbers of external interfaces Lack of / incompatible standard & protocol Delayed authority to proceed/start with fixed milestone UnprecedentednessRequirements Volatility Infeasible schedule/staffing profileVague RequirementsUnprecedentedness Lack of Domain ExperienceEmbedded poor quality softwareHigh numbers of external interfaces Technology VolatilityConflicting StakeholdersInfeasible schedule/staffing profile High numbers of external interfaces Delayed authority to proceed/start with fixed milestone Inability to test across systems Vague RequirementsInfeasible schedule/staffing profile Delayed authority to proceed/start with fixed milestone Under average people / Personnel Capability Technical debtLack of Domain Experience Technology ImmaturityInteroperability / compatibilityTechnology Volatility

45. University of Southern California Center for Systems and Software Engineering Top 10 Enablers - Similarities 45 A New Single SystemAn Existing Single SystemA System of Systems Rapid Prototyping Target hardware lab / test like you fly & simulation Customer /tech requirements flexibility Target hardware lab / test like you fly & simulation Incremental test and feedbackRapid Prototyping Customer /tech requirements flexibilityIncremental Delivery & feedback Target hardware lab / test like you fly & simulation Incremental test and feedbackFlexible / Tailorable rulesIncremental test and feedback Incremental Delivery & feedbackAgile/lean approachCommon standard and protocol Decision making authorityRapid PrototypingReusing assets Best people / personnel capabilityCommon standard, interfaceTools and automation Agile/lean approachCustomer /tech requirements flexibilityCommon standard, interface Less context switching when doing multiple projects Domain knowledgeBest people / Personnel Capability Tools and automation Understanding of the existing system and interfaces Team cohesion

46. University of Southern California Center for Systems and Software Engineering Top 10 Enablers - Differences 46 A New Single SystemAn Existing Single SystemA System of Systems Rapid Prototyping Target hardware lab / test like you fly & simulation Customer /tech requirements flexibility Target hardware lab / test like you fly & simulation Incremental test and feedbackRapid Prototyping Customer /tech requirements flexibilityIncremental Delivery & feedback Target hardware lab / test like you fly & simulation Incremental test and feedbackFlexible / Tailorable rulesIncremental test and feedback Incremental Delivery & feedbackAgile/lean approachCommon standard and protocol Decision making authorityRapid PrototypingReusing assets Best people / personnel capabilityCommon standard, interfaceTools and automation Agile/lean approachCustomer /tech requirements flexibilityCommon standard, interface Less context switching when doing multiple projects Domain knowledgeBest people / Personnel Capability Tools and automation Understanding of the existing system and interfaces Team cohesion

47. University of Southern California Center for Systems and Software Engineering Observations Flip side of a coin 47 EnablersInhibitors Best peopleUnder average people Decision making authorityLack of decision making authority Team CohesionConflicting stakeholders Incremental Test and FeedbackInability to test across systems

48. University of Southern California Center for Systems and Software Engineering Observations Grey Area Common standard Flexible rules Requirements Volatility Requirements Flexibility Agile/lean approach Constituent Documentation 48

49. University of Southern California Center for Systems and Software Engineering Observations Overlap & Similar but not the same Lack of Domain Experience Unprecedentedness Technology Immaturity Technology Volatility Lack of decision making at lower levels Lack of decision making authority 49

50. University of Southern California Center for Systems and Software Engineering The bottom line Trade off between –Technical Debt –Flexibility (Design for Reuse) –Expedition 50

51. University of Southern California Center for Systems and Software Engineering References http://pkruchten.files.wordpress.com/2011/ 10/kruchten-111027-techdebt.pdfhttp://pkruchten.files.wordpress.com/2011/ 10/kruchten-111027-techdebt.pdf 51