The Software Debt Bubble: Is It About to Burst


Published on

This is a keynote presentation that I am delivering at Cutter Agile Mexico 2011 in Mexico, City August 2011.

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Software Debt Bubble: Is It About to Burst

  1. 1. The  Soware  Debt  Bubble Is  it  about  to  burst? Chris Sterling VP of Engineering Agile Advantage, Inc. Web: Email: Blog: Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebtMonday, January 9, 2012
  2. 2. Chris  Sterling  -­‐  Sr.  Cuer  Consultant • CTO  at  Agile  Advantage,  Inc. • Author  of  Book  “Managing   So@ware  Debt:  Building  for   Inevitable  Change” • Consults  on  So@ware  Debt   Management  Strategies • Conducts  Technical  Debt   Assessments • CerGfied  Scrum  Trainer email: • InnovaGon  Games®  Trained   blog:   Facilitator web: follow  me  @csterwa hashtag:  #swdebt Un  evento  de  Monday, January 9, 2012
  3. 3. Project  size  is  easily  the  most  significant  determinant  of  effort,  cost  and   schedule  [for  a  so:ware  project]. THE  DISECONOMIES  OF  SCALE  IN   SOFTWARE  DEVELOPMENT* *  “So@ware  EsGmaGon:  DemysGfying  the  Black  Art  “  –  Steve  McConnell Un  evento  de  Monday, January 9, 2012
  4. 4. “A  Big  Ball  of  Mud  is  a  haphazardly  structured,  sprawling,  sloppy,   duct-­‐tape-­‐and-­‐baling-­‐wire,  spagheE-­‐code  jungle.  These  systems   show  unmistakable  signs  of  unregulated  growth,  and  repeated,   expedient  repair.  InformaJon  is  shared  promiscuously  among   distant  elements  of  the  system,  o:en  to  the  point  where  nearly   all  the  important  informaJon  becomes  global  or  duplicated.  The   overall  structure  of  the  system  may  never  have  been  well  defined.   If  it  was,  it  may  have  eroded  beyond  recogniJon.  Programmers   with  a  shred  of  architectural  sensibility  shun  these  quagmires.   Only  those  who  are  unconcerned  about  architecture,  and,   perhaps,  are  comfortable  with  the  inerJa  of  the  day-­‐to-­‐day  chore   of  patching  the  holes  in  these  failing  dikes,  are  content  to  work   on  such  systems.”  * Big  Ball  of  Mud *  Brian  Foote  and  Joseph  Yoder,  Big  Ball  of  Mud.   Fourth  Conference  on  PaTerns  Languages  of  Programs  (PLoP  97/EuroPLoP  97)   MonJcello,  Illinois,  September  1997 Un  evento  de  Monday, January 9, 2012
  5. 5. Un  evento  de  Monday, January 9, 2012
  6. 6. Lack  of  emphasis  on  soware  quality  a2ributes   contributes  to  decay Un  evento  de   6Monday, January 9, 2012
  7. 7. The  “Rewrite”,  “NextGen”   or  “Like-­‐to-­‐like  MigraJon” • “It  will  be  easy  since  we  worked  on  the  original  version”  -­‐   although  we  understand  the  domain  we  will    be  fighGng  with   new  features,  technology,  tools,  and  processes • “We  don’t  have  any  other  opGons”  -­‐  Refactoring  and  test   automaGon  are  potenGal  alternaGves  to  like-­‐to-­‐like  migraGons. Un  evento  de   7Monday, January 9, 2012
  8. 8. Why  RewriGng  is  (Almost)  Never  a   Good  Idea  * 1.It  will  take  longer  than  you  think 2.Markets  change 3.Exis=ng  customers  become  frustrated 4.Refactoring  can  clean  up  the  code 5.You  don’t  control  the  rewrite,  it  controls  you “Why You Should (Almost) Never Rewrite Your Software” - post to by Dharmesh Shah Un  evento  de   8Monday, January 9, 2012
  9. 9. Types  of  So@ware  Debt • Technical  Debt:  These  are  the  acGviGes  that  a  team  or  team   members  choose  not  to  do  well  now  and  will  impede  future   development  if  le@  undone. • Quality  Debt:  There  is  a  diminishing  ability  to  verify  the   funcGonal  and  technical  quality  of  so@ware. • Configura<on  Management  Debt:  IntegraGon  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  wriGng  from  scratch. • Pla@orm  Experience  Debt:  The  availability  of  people  to  work  on   so@ware  changes  is  becoming  limited  or  cost-­‐prohibiGve. Un  evento  de   8Monday, January 9, 2012
  10. 10. “Lowering  quality  lengthens  development  Jme.”  -­‐  From  wiki  page  on   “First  Law  of  Programming”  ( TECHNICAL  DEBT Un  evento  de   9Monday, January 9, 2012
  11. 11. PaMerns  of  Technical  Debt Duplica@on Schedule  Pressure Get  it  “right”  the   first  @me  mentality Un  evento  de   10Monday, January 9, 2012
  12. 12. Aspects  of  the  soJware’s  design  that  teams   agree  to  should  be  automated,  if  possible,   and  break  the  build  when  they  are  not   adhered  to. Un  evento  de   11Monday, January 9, 2012
  13. 13. Keep  DRY  (Don’t  Repeat  Yourself) *  Sonar  -­‐  an  open  source  quality  dashboard hTp://   Un  evento  de   12Monday, January 9, 2012
  14. 14. Remove  Complexity *  Sonar  -­‐  an  open  source  quality  dashboard hTp://   Un  evento  de   13Monday, January 9, 2012
  15. 15. Trend  Technical  Debt  Metrics *  Sonar  -­‐  an  open  source  quality  dashboard hTp://   Un  evento  de   14Monday, January 9, 2012
  16. 16. Trend  Technical  Debt  Metrics*  SQALE  -­‐  a  commercial  Sonar  plugin Un  evento  de   15hTp://­‐sqale/overview/  Monday, January 9, 2012
  17. 17. No  ma2er  what,  the  cost  of  addressing   technical  debt  increases  with  <me. Un  evento  de   16Monday, January 9, 2012
  18. 18. “Promises  make  debt,  and  debt  makes  promises.”  -­‐  Dutch  Proverb QUALITY  DEBT Un  evento  de   17Monday, January 9, 2012
  19. 19. Effect  of  Project  Constraints  on  Quality Un  evento  de   18Monday, January 9, 2012
  20. 20. Effect  of  Project  Constraints  on  Quality Un  evento  de   18Monday, January 9, 2012
  21. 21. “For  every  [dollar]  of  compe==ve  advantage   gained  by  cuAng  quality,  it  costs  $4  to  restore  it;   and  soJware  is  an  organiza=onal  asset  and   decisions  to  cut  quality  must  be  made  by   execu<ve  management  and  reflected  in  the   financial  statements.”   -­‐-­‐  Ken  Schwaber,  co-­‐creator  of  Scrum Un  evento  de   19Monday, January 9, 2012
  22. 22. Acceptance  Test-­‐Driven  Development Un  evento  de   20Monday, January 9, 2012
  23. 23. Cost  reducJon  using  Fit  for  acceptance  test  automaJon  for  insurance   company  plaeorm  and  data  migraJon  project AN  ACCEPTANCE  TEST-­‐DRIVEN  DEVELOPMENT CASE  STUDY Un  evento  de   21Monday, January 9, 2012
  24. 24. Manual  Regression  TesGng • Tes=ng  was  taking  75  person  hours  during  2   full  test  runs  consis=ng  of: – Comprehensive  manual  regression  tesJng – Data  conversion  and  validaJon • Cost  for  tes=ng  was  $17,000  each  itera@on Un  evento  de   22Monday, January 9, 2012
  25. 25. Introducing  Fit  into  TesGng  Process • A:er  8  itera@ons  team  had  introduced  healthy   amount  of  Fit  fixtures  and  automated  tests • Reduced  70+  hour  test  runJme  down  to  6  hours   which  now  included: – Fit  automated  regression  tesJng   – Data  conversion  and  validaJon  automated  with  Fit   fixtures   • Reduced  cost  of  tesJng  each  iteraJon  from   $17,000  to  $7,000 Un  evento  de   23Monday, January 9, 2012
  26. 26. “If  releases  are  like  giving  birth,  then  you  must  be  doing  something   wrong.”  -­‐-­‐  Robert  Benefield CONFIGURATION  MANAGEMENT   DEBT Un  evento  de   24Monday, January 9, 2012
  27. 27. Case  Study:  Enterprise  Agile  AdopJon • 180+  person  “Web  2.0”  product  organizaJon • 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 • TransiJoned  to  Agile  methods  on  15  teams  in  3  months • Changed  release  management  strategy,  added  XP  technical  pracJces,   and  implemented  Scrum  product  development  framework  for  scaled   coordinaJon • Able  to  release  every  week  to  users  within  4  months • Used  streamlined  deployment  environment  process  to  validate   product  changes  daily  using  ConJnuous  IntegraJon  and  automated   promoJons Un  evento  de   25Monday, January 9, 2012
  28. 28. The  Power  of  2  Scripts:  Deploy  and  Rollback Un  evento  de   26Monday, January 9, 2012
  29. 29. Automated  PromoGon  to  Environments Un  evento  de   27Monday, January 9, 2012
  30. 30. Design  decays  when  not  aTended  to  so  design  so:ware  conJnually DESIGN  DEBT Un  evento  de   28Monday, January 9, 2012
  31. 31. The  value  of  technical  aspects  in  an   applica=on  or  its  surrounding  infrastructure  is   the  cost  of  not  addressing  them. Un  evento  de   29Monday, January 9, 2012
  32. 32. Describe  as  Abuse  User  Stories Implement Security for User Information *  From  “User  Stories  Applied”  presented  by  Mike  Cohn  Agile  2006   Un  evento  de   30Monday, January 9, 2012
  33. 33. Describe  as  Abuse  User  Stories As a Malicious Hacker I Implement Security 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   Un  evento  de   30Monday, January 9, 2012
  34. 34. Some  PotenGal  Abusers • Malicious  Hacker • Mass  of  users • SQL  injector • Disgruntled  employee • Naïve  API  user • ImpaJent  clicker • Denial-­‐of-­‐service  (DoS)  aTacker • Sleazy  user Un  evento  de   31Monday, January 9, 2012
  35. 35. So@ware  Quality  AMributes  Defined Un  evento  de   32Monday, January 9, 2012
  36. 36. So@ware  Quality  AMributes  RaGng  Tool Un  evento  de   33Monday, January 9, 2012
  37. 37. Put  So@ware  Debt  on  Product  Roadmap *  Image  from  Dean  Leffingwell’s  blog  -­‐  hTp:// Un  evento  de   34Monday, January 9, 2012
  38. 38. “As  in  Nature,  if  an  organizaJon  is  too  inflexible  or  stands  sJll  too  long  it   will  get  eaten.”  -­‐  James  Burke  (author  and  historian) PLATFORM  EXPERIENCE  DEBT Un  evento  de   35Monday, January 9, 2012
  39. 39. Rather  than  crea=ng  teams  to  work  on   projects,  let’s  find  ways  to  give  projects  to   cross-­‐func<onal  teams. Un  evento  de   36Monday, January 9, 2012
  40. 40. Component  Team  ConfiguraGon • “Component  Team”  structure • Separate  Product  Backlog • Managing  dependencies  is  o:en   serialized • ProblemaJc  integraJon  issues  are   typically  faced  if  mulJple   components  are   required  to  release • Use  an  “IntegraJon Team”  to  pull   components  together • Causes  more  rework  than   “Feature  Team”  structure Un  evento  de   37Monday, January 9, 2012
  41. 41. Feature  Team  ConfiguraGon • “Feature  Team”  structure • Uses  common  Product  Backlog • IntegraJon  is  done  in  parallel • Requires  high  levels  of   communicaJon  across  teams   to  resolve  integraJon  issues • Forces  Product  Owners  to   be  more  coordinated   • Sprints  should  be  synchronized • Cross  team  ferJlizaJon  is  a requirement  to  successfully   deliver  in  parallel Un  evento  de   38Monday, January 9, 2012
  42. 42. “What  he  needs  is  some  way  to  pay  back.  Not  some  way  to  borrow   more.”  -­‐-­‐  Will  Rogers THE  “NO  DEFECT”  MINDSET Un  evento  de   39Monday, January 9, 2012
  43. 43. Case  Study:  Field  Support  ApplicaGon • 2000+  users  access  applicaGon  each  day • ApplicaGon  supports  mulGple  perspecGves  and  workflows   from  Field  Support  OperaGons  to  Customer  Service • Team  of  5  people  delivering  features  on  exisGng  Cold  Fusion   plahorm  implementaGon • MigraGng  Architecture  to  Spring/Hibernate  in  slices  while  sGll   delivering  valuable  features • 36  2-­‐week  Sprints,  33  producGon  releases,  and  only  1  defect   found  in  producGon • So,  what  was  the  defect  you  say?  Let  me  tell  you… Un  evento  de   40Monday, January 9, 2012
  44. 44. Can  We  Afford  a  “No  Defect”  Policy? • This  team  worked  on  legacy  codebase  inherited  from  another  vendor • Other  vendor  had  been  slowing  down  month  a:er  month  and  cost  of   development  was  increasing • In  first  iteraJon  this  team  was  able  to  deliver  more  than  other  vendor   was  able  to  in  previous  2  months • A:er  24  iteraJons  this  team  was  10  Jmes  faster  delivery  than1st   iteraJon • Acceptance  Test-­‐Driven  Development  and  ConJnuous  IntegraJon  were   greatest  technical  factors  to  support  team  in  these  results • Can  you  afford  not  to  have  a  “No  Defect”  policy? Un  evento  de   41Monday, January 9, 2012
  45. 45. Acceptance  Test-­‐Driven  Development Un  evento  de   42Monday, January 9, 2012
  46. 46. The  Power  of  2  Scripts:  Deploy  and  Rollback Un  evento  de   43Monday, January 9, 2012
  47. 47. Thank  you Ques=ons  and  Answers Un  evento  de   44Monday, January 9, 2012