Recognizing Software Debt - Beyond Agile Puget Sound


Published on

Software debt slowly creeps into software assets if left unnoticed and can slow down delivery in ways that seemed faster initially. Fortunately, modern tools, frameworks, and software development approaches help us manage software debt effectively at a reasonable cost to implement. This program will show ways to recognize software debt in five debt areas so that you can start to manage it.

Published in: Technology, Economy & Finance
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Recognizing Software Debt - Beyond Agile Puget Sound

  1. 1. Recognizing  So+ware  DebtWednesday, November 30, 2011
  2. 2. Chris  Sterling Co-­‐founder  of  Agile  Advantage  and  VP  of   Engineering  (   Author  of  Book  “Managing  SoAware   Debt:  Building  for  Inevitable  Change” Consults  on  soAware  technology,  Agile   technical  pracKces,  Scrum,  and  effecKve   management  techniques CerKfied  Scrum  Trainer Email:   InnovaKon  Games®  Trained  Facilitator Web:  h3p:// Follow  me  on  Twi0er:  @csterwa Open  Source  Developer Blog:  h3p:// Hashtag  for  presenta:on:  #swdebt 2Wednesday, November 30, 2011
  3. 3. Go  to!!! Send  an  email  to  to   get  invited  with  your  first  impediment  now!!! 3Wednesday, November 30, 2011
  4. 4. Agenda Managing  SoAware  Debt • ConKnuous  IntegraKon • An  Overview • Quality  Dashboards Types  of  SoAware  Debt Release  Management • Technical • The  Power  of  2  Scripts:   • Quality Deploy  and  Rollback • ConfiguraKon  Management • ConKnuous  IntegraKon • Design • Automated  PromoKon • PlaUorm  Experience • Turn  On/Off  Features Balancing  Signal  to  Noise Exercise • DefiniKon  of  Done • SoAware  Debt  Management   Strategy • Source  Control  Management 4Wednesday, November 30, 2011
  5. 5. Managing  So+ware  Debt An  OverviewWednesday, November 30, 2011
  6. 6. THE  DISECONOMIES  OF  SCALE  IN  SOFTWARE  DEVELOPMENT* Project  size  is  easily  the  most  significant   determinant  of  effort,  cost  and  schedule  [for  a   soIware  project]. *  “SoIware  Es:ma:on:  Demys:fying  the  Black  Art  “  –  Steve  McConnellWednesday, November 30, 2011
  7. 7. Big  Ball  of  Mud “A  Big  Ball  of  Mud  is  a  haphazardly  structured,  sprawling,  sloppy,   duct-­‐tape-­‐and-­‐baling-­‐wire,  spagheZ-­‐code  jungle.  These  systems   show  unmistakable  signs  of  unregulated  growth,  and  repeated,   expedient  repair.  Informa:on  is  shared  promiscuously  among   distant  elements  of  the  system,  oIen  to  the  point  where  nearly  all   the  important  informa:on  becomes  global  or  duplicated.  The   overall  structure  of  the  system  may  never  have  been  well  defined.  If   it  was,  it  may  have  eroded  beyond  recogni:on.  Programmers  with  a   shred  of  architectural  sensibility  shun  these  quagmires.  Only  those   who  are  unconcerned  about  architecture,  and,  perhaps,  are   comfortable  with  the  iner:a  of  the  day-­‐to-­‐day  chore  of  patching  the   holes  in  these  failing  dikes,  are  content  to  work  on  such  systems.”  * *  Brian  Foote  and  Joseph  Yoder,  Big  Ball  of  Mud.   Fourth  Conference  on  Pa0erns  Languages  of  Programs  (PLoP  97/EuroPLoP  97)   Mon:cello,  Illinois,  September  1997Wednesday, November 30, 2011
  8. 8. Wednesday, November 30, 2011
  9. 9. Lack  of  emphasis  on  soware  quality  a2ributes   contributes  to  decayWednesday, November 30, 2011
  10. 10. Types  of  So+ware  DebtWednesday, November 30, 2011
  11. 11. Why  not  just  call  it  all  “ Technical  Debt” Technical  debt  tended  to  focus  more  on   programming  aspects  of  soIware  delivery  and   leI  out  full  soIware  development  life  cycle Each  type  of  soIware  debt  can  be  managed  and   monitored  using  different  tools  and  approaches Focusing  on  managing  each  type  of  soIware   debt  simplifies  crea:on  of  an  overall  strategy  that   promotes  holis:c  perspec:ve 11Wednesday, November 30, 2011
  12. 12. Types  of  SoIware  Debt Technical  Debt:  These  are  the  ac:vi:es  that  a  team  or  team   members  do  not  to  do  well  now  that  will  impede  future   development  if  leI  as  is. Quality  Debt:  There  is  a  diminishing  ability  to  verify  the  func:onal   and  technical  quality  of  soIware:  the  “Break/Fix”  mentality. ConfiguraHon  Management  Debt:  Integra:on  and  release   management  become  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  wri:ng  from  scratch. PlaJorm  Experience  Debt:  The  availability  and  alignment  of  people   to  business  objec:ves  that  involve  soIware  changes  is  becoming   more  limited  or  cost-­‐prohibi:ve. 8Wednesday, November 30, 2011
  13. 13. Principle:  No  maOer  what,  the  cost  of   addressing  so+ware  debt  increases   with  Hme.Wednesday, November 30, 2011
  14. 14. Balancing  Signal  to  Noise  at  ScaleWednesday, November 30, 2011
  15. 15. Balancing  Signal  Indicators   Value Quality Constraints Source:  Jim  Highsmith (Schedule,  Cost,  Scope) 15Wednesday, November 30, 2011
  16. 16. DefiniMon  of  Done  -­‐  Assert  Quality Acceptance defined criteria for each Code checked in with reference to user story US#/Task# Unit tests written and passed Tested on FE Code compiles with no errors and no Integration test written & passes warnings Test code reviewed New code doesn’t break existing code Environment requirements documented Test case review (Dev to review test Interface document updated/added case written) and checked in to SVN Architectural impact assessed and Acceptance criteria verified complete artifacts updated if necessary All P1-P3 bugs for the story are Comments in code closed Error codes added Test approves user story Code reviewed by peer Story demonstrated to product owner and accepted on Target Platform 16Wednesday, November 30, 2011
  17. 17. Release  DefiniMon  of  Done Every  release  should  have  clear  quality  criteria With  a  “Release  Defini:on  of  Done”  you  can   understand  targets  be0er Measure  the  gap  between  the  teams’  Defini:on   of  Done  and  a  Release  Defini:on  of  Done. • This  gap  is  a  source  of  quality  issues  and  represents   significant  risk  to  scheduleWednesday, November 30, 2011
  18. 18. Release  DefiniMon  of  Done Every  release  should  have  clear  quality  criteria With  a  “Release  Defini:on  of  Done”  you  can   understand  targets  be0er Measure  the  gap  between  the  teams’  Defini:on   of  Done  and  a  Release  Defini:on  of  Done. • This  gap  is  a  source  of  quality  issues  and  represents   significant  risk  to  scheduleWednesday, November 30, 2011
  19. 19. TradiMonal  Source  Control  Management 18Wednesday, November 30, 2011
  20. 20. TradiMonal  Source  Control  Management Main  Branch 18Wednesday, November 30, 2011
  21. 21. TradiMonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Main  Branch 18Wednesday, November 30, 2011
  22. 22. TradiMonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March 18Wednesday, November 30, 2011
  23. 23. TradiMonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March { Debt  accrues  quickly  within  stabilizaHon  periods 18Wednesday, November 30, 2011
  24. 24. Flexible  Source  Control  Management 19Wednesday, November 30, 2011
  25. 25. Flexible  Source  Control  Management Main Branch 19Wednesday, November 30, 2011
  26. 26. Flexible  Source  Control  Management Version 1 Main Branch 19Wednesday, November 30, 2011
  27. 27. Flexible  Source  Control  Management Version 1 Version 2 Main Branch 19Wednesday, November 30, 2011
  28. 28. Flexible  Source  Control  Management Version 1 Version 2 Main Branch { Not Easy! Must have proper infrastructure to do this. 19Wednesday, November 30, 2011
  29. 29. ConMnuous  IntegraMon 20Wednesday, November 30, 2011
  30. 30. Quality  Dashboard  -­‐  Sonar 21Wednesday, November 30, 2011
  31. 31. Quality  Dashboard  -­‐  Sonar 22Wednesday, November 30, 2011
  32. 32. Quality  Dashboard  -­‐  Sonar 23Wednesday, November 30, 2011
  33. 33. Quality  Dashboard  -­‐  Sonar 24Wednesday, November 30, 2011
  34. 34. Early  Warning  Signs Early  Warnings: •Broken  Builds •Broken  Automated  Tests •Broken  Custom  Thresholds 25Wednesday, November 30, 2011
  35. 35. Early  Warning  on  Quality  Dashboard Early  Warnings: •Design  Debt  in  Duplica:on  (DRY) •Technical  Debt  in  Code  Complexity •Quality  Debt  in  Bug  DB  (Break/Fix) •Other  Custom  Thresholds 26Wednesday, November 30, 2011
  36. 36. Release  Management  StrategyWednesday, November 30, 2011
  37. 37. “If  releases  are  like  giving  birth,  then   you  must  be  doing  something  wrong.”   -­‐  Robert  BenefieldWednesday, November 30, 2011
  38. 38. Case  Study:  Enterprise  Agile  AdopMon 180+  person  “Web  2.0”  product  organiza:on Waterfall  SDLC  that  development  uses  to  deliver  in  6  month  release   cycles Want  to  use  Agile  methods  to  be  more  responsive  to  users  and  keep  up   with  other  “Web  2.0”  companies Transi:oned  to  Agile  methods  on  15  teams  in  3  months Changed  release  management  strategy,  added  XP  technical  prac:ces,   and  implemented  Scrum  product  development  framework  for  scaled   coordina:on Able  to  release  every  week  to  users  within  4  months Used  streamlined  deployment  environment  process  to  validate  product   changes  daily  using  Con:nuous  Integra:on  and  automated  promo:ons 29Wednesday, November 30, 2011
  39. 39. The  Power  of  2  Scripts:  Deploy  &  Rollback 30Wednesday, November 30, 2011
  40. 40. Scaling  ConMnuous  IntegraMon End-­‐to-­‐End  & Load/Stress Integrated   Component ValidaHon Component ValidaHon 31Wednesday, November 30, 2011
  41. 41. Automated  PromoMon  to  Environments 32Wednesday, November 30, 2011
  42. 42. The  value  of  technical  aspects  in  an   applica:on  or  its  surrounding  infrastructure   is  the  cost  of  not  addressing  them. 29Wednesday, November 30, 2011
  43. 43. Describe  as  Abuse  User  Stories Implement Security for User Information *  From  “User  Stories  Applied”  presented  by  Mike  Cohn  Agile  2006   30Wednesday, November 30, 2011
  44. 44. Describe  as  Abuse  User  Stories Implement Security As a Malicious Hacker I want to steal credit card for User Information information so that I can make fraudulent charges *  From  “User  Stories  Applied”  presented  by  Mike  Cohn  Agile  2006   30Wednesday, November 30, 2011
  45. 45. Some  PotenMal  Abusers • Malicious  Hacker • Mass  of  users • SQL  injector • Disgruntled  employee • Naïve  API  user • ImpaBent  clicker • Denial-­‐of-­‐service  (DoS)  aFacker • Sleazy  user 31Wednesday, November 30, 2011
  46. 46. SoIware  Quality  A0ributes  Defined 32Wednesday, November 30, 2011
  47. 47. SoIware  Quality  A0ributes  Ra:ng  Tool 33Wednesday, November 30, 2011
  48. 48. Put  SoIware  Debt  on  Product  Roadmap *  Image  from  Dean  Leffingwell’s  blog  -­‐  h0p:// 34 38Wednesday, November 30, 2011
  49. 49. Exercise:  So+ware  Debt  Management   StrategyWednesday, November 30, 2011
  50. 50. Thank  you! QuesHons  &  AnswersWednesday, November 30, 2011
  51. 51. Come  see  us  at 41Wednesday, November 30, 2011
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.