Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)

Like this? Share it with your network


Technical Debt - Why should you care? (Agiles Buenos Aires 2011)






Total Views
Views on SlideShare
Embed Views



6 Embeds 59 35 10 6 4 3 1


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Technical Debt - Why should you care? (Agiles Buenos Aires 2011) Presentation Transcript

  • 1. Oh,  no!  Another   session  about   technical   debt?!?  
  • 2. Maybe  we  could  discuss  other  things….  
  • 3. }!before we start…! what  the  hell  is  happening  with  this  project?!?  
  • 4. }!before we start…! How  is  your  boss   here?   what  the  hell  is  happening  with  this  project?!?  
  • 5. Technical Debt! Why should you care?!   Paulo  Roberto  Camara   Tech  Manager  at  Ci&T   @proberto98! {!
  • 6. which  opCon  would  you  go  for?  •  the  easy  and  quick  way,  but  the  code  doesn’t   look  very  nice…  Future  will  be  dark…  •  a  cleaner  and  more  sophisCcated  design,  but   it  will  take  longer  to  put  in  place.  No  clouds   ahead!  
  • 7. really?  
  • 8. really,  really?  
  • 9. ah,  ok….  
  • 10. “Technical  debt  is   everything  that   makes  your  code   harder  to  change.”    (Tom  Poppendiek)  
  • 11. such  as….  •  no  design  •  poor  design  •  duplicated  code  •  deprecated  code  •  un-­‐tested  code  •  complex  code  •  any  kind  of   “workaround”…  
  • 12. the  metaphor…  •  every  Cme  you  choose  the  first  opCon  (the   quick  and  dirt  way)  you  create  debt  (like  a   financial  debt)   –  if  it  is  a  debt,  it  incurs  interest  •  you  may  pay  only  the  interest  •  or  you  may  pay  down  the  principal,  reducing   the  interest  in  the  future  
  • 13. interest?!?  •  bugs  •  extra  effort  •  slower  development  •  delays  
  • 14. hTp://­‐debt/  
  • 15. “Every  minute  spent  on  not-­‐quite-­‐right  code  counts  as   interest    on  that  debt.  EnCre  engineering  organizaCons   can  be  brought  to  a  stand-­‐sCll  under  the  debt  load  of   an  unconsolidated  implementaCon…”     (Ward  Cunningham,  1992)  
  • 16. Technical  Debt  Quadrant  (by  MarCn  Fowler  @  Agile  Brazil  2010)   hTp://  
  • 17. why  should  you  care?  
  • 18. interest?!?  •  bugs  •  extra  effort  •  slower  development  •  delays  
  • 19. a  liTle  context  (before  I  show  you  what  I  am  really   talking  about)  
  • 20. }!Ci&T at a glance! Founded in 1995! HQ in Brazil w/ offices in the US, Japan, Europe & China! Argentina and China ! Global Delivery Centers in Brazil, Staff: 1,300+! Annual growth: 40%! Provide high performance teams to our clients! / @ciandt!
  • 21. }!Our  Clients / @ciandt!
  • 22. }!What we do! Service Offerings! 
 Application Development & Management! Mobile Solutions! Cloud Computing! Product Engineering! SAP! Business Intelligence! ! / @ciandt!
  • 23. }How  we  do  it   Ci&T runs 100% ! Agile projects!! / @ciandt!
  • 24. some  sad  stories  (and  fortunately  other  very  happy  ones!)  
  • 25. }!do you remember this chart?! what  the  hell  is  happening  with  this  project?!?  
  • 26. it  is  a  true  project…  L  •  criCcal  Cme  to  market  milestone  •  prudent  technical  debt  (“let’s  fix  it  later!”)  •  yes!  We  met  the  milestone!  J  •  but….  a  new  “criCcal”  milestone  was  set…  •  more  reckless  technical  debt  (“refactoring  is  for  losers!”)  •  things  got  more  difficult  (extra  effort,  extra  bugs,  frustrated   team,  unhappy  customer…)  •  we  didn’t  meet  the  second  milestone…  L  •  two  sprints  spent  on  refactoring,  almost  no  new   funcConality  delivered…  •  a  long  Cme  to  recover  credibility.  
  • 27. Design  Stamina  Hypothesis  (by  MarCn  Fowler  @  Agile  Brazil  2010)   hTp://  
  • 28. let’s  look  another  example…   almost  40%  of   the  total  sprint   capacity   and  quality  has   became  an   issue…   what  a  hell  is  happening  with  this  project?!?  
  • 29. lack  of  automated  tests,  coCnuos  integraCon!  •  complex  billing  system  for  an  Insurance  company  •  lots  of  integraCons  with  legacy  systems  •  automated  tests  were  not  easy  to  be  created  (and  kept   working  later!)  •  and  the  Product  Owner  didn’t  accept  to  spend  sprint   capacity  with  “no  useful  code”  •  aber  a  lot  of  conversaCon  –  and  problems  –  team  was  able   to  create  a  minimal  test  suite  (one  enCre  sprint  spent  on   that!)  •  keep  this  tesCng  code  up  and  running  had  become  part  of   the  definiCon  of  done  •  in  the  following  sprint,  regression  tests  effort  dropped  half   as  well  as  the  bugs  found  by  the  PO!  J  
  • 30. a  good  reference  now!   •  a  large  building   company   •  an  18  months  project   •  high  technical  and   business  complexity   •  company  board  as  the   main  stakeholders   •  Ci&T’s  team:  12  people   •  monthly  deliveries   •  currently  at  sprint  12  
  • 31. technical  debt  under  control!  •  code  standards  /  design  /  code  reviews  /   frequent  refactoring   –  cost  to  add  new  features  is  almost  the  same  since   sprint  3  •  conCnuous  integraCon  /  automated  tests   –  daily  builds  deployed  on  customer  environment   –  completely  automated  deploy  process   –  merge  Cme  reduced  to  zero  •  quality   –  from  0,1  bugs  /  KLOC  to  0,06  bugs  /  KLOC  on   producCon   but  how?!?  
  • 32. how  to  pay  the  debt?  
  • 33. 1  –  register  
  • 34. 2  –  evaluate  
  • 35. 3  –  do  not  accumulate      
  • 36. conCnuous  integraCon    TDD    code  reviews    refactoring    ...   4  –  pay  
  • 37. and  how  about  the  product   owner?   (because  it  seems  he  is  somehow   important,  doesn’t  it?  J  )  
  • 38. you  may  see  him  as  the  bad  guy…  Ø pushing  the  team  very  hard  Ø adding  unnecessary  complexity  Ø not  opened  to  technical  arguments  
  • 39. but  he  is  the  one  who  will  have  to  pay   for  the  debt  eventually!  
  • 40. it  is  all  about  communicaCon  •  The  product  owner  –  usually  -­‐  does  not  know   what  is  refactoring,  code  review,  TDD,  etc   –  And  he  does  not  need  to  know!  •  But  he  needs  to  know  what  is  the  size  of  the  debt   and  make  conscious  decisions  about  when  and   how  to  pay  it   –  Keeping  him  in  the  loop  is  a  team  responsibility!  
  • 41. final  words  (if  you  have  just  waken  up)  
  • 42. this  deck:  hp://   Paulo  Camara   hTp://   proberto98  
  • 43. ?
  • 44. good  references  Sites   ArCcles  •  Being  Agile  –  blog  interno  da  Ci&T   •  CMMI®  or  Agile:  Why  Not  Embrace  Both!  –  by  Hillel  •  hTp://   Glazer,  Jeff  Dalton,  David  Anderson,  Mike  Konrad   and  Sandy  Shrum  •  hTp://   •  PracCcal  Roadmap  To  Great  Scrum  -­‐  Jeff  •  hTp://   Sutherland,  Ph.D.,  October  20,  2009  •  hTp://   •  Scrum  and  CMMI  -­‐  Going  from  Good  to  Great,  •  hTp://   Carsten  Ruseng  Jakobsen,  Jeff  Sutherland,  Ph.D.    Books  •  Agile  Project  Management  with  Scrum  -­‐  by  Ken   Schwaber  •  Lean  Sobware  Development:  An  Agile  Toolkit  -­‐  By   Mary  Poppendieck,  Tom  Poppendieck    •  Agile  and  IteraCve  Development:  A  Managers   Guide  -­‐  By  Craig  Larman    •  Agile  Sobware  Development  -­‐  by  Alistair  Cockburn