Technical Bankruptcy

Technical Bankruptcy

What is technical bankruptcy? More to the point, what is technical debt? And what happens to software systems when the interest payments on technical debt go out of control?

Presented CukeUp 2015

8b2d2d488fa1d4ca40a2b3e4f8991799?s=128

Lukas Oberhuber

March 27, 2015
Tweet

Transcript

  1. technical bankruptcy lukas oberhuber simply business @lukasco 1

  2. who am i? simply business online insurance 290,000 policies 45

    people on tech team ~60 developing products ~100,000 lines of code increasing rapidly agile build-measure-learn 2
  3. our story new shareholder with little technology experience had to

    explain replacing 5 year old system: couldn’t improve business and it’s taken 2 years needed to understand tech debt and tech bankruptcy (they weren’t big fans of ‘the software is never done’) 3
  4. our fix old system: 1 week to make rating change

    new system: 1 hour and done by product manager 4
  5. conclusion actual bankruptcy due to technical bankruptcy is likely high

    examples friendster video management system at the bbc (cancelled) new air traffic system in the usa npfit healthcare software programme here at home 5
  6. conclusion equations that can help us reason about how much

    debt we are accumulating and paying off how that increases the effort to create change 6
  7. conclusion same behaviours in business and organisations examples signal failures

    on the london tube poorly flushing toilets at simply business non-earthquake safe bridges strikes examples of bankruptcy iraqi army garment factory that collapsed in bangladesh worldwide corruption 7
  8. conclusion couched as software you can transfer to different domain

    looking for an equation hints at the end on how to deal with tech debt 8
  9. conclusion at the end of this, you should be scared

    9
  10. but first some definitions 10

  11. definition of technical bankruptcy economic cost of to change system

    exceeds needed return for most changes even if system is working and stable implicit: change is needed implicit: software is never done 11
  12. the problem usually recognised long after bankruptcy has occurred it

    is too late to fix [imagine flossing your teeth vigorously when a root canal is needed] businesses fail because of it [example: friendster] 12
  13. definition of technical debt the work that hasn’t been done

    difference between doing something properly and the less correct way it was actually done quantified by: amount of work left to correct the implementation vs original implementation not: every possible option that could be built 13
  14. problem with technical debt makes good solutions bad increases cost

    of change starts slowly and picks up speed eventually, if not paid off, leads to tech bankruptcy 14
  15. intuition around technical debt principle needs to be paid off

    interest accrues how fast? how bad? 15
  16. definition of complexity a unit of the final product examples

    tech lines of code rows in a database function points business/organisation/other employees paragraphs in laws customers 16
  17. caveat: it’s all a hypothesis based on empirical, mathematical information

    from similar or adjacent areas a thought experiment further investigation warranted 17
  18. debt and complexity: two angles complexity is the base (good)

    debt is the accelerant (makes it worse) equation: effort to make 1 unit of change 18
  19. what does debt look like? the evidence beyond simply business

    debt makes good code bad; what does bad look like? focusing on maintenance (not exactly the same as adding a line/unit), so bear with the shift credit: Capers Jones http://www.compaid.com/caiinternet/ezine/ capersjones-maintenance.pdf 19
  20. leading excellent quality control very good code structure at the

    initial release zero error-prone modules very low bad-fix injection rate of 1% or less result: maintenance costs can actually decline over the five year ownership period 20
  21. average marginal quality control reasonable initial code structure one or

    two error-prone modules an average bad-fix injection rate of about 7% result: maintenance costs increase over a five-year period, but not at a very significant annual rate 21
  22. lagging inadequate quality control poor code structure up to a

    dozen severe error-prone modules significant bad-fix injection rates of about 20% result: maintenance costs become more expensive every year due to entropy and an application that never stabilises 22
  23. maintenance conclusion in the lagging scenario, ROI is negative in

    3-5 years meaning the system needs to be replaced; this is tech bankruptcy leading scenario can have 20 - 30 years of positive ROI 23
  24. an equation that can quantify complexity and debt complexity of

    a system which equation is the right one? acceleration of effort due to technical debt we’ll be looking for the effort to add one unit of complexity 24
  25. complexity of a system 25

  26. options for complexity measures intuition: complexity of adding a line

    of code based on how many other lines of code affected 26
  27. options for complexity measures example write tests write line of

    code change all other places (code or tests) that depend on or are affected by repeat until finished 27
  28. options for complexity measures we are looking for the ideal

    (best case) scenario n will be the amount of complexity 28
  29. http://science.slc.edu/~jmarshall/courses/2002/spring/cs50/BigO/ 29

  30. metcalfe’s law - a stretch value of a nextwork increases

    by the number of nodes because they are connected more or less n ^ 2 how does this apply? imagine building every connection, not just using it "Metcalfe-Network-Effect" by Woody993 at en.wikipedia - Transferred from en.wikipedia. Licensed under CC0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Metcalfe-Network-Effect.svg#mediaviewer/File:Metcalfe-Network-Effect.svg 30
  31. binary trees - another stretch well known properties of algorithms

    (searching for example) number of connections between nodes increases as log n http://stackoverflow.com/questions/2307283/what-does-olog-n-mean-exactly 31
  32. huge amount of work in software has been done to

    compartmentalise to avoid systemic effects object oriented programming patterns functions/procedures reusable code network layers interfaces protocols other domains methodologies for organisation change vast literature on how to run companies more effectively 32
  33. 33 All of this allows for building larger and more

    complex systems • lines of code • number of people
  34. base (best case) complexity good log(n) by decoupling and compartmentalising

    we reduce connections when a line of code is inserted, it only affects a small part of the network 34
  35. Text log n http://stackoverflow.com/questions/ 2307283/what-does-olog-n-mean- exactly 35

  36. Text 36

  37. technical debt 37

  38. technical debt in complexity terms tech debt takes log(n) of

    good code and makes it worse 38
  39. does it accumulate quickly? should: see problem, then act problems

    it’s too late to brush and floss when the teeth are falling out tech debt accumulates silently, in multiple ways, the slowdown that results is gradual and then accelerates 39
  40. does it accumulate quickly? decisions at multiple levels multiplier effect

    causing small concessions to add up quickly example management defers needed scope to gain speed team cuts corners to hit deadlines 40
  41. multiplier effect management cuts scope team cut corners resulting debt

    10% (90% done right) 10% (90% done right) 19% (0.9 * 0.9 = 0.81) 20% 20% 36% 30% 30% 51% 50% 50% 75% 41
  42. complexity log(n) 42

  43. debt: goodness 1 - debt 43

  44. debt: exponent 44 1 1 - debt

  45. together: complexity and debt log(n) 1 1 - debt 45

  46. together: complexity and debt 46 log(n) 1 1 - debt

  47. 47

  48. 48

  49. next steps for the theory prove equations are right better

    ways to measure debt and complexity 49
  50. what can you do? if you aren’t scared yet… otherwise…

    symptoms: are you leading, average or lagging? differences are easily visible debt ratio needs to be low (but no need to know it exactly) do things properly i.e. peer reviews, formal controls, good structure 50
  51. references Organisational change http://www.bristol.ac.uk/media-library/sites/cubec/migrated/documents/pr1.pdf Groups and scale http://www.shirky.com/writings/group_enemy.html Big O

    examples http://stackoverflow.com/questions/2307283/what-does-olog-n-mean-exactly Godel, Escher, Bach; I Am A Strange Loop; Douglas Hofstadter Capers Jones; Software Productivity Research Institute Quality excellence has ROI > $15 for each $1 spent; SOFTWARE QUALITY IN 2012:A SURVEY OF THE STATE OF THE ART http:// sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf http://www.compaid.com/caiinternet/ezine/capersjones-maintenance.pdf http://insights.cermacademy.com/2012/05/preventing-software-failure-capers-jones-technologyrisk/ How To Measure Anything; Douglas Hubbard "Metcalfe-Network-Effect" by Woody993 at en.wikipedia - Transferred from en.wikipedia. Licensed under CC0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Metcalfe-Network-Effect.svg#mediaviewer/File:Metcalfe-Network-Effect.svg http://science.slc.edu/~jmarshall/courses/2002/spring/cs50/BigO/ http://stackoverflow.com/questions/2307283/what-does-olog-n-mean-exactly http://stackoverflow.com/questions/2307283/what-does-olog-n-mean-exactly Dunbar number http://en.wikipedia.org/wiki/Dunbar%27s_number Estimates of projects http://www.isbsg.org/ 51
  52. references Your Code As a Crime Scene: Use Forensic Techniques

    to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill https://pragprog.com/book/atcrime/your-code-as-a-crime-scene 52
  53. questions twitter: @lukasco email: lukas.oberhuber@simplybusiness.co.uk linkdedin: uk.linkedin.com/in/lukasoberhuber 53