Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From Technical Debt to Technical Health


Published on

Everyone agrees that technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they don't ever get the time to clean it up. Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
In this session, we will focus on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization. While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources. Therefore, the solutions to the technical debt problem must extend beyond the team.

Published in: Technology

From Technical Debt to Technical Health

  1. 1. From technical debt to technical health Copyright © 2016 Declan Whelan Declan Whelan Agile coach, developer
  2. 2. From technical debt to technical health Copyright © 2016 Declan Whelan Declan Whelan Agile coach, developer
  3. 3. Tom Grant Senior consultant, Net Objectives Thanks Tom!
  4. 4. The good news Software development encounters fewer constraints than other forms of invention: • No physical constraints • Lower material costs • Fewer regulations • Near instantaneous market delivery
  5. 5. The bad news Software development encounters fewer constraints than other forms of invention: • It’s easy to cut corners • The incremental cost of cutting corners is low • Hard to go back and do the work the right way • Cutting corners imposes a rising cost on innovation
  6. 6. We’re tempted to cut corners And we eventually pay for our sins
  7. 7. D
  8. 8. “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation…” Ward Cunningham What Ward said …
  9. 9. A textbook definition The increased difficulty in writing new code, or maintaining code, that is the natural result of… • Shortcuts • Bad coding practices • Hacks • Other times when we wish, in hindsight, we had coded more carefully
  10. 10. From Brian Foote: A BIG BALL OF MUD … a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.
  11. 11. A practical definition Stuff in the code that slows us down!
  12. 12. You now Future you I’M GETTING TONS OF CODING DONE! WHEEEEEE! Changing the code takes sooo loooong…
  13. 13. How do we create it? Very easily, and here are a few common examples: • Gotta get this out now! • I don’t have the time to <some good practice>… • It’s just a small thing, we’ll fix it after we ship. • No code reviews T
  14. 14. What TD is not Unidentified defects, unknown defect trends or levels, lack of clarity about quality targets. Poor processes within the team, value stream, and larger organization. Missing capabilities in the code that lower its value. A poor user experience, lowering the code’s value. Missing or weak skills within the team. TD may contribute to these problems. These problems may contribute to TD.
  15. 15. D
  16. 16. On the individual • Harder to add new software value • Harder to fix problems • Harder to work in any part of the code • Harder to get motivated about working in the code • I hear Company X is hiring… • Is this the career I wanted?
  17. 17. On the team • Lower velocity • Greater variance in velocity • Harder to break down stories • Less fluidity in task assignment • Less flow within the team • Harder to make reliable plans • Lower team morale, higher turnover
  18. 18. On the organization • Reduced value of software assets • Harder to manage the portfolio of these assets • Harder to change team or team membership • Reduced flow in the software value stream • Slower and less reliable responsiveness to critical problems • Greater friction between team and other groups
  19. 19. T
  20. 20. Technical debt gets out of control quickly Deadline pressures and uncontrolled demand • Creates incentives for cutting corners • Don’t think through decisions
  21. 21. Technical debt gets out of control quickly Unmeasured impact • Hard for non-technical people to grasp importance • If no time to avoid technical debt, there’s no time to assess it • Often lack data, especially about deep patterns
  22. 22. Technical debt gets out of control quickly Lack of experience • Unaware of agile engineering practices • Unaware of the level of risk • Unaware of the sources of risk
  23. 23. Technical debt gets out of control quickly No awareness among stake holders and executives • Don’t know or see how they contribute • Easier to blame the people than it is to address the problem
  24. 24. What’s really bad about TD Chances are, someone else left it for you
  25. 25. Exercise: Dice of Debt Game Play the game • Get into groups • Play for about 20 minutes • Please leave us the score sheet, dice and rules at the end • Please take the chart with you
  26. 26. Discuss with people at your table • Based on the game, what is the best strategy for dealing with technical debt? • Is the strategy you used in the game at all similar to the strategy you follow in real life? • Do you have a better strategy? • What is standing in your way? D
  27. 27. The OODA Loop – John Boyd
  28. 28. Observe: You can’t manage what you don’t measure
  29. 29. Observe: Measure technical debt • Individual sources: the code • Cyclomatic complexity • Duplicate code • Size of methods and classes • Aggregate effects: team & organization • Velocity • Team happiness • % of capacity lost to TD
  30. 30. Observe: Find the measures that work for your team Approaches like the SQALE model help assess amount and impact
  31. 31. Orient: yourself to the crime scene • Orient your team and the organization to the overall impact • Look for code that changes the most • Automate the measures • Make the measures visible!
  32. 32. Decide: to stop writing crappy code Include something in your team working agreement about technical debt. At an organizational level support and respect team agreements.
  33. 33. Decide: to start cleaning up old crap Include something in your team working agreement about legacy code.
  34. 34. Decide: the team Some examples … • Make code review part of the done criteria • Dedicate capacity to TD reduction and prevention • Do static code analysis • Follow the Boy Scout Rule!
  35. 35. Decide: Make TD impact part of planning • Portfolio • What investments are we willing to make? • How far are we willing to pursue them? • Project/product • What effect is TD having on… • Release planning? • Sprint planning? • Re-planning? • What are the rules for deliberately assuming TD? • Risks of taking on TD • Risks of not taking on TD • How is TD prevention and reduction built into our plans?
  36. 36. Act: Fix the code Name Good practice Affects Rationale Remediation Tested-CCOV A file has an acceptable level of code coverage. Reliability Unit tests verify that the code performs as expected without errors. Write tests in order to cover uncovered lines. Test variable values. Clear-INVL A "for" loop iterator is not modified in the body of the loop. Reliability Modifying the loop iterator inside the loop may lead to unreliable behavior. Code is also more difficult to understand. Restructure the code. Clear-DEST All "if"/"for"/"while" structures are delimited by curly braces. Changeability Using curly braces for control structures helps to better understand the code. Enclose the core of the structure with curly braces. Clear-CLDO Public classes and public methods are documented. Maintainability Code is easier to understand Identify public classes and public methods without documentation. Write additional meaningful comments. Agile Alliance Debt Analysis Model (A2DAM)
  37. 37. Act: Start automating Identify manual steps and automate! Automate tests. Automate build scripts.
  38. 38. Act: Start agile engineering practices Test driven development Refactoring Simple Design Pair/Mob Programming
  39. 39. Systems Thinking 94% of the belong to the system (responsibility of management), 6% are special cause. — W. Edwards Deming
  40. 40. Apply Systems Thinking Fundamental Fix Technical Debt t
  41. 41. Apply Systems Thinking (5 minutes) • At your table brainstorm factors that contribute to technical debt. Some things to consider: • Hiring practices • Outsourcing • Staffing up for projects • Project deadlines • Etc. • Rank then from biggest to smallest impact.
  42. 42. Apply Systems Thinking At your table brainstorm actions that would help move towards technical health: • Observe: what measures could you make? • Orient: how could you make that information relevant? • Decide: how can you make better decisions supporting technical health? • Act: what can you actually do in the next 2 weeks?
  43. 43. The conclusion should be obvious Short-term investment in technical debt reduction and prevention allows for increased productivity in the future Technical debt just keeps accumulating. Our productivity plummets. D Technical Health!
  44. 44. The Agile Alliance can help! GENERAL INFO White paper CODE A2ADAM spreadsheet TEAM Project management white paper JUSTIFICATION Dice Of Debt game Understand the nature of technical debt Assess the sources and burden of technical debt Take steps proven to be effective Educate people about the importance of dealing with technical debt