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.

Technical Debt Management

1,038 views

Published on

Technical Debt Management

For every short-cut taken technical debt is added to a project. Taking that path may come from one of many factors, including inexperience, time constraints, scope creep, or lack of resources. Managing technical debt with a professional approach can reduce the high interest rate you may be currently experiencing and lower team stress. That technical burden can be properly managed by giving proper attention, time, and resources to paying down the debt on a regular basis. Explore ways to consistently reduce technical debt and discuss best practices with fellow debtors. Learn how your code score improve and how you can avoid going bankrupt from a proper technical debt management approach.

Published in: Software
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ➤➤ http://tinyurl.com/y3hc8gpw
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Technical Debt Management

  1. 1. Reduce Your Technical Debt Mark Niebergall - https://joind.in/talk/a3f07
  2. 2. Thank You Sponsors
  3. 3. About Mark Niebergall ● PHP since 2005 ● Masters degree in MIS ● Senior Software Engineer ● Drug screening project ● UPHPU President ● SSCP, CSSLP Certified and SME ● Drones, fishing, skiing, father, husband
  4. 4. UPHPU ● 3rd Thursday of each month in Lehi ● PHP and related topics ○ Friday 6pm OpenWest review ○ August - Git ○ September - PHP TestFest ○ October - Defensive Coding ● Networking, community ● Pizza, pop, dessert, swag
  5. 5. About Mark Niebergall ● German ● Ancestry.com: nickname for someone who habitually failed to repay his debts
  6. 6. Reduce Your Technical Debt
  7. 7. Reduce Your Technical Debt ● Definition ● How it is introduced ● Impact on a project ● Avoid adding ● Paying off existing debt
  8. 8. Audience Survey ● Roles on projects ● Languages used
  9. 9. Disclaimer ● PHP technologies ● Concepts apply to other languages and projects
  10. 10. Definition
  11. 11. Definition ● Metaphor coined by Ward Cunningham ● Explained further by Martin Fowler, others
  12. 12. Definition ● Consequences of poor design, architecture ● Prudent vs reckless ● Incurred knowingly and inadvertently ● Work needed to complete job properly
  13. 13. Examples
  14. 14. Examples ● Unused code (dead wood) ● Old versions ● Dated technology ● Deprecated functionality
  15. 15. Examples ● Buggy code ● Overly complicated code ● Insecure code ● “Smelly” code
  16. 16. Examples ● Doesn’t meet requirements ● Insufficient features ● No documentation ● No unit tests
  17. 17. Examples ● Incomplete coding standards ● Missing database constraints ● Missing validation ● Tightly coupled code
  18. 18. Clearance Rack ● Food about to expire ● Questionable dairy and bread ● Items that have been sitting on the shelf a little too long
  19. 19. University Bid Sales ● Aging computers and hardware ● Obsolete items ● Never opened items ● Broken items needing repair or parts ● Piles of cables and adapters
  20. 20. The Problem
  21. 21. The Problem - Updates return a + b
  22. 22. The Problem - Updates return (a + b).toFixed(2)
  23. 23. The Problem - Updates if ( !isNaN(parseFloat(a)) || isFinite(a) || !isNaN(parseFloat(b)) || isFinite(b) ) { throw “Not a number”; } return (a + b).toFixed(2)
  24. 24. The Problem - Files index.html stuff.js morestuff.js moreawesomestuff.js utilities.js core.js
  25. 25. The Problem - Database Table: person Columns: name, address, address1, city, state, zip, phone, phone2, phone3, email, email2, address_mailing, address1_mailing, city_mailing, state_mailing, zip_mailing, create_timestamp_string, …
  26. 26. The Problem - Database Table: thing Columns: name, description, image, what_it_does, hours, location, cost, time, owner, obscure_field, ts, sd, or, qa, ei, num, + 50 more columns
  27. 27. The Problem - Security $sql = “SELECT * FROM big_table WHERE something = “ $_POST[‘from_user’]; $result = mysqli_query($sql);
  28. 28. The Problem - Architecture $value = [ ‘some_key’ => [ ‘another_key’ => [‘maybe_key’ => ‘alice’, 1 => ‘super awesome’], ‘questionable’ => [‘bob’, ‘cat’ => ‘kittens’, ‘mixed’ => new stdClass] ];
  29. 29. Sources of Technical Debt
  30. 30. Sources of Technical Debt ● New versions of libraries ● New versions of languages ● New versions of frameworks
  31. 31. Sources of Technical Debt ● Inexperience
  32. 32. Sources of Technical Debt ● Architecture changes
  33. 33. Sources of Technical Debt ● Time ● Resources ● Scope creep
  34. 34. Sources of Technical Debt ● Ignorance ● Misunderstanding of requirements ● Understanding of project
  35. 35. Sources of Technical Debt ● Unwillingness ● Lack of motivation
  36. 36. Impact
  37. 37. Impact ● Increased time to deliver new features ● Increased time to maintain application ● Increased time paying off debts ● Increased code complexity
  38. 38. Impact ● Software brittleness ● Software bloat ● Software rot ● Magic in application
  39. 39. Avoid Debt
  40. 40. Avoid Debt ● Avoid excessive debt ● Minimize risk ● Stay within means ● Use available resources ● Iron Triangle: Scope, Resources, Time
  41. 41. Avoid Debt - Operational ● Planning ● Requirements gathering ● Analyze project ● Documentation ● Acceptance tests
  42. 42. Avoid Debt - Technical ● Use a framework ● Be open to new technologies
  43. 43. Avoid Debt - Technical ● Package Manager ● Move 3rd party library out of project code ● Keep libraries, software up-to-date ● “Life is too short for old software” - Sebastian Bergmann
  44. 44. Avoid Debt - Technical ● Unit tests ● Loosely coupled code ● Code reusability ● Reduce code complexity ● Leverage language features
  45. 45. Avoid Debt - Technical ● Static code analysis tools ○ Automated way to check code health ○ Unit test coverage ○ Coding standards ○ Unused code ○ Design patterns ○ Metrics ○ Methods doing too much
  46. 46. Avoid Debt - Technical ● Dynamic code review ○ Review by a human ○ Security reviews ○ Architecture ○ Linked functionality ○ Business rules ○ Functional bugs
  47. 47. Avoid Debt - Technical ● Continuous integration tools ● Configuration management tools
  48. 48. Avoid Debt - Technical ● Code reviews and feedback ● Coding standards ● Design patterns ● General best practices
  49. 49. Paying off Debt
  50. 50. Paying off Debt ● My experience with a big project ● Included PM, developers, devops, DBAs, system administrators, QA, IT leadership ● Buy-in from upper management ● Application is faster, more stable, more secure, modernized, easier to maintain
  51. 51. Paying off Debt ● Identified pain points ● Created epics ● Set priorities ● Defined user stories
  52. 52. Paying off Debt ● Assigned work, ownership ● Regular reporting as a team ● Regular reporting to management
  53. 53. Paying off Debt ● Defined goals for quarters, years
  54. 54. Paying off Debt ● Data migration out of database and into cloud storage ● Data consolidation ● Data restructuring
  55. 55. Paying off Debt ● Adding middleware ● Framework upgrades ● Software upgrades ● Library upgrades
  56. 56. Paying off Debt ● Major overhauls in painful areas
  57. 57. Paying off Debt ● Moving processes to queue manager ● Cleaning up technology stack
  58. 58. Paying off Debt ● Security updates ● Auditing improvements
  59. 59. Paying off Debt ● Work spread out over time ● Measurable successes and milestones ● Very successful and still ongoing
  60. 60. Paying off Debt ● Make a plan ● Set goals ● Stay inside your budget
  61. 61. Paying off Debt ● Consistency ● Pay off some debt each sprint or regular interval
  62. 62. Paying off Debt ● Repeating process ○ Identify debt ○ Make a plan ○ Take action
  63. 63. Taking on Debt
  64. 64. Taking on Debt Four Rights ● Reason ● Time ● Terms ● Amount
  65. 65. Professional Development ● Participate in local user groups ● Find experienced mentors ● Attend conferences ● Read blogs ● Learn
  66. 66. Rewrite vs Refactor
  67. 67. Rewrite ● New project to replace current solution
  68. 68. Rewrite ● Sustainability of current solution is critical ● Large effort ● Long term benefits, not short ● Explore available technologies ● Prevent excessive new debt ● Higher risk of failure
  69. 69. Refactor ● Replace pieces of project in-place
  70. 70. Refactor ● Break effort up over time ● Results both short and long term ● Prioritize what to rework first ● Lower risk of failure
  71. 71. Rewrite vs Refactor ● Sustainability of current solution ● Level of effort ● Short and long term benefits ● Feasibility ● Technology stack ● Team capabilities
  72. 72. Review
  73. 73. Technical Debt ● Metaphor ● Reduce your debt ● Pay off debt using repeating process ● Tools available for your project ● Apply understanding to improve architecture
  74. 74. Questions? ● https://joind.in/talk/a3f07
  75. 75. References ● Ancestry.com http://www.ancestry.com/name-origin?surname=niebergall ● Ward Cunningham https://www.youtube.com/watch?v=pqeJFYwnkjE ● Martin Fowler http://martinfowler.com/bliki/TechnicalDebt.html ● David Laribee https://msdn.microsoft.com/en-us/magazine/ee819135.aspx ● Mark Noneman https://www.youtube.com/watch?v=cb5fkftdD9k

×