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 bankruptcy
lukas oberhuber
simply business
who am i?
simply business
online insurance
290,000 policies
45 people on tech team
~60 developing products
~100,000 lines ...
our story
new shareholder with little technology experience
had to explain replacing a 5 year old system: we couldn’t impr...
our fix
old system took 1 week for rating change
new system 1 hour by product manager
conclusion
actual bankruptcy due to technical bankruptcy is likely high
examples
friendster
video management system at the...
conclusion
i have equations can help us reason about
how much debt we are accumulating and paying off
how that increases t...
conclusion
same behaviours in business and organisations
examples
signal failures on the london tube poorly flushing toile...
conclusion
everything will be couched as software
i will leave to you to transfer this to your domain
hints at the end of ...
but first some definitions
definition of technical bankruptcy
economic cost of to change system exceeds needed return for most
changes
even if system...
the problem
usually recognised long after bankruptcy has occurred
it is too late to fix [imagine flossing your teeth vigor...
definition of technical debt
the work that hasn’t been done
difference between doing something properly and the less corre...
problem with technical debt
makes good solutions bad
increases cost of change
starts slowly and picks up speed
eventually,...
intuition around technical debt
principle needs to be paid off
interest accrues
how fast?
how bad?
definition of complexity
a unit of the final product
examples
tech
lines of code
rows in a database
function points
busine...
caveat: it’s all a hypothesis
the equations and all else are hypotheses based on empirical,
mathematical information from ...
debt and complexity: two angles
complexity is the base
debt is the accelerant (makes it worse)
what does debt look like? the
evidence beyond simply business
debt makes good code bad; what does bad look like?
focusing ...
leading
excellent quality control
very good code structure at the initial release
zero error-prone modules
very low bad-fi...
average
marginal quality control
reasonable initial code structure
one or two error-prone modules
an average bad-fix injec...
lagging
inadequate quality control
poor code structure
up to a dozen severe error-prone modules
significant bad-fix inject...
maintenance conclusion
in the lagging scenario, ROI is negative in 3-5 years meaning the
system needs to be replaced; this...
an equation that can quantify
complexity and debt
complexity of a system
which equation is the right one?
acceleration of ...
complexity of a system
options for complexity measures
intuition that complexity of adding a line of code is based on how many other lines of cod...
http://science.slc.edu/~jmarshall/courses/2002/spring/cs50/BigO/
metcalfe’s law - this is a
stretch
value of the nextwork increases by the number of
nodes because they are connected
how d...
binary trees - another stretch
well known properties of algorithms
number of connections between nodes increases as log n
...
huge amount of work in software has been done to
compartmentalise to avoid systemic effects
object oriented programming
pa...
base (best case) complexity
good
log(n)
by decoupling and compartmentalising we reduce connections
when a line of code is ...
Text
log n
http://stackoverflow.com/questions/
2307283/what-does-olog-n-mean-
exactly
Text
technical debt
technical debt in complexity terms
tech debt takes log(n) of good code and makes it worse
does it accumulate quickly?
see problem, then act
two problems
it’s too late to brush and floss when the teeth are falling...
does it accumulate quickly?
not noticed because decisions are made at multiple levels
there is a multiplier effect causing...
multiplier effect
management cuts scope team cut corners resulting debt
10%
(90% done right)
10%
(90% done right)
19%
(0.9...
together: complexity and debt
log(n)
1
1 - debt
together: complexity and debt
log(n)
1
1 - debt
debt vs lines of code
productivity
next steps for the theory
investigation to prove equations are right
better ways to measure debt and complexity
what can you do?
if you aren’t scared yet…
otherwise…
symptoms: are you leading, average or lagging?
differences are easil...
referencesOrganisational change http://www.bristol.ac.uk/media-library/sites/cubec/migrated/documents/pr1.pdf
Groups and s...
questions
twitter: @lukasco
email: lukas.oberhuber@simplybusiness.co.uk
linkdedin: uk.linkedin.com/in/lukasoberhube
This presentation was delivered
at an APM event
To find out more about upcoming events
please visit our website
www.apm.or...
Upcoming SlideShare
Loading in …5
×

Technical debt bankruptcy, Wednesday 21st January 2015

852 views

Published on

A presentation given by Lukas Oberhuber to the APM Planning, Monitoring and Control SIG and guests at the University of Warwick, Coventry 2015.

Lukas Oberhuber, Simply Business – technical debt bankruptcy occurs when it’s too late to fix things after the failure. Do things right, don’t take short cuts or else the debt will build up, e.g. Floss your teeth, don’t wait until they fall out, because then it’s too late. Not flossing is the technical debt.

Published in: Business
  • Be the first to comment

  • Be the first to like this

Technical debt bankruptcy, Wednesday 21st January 2015

  1. 1. technical bankruptcy lukas oberhuber simply business
  2. 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
  3. 3. our story new shareholder with little technology experience had to explain replacing a 5 year old system: we couldn’t improve the business anymore in trying to explain, we had to understand tech debt and tech bankruptcy (and they weren’t big fans of ‘the software is never done’)
  4. 4. our fix old system took 1 week for rating change new system 1 hour by product manager
  5. 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
  6. 6. conclusion i have equations can help us reason about how much debt we are accumulating and paying off how that increases the effort to create change
  7. 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
  8. 8. conclusion everything will be couched as software i will leave to you to transfer this to your domain hints at the end of how to deal with tech debt
  9. 9. but first some definitions
  10. 10. 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. 11. 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. 12. 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. 13. 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. 14. intuition around technical debt principle needs to be paid off interest accrues how fast? how bad?
  15. 15. definition of complexity a unit of the final product examples tech lines of code rows in a database function points business/organisation/othe r employees paragraphs in laws customers
  16. 16. caveat: it’s all a hypothesis the equations and all else are hypotheses based on empirical, mathematical information from similar or adjacent areas this is primarily a thought experiment therefore further investigation is definitely warranted
  17. 17. debt and complexity: two angles complexity is the base debt is the accelerant (makes it worse)
  18. 18. 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 slight shift credit: Capers Jones http://www.compaid.com/caiinternet/ezine/capersjones-maintenance.pdf
  19. 19. 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. 20. 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. 21. 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 will become more expensive every year due to entropy and the fact that the application never stabilises
  22. 22. 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 in contrast can have 20 - 30 years of positive ROI
  23. 23. 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. 24. complexity of a system
  25. 25. options for complexity measures intuition that complexity of adding a line of code is based on how many other lines of code are affected example write tests write line of code change all other places (code or tests) that depend on or are affected by repeat until finished we are looking for the ideal (best case) scenario n will be the amount of complexity
  26. 26. http://science.slc.edu/~jmarshall/courses/2002/spring/cs50/BigO/
  27. 27. metcalfe’s law - this is a stretch value of the nextwork increases by the number of nodes because they are connected how does this apply? more or less n ^ 2 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
  28. 28. binary trees - another stretch well known properties of algorithms number of connections between nodes increases as log n http://stackoverflow.com/questions/2307283/what-does-olog-n-mean-exactly
  29. 29. huge amount of work in software has been done to compartmentalise to avoid systemic effects object oriented programming patterns the concept of a function or procedure libraries of reusable code layers (like the network layers) interfaces protocols other domains methodologies for executing organisation change vast literature on how to run companies more effectively All of this allows for building larger and more complex systems • lines of code • number of people
  30. 30. 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 of connections
  31. 31. Text log n http://stackoverflow.com/questions/ 2307283/what-does-olog-n-mean- exactly
  32. 32. Text
  33. 33. technical debt
  34. 34. technical debt in complexity terms tech debt takes log(n) of good code and makes it worse
  35. 35. does it accumulate quickly? see problem, then act two 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
  36. 36. does it accumulate quickly? not noticed because decisions are made at multiple levels there is a multiplier effect causing small concessions to add up quickly example management defers needed scope to gain speed team cuts corners to hit deadlines
  37. 37. 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%
  38. 38. together: complexity and debt log(n) 1 1 - debt
  39. 39. together: complexity and debt log(n) 1 1 - debt
  40. 40. debt vs lines of code
  41. 41. productivity
  42. 42. next steps for the theory investigation to prove equations are right better ways to measure debt and complexity
  43. 43. 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
  44. 44. referencesOrganisational 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/ Estimates of projects http://www.isbsg.org/
  45. 45. questions twitter: @lukasco email: lukas.oberhuber@simplybusiness.co.uk linkdedin: uk.linkedin.com/in/lukasoberhube
  46. 46. This presentation was delivered at an APM event To find out more about upcoming events please visit our website www.apm.org.uk/events

×