Oh,	  no!	  Another	   session	  about	      technical	         debt?!?	  
Maybe	  we	  could	  discuss	  other	  things….	  
}!before we start…!       what	  the	  hell	  is	  happening	  with	  this	  project?!?	  
}!before we start…!                                                                          How	  is	  your	  boss	      ...
Technical Debt!  Why should you care?!   	     Paulo	  Roberto	  Camara	     Tech	  Manager	  at	  Ci&T	     proberto@cian...
which	  opCon	  would	  you	  go	  for?	  •  the	  easy	  and	  quick	  way,	  but	  the	  code	  doesn’t	     look	  very...
really?	  
really,	  really?	  
ah,	  ok….	  
“Technical	  debt	  is	    everything	  that	    makes	  your	  code	   harder	  to	  change.”	  	  (Tom	  Poppendiek)	  
such	  as….	  •    no	  design	  •    poor	  design	  •    duplicated	  code	  •    deprecated	  code	  •    un-­‐tested	 ...
the	  metaphor…	  •  every	  Cme	  you	  choose	  the	  first	  opCon	  (the	     quick	  and	  dirt	  way)	  you	  create	...
interest?!?	  •    bugs	  •    extra	  effort	  •    slower	  development	  •    delays	  
hTp://theagileexecuCve.com/category/technical-­‐debt/	  
“Every	  minute	  spent	  on	  not-­‐quite-­‐right	  code	  counts	  as	   interest	  	  on	  that	  debt.	  EnCre	  engin...
Technical	  Debt	  Quadrant	  (by	  MarCn	  Fowler	  @	  Agile	  Brazil	  2010)	                       hTp://www.marCnfowl...
why	  should	  you	  care?	  
interest?!?	  •    bugs	  •    extra	  effort	  •    slower	  development	  •    delays	  
a	  liTle	  context	  (before	  I	  show	  you	  what	  I	  am	  really	                   talking	  about)	  
}!Ci&T at a glance!                            Founded in 1995!                            HQ in Brazil w/ offices in the U...
}!Our	  Clients	   www.ciandt.com / @ciandt!
}!What we do!                 Service Offerings!                 
                 Application Development & Management!  ...
}How	  we	  do	  it	                                Ci&T runs 100% !                              Agile projects!! www.cia...
some	  sad	  stories	  (and	  fortunately	  other	  very	  happy	  ones!)	  
}!do you remember this chart?!       what	  the	  hell	  is	  happening	  with	  this	  project?!?	  
it	  is	  a	  true	  project…	  L	  •  criCcal	  Cme	  to	  market	  milestone	  •  prudent	  technical	  debt	  (“let’s	...
Design	  Stamina	  Hypothesis	  (by	  MarCn	  Fowler	  @	  Agile	  Brazil	  2010)	                       hTp://www.marCnfo...
let’s	  look	  another	  example…	                              almost	  40%	  of	                              the	  tota...
lack	  of	  automated	  tests,	  coCnuos	  integraCon!	  •  complex	  billing	  system	  for	  an	  Insurance	  company	  ...
a	  good	  reference	  now!	   •  a	  large	  building	      company	   •  an	  18	  months	  project	   •  high	  technic...
technical	  debt	  under	  control!	  •  code	  standards	  /	  design	  /	  code	  reviews	  /	     frequent	  refactorin...
how	  to	  pay	  the	  debt?	  
1	  –	  register	  
2	  –	  evaluate	  
3	  –	  do	  not	  accumulate	             	             	  
conCnuous	  integraCon	  	  TDD	  	  code	  reviews	  	  refactoring	  	  ...	                        4	  –	  pay	  
and	  how	  about	  the	  product	                 owner?	    (because	  it	  seems	  he	  is	  somehow	       important,	...
you	  may	  see	  him	  as	  the	  bad	  guy…	  Ø pushing	  the	  team	  very	  hard	  Ø adding	  unnecessary	  complexi...
but	  he	  is	  the	  one	  who	  will	  have	  to	  pay	               for	  the	  debt	  eventually!	  
it	  is	  all	  about	  communicaCon	  •  The	  product	  owner	  –	  usually	  -­‐	  does	  not	  know	     what	  is	  r...
final	  words	  (if	  you	  have	  just	  waken	  up)	  
this	  deck:	  hp://bit.ly/mWmqan	     Paulo	  Camara	                                             proberto@ciandt.com	   ...
?
good	  references	  Sites	                                                                         ArCcles	  •  Being	  Ag...
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Upcoming SlideShare
Loading in...5
×

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

2,399

Published on

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

  1. 1. Oh,  no!  Another   session  about   technical   debt?!?  
  2. 2. Maybe  we  could  discuss  other  things….  
  3. 3. }!before we start…! what  the  hell  is  happening  with  this  project?!?  
  4. 4. }!before we start…! How  is  your  boss   here?   what  the  hell  is  happening  with  this  project?!?  
  5. 5. Technical Debt! Why should you care?!   Paulo  Roberto  Camara   Tech  Manager  at  Ci&T   proberto@ciandt.com   @proberto98   www.ciandt.com! {!
  6. 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. 7. really?  
  8. 8. really,  really?  
  9. 9. ah,  ok….  
  10. 10. “Technical  debt  is   everything  that   makes  your  code   harder  to  change.”    (Tom  Poppendiek)  
  11. 11. such  as….  •  no  design  •  poor  design  •  duplicated  code  •  deprecated  code  •  un-­‐tested  code  •  complex  code  •  any  kind  of   “workaround”…  
  12. 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. 13. interest?!?  •  bugs  •  extra  effort  •  slower  development  •  delays  
  14. 14. hTp://theagileexecuCve.com/category/technical-­‐debt/  
  15. 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. 16. Technical  Debt  Quadrant  (by  MarCn  Fowler  @  Agile  Brazil  2010)   hTp://www.marCnfowler.com/bliki/TechnicalDebtQuadrant.html  
  17. 17. why  should  you  care?  
  18. 18. interest?!?  •  bugs  •  extra  effort  •  slower  development  •  delays  
  19. 19. a  liTle  context  (before  I  show  you  what  I  am  really   talking  about)  
  20. 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! 2010www.ciandt.com / @ciandt!
  21. 21. }!Our  Clients   www.ciandt.com / @ciandt!
  22. 22. }!What we do! Service Offerings! 
 Application Development & Management! Mobile Solutions! Cloud Computing! Product Engineering! SAP! Business Intelligence! !www.ciandt.com / @ciandt!
  23. 23. }How  we  do  it   Ci&T runs 100% ! Agile projects!! www.ciandt.com / @ciandt!
  24. 24. some  sad  stories  (and  fortunately  other  very  happy  ones!)  
  25. 25. }!do you remember this chart?! what  the  hell  is  happening  with  this  project?!?  
  26. 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. 27. Design  Stamina  Hypothesis  (by  MarCn  Fowler  @  Agile  Brazil  2010)   hTp://www.marCnfowler.com/bliki/DesignStaminaHypothesis.html  
  28. 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. 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. 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. 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. 32. how  to  pay  the  debt?  
  33. 33. 1  –  register  
  34. 34. 2  –  evaluate  
  35. 35. 3  –  do  not  accumulate      
  36. 36. conCnuous  integraCon    TDD    code  reviews    refactoring    ...   4  –  pay  
  37. 37. and  how  about  the  product   owner?   (because  it  seems  he  is  somehow   important,  doesn’t  it?  J  )  
  38. 38. you  may  see  him  as  the  bad  guy…  Ø pushing  the  team  very  hard  Ø adding  unnecessary  complexity  Ø not  opened  to  technical  arguments  
  39. 39. but  he  is  the  one  who  will  have  to  pay   for  the  debt  eventually!  
  40. 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. 41. final  words  (if  you  have  just  waken  up)  
  42. 42. this  deck:  hp://bit.ly/mWmqan   Paulo  Camara   proberto@ciandt.com   hTp://www.linkedin.com/in/proberto   proberto98  
  43. 43. ?
  44. 44. good  references  Sites   ArCcles  •  Being  Agile  –  blog  interno  da  Ci&T   •  CMMI®  or  Agile:  Why  Not  Embrace  Both!  –  by  Hillel  •  hTp://www.controlchaos.com/   Glazer,  Jeff  Dalton,  David  Anderson,  Mike  Konrad   and  Sandy  Shrum  •  hTp://www.mountaingoatsobware.com/scrum   •  PracCcal  Roadmap  To  Great  Scrum  -­‐  Jeff  •  hTp://jeffsutherland.com/scrum/   Sutherland,  Ph.D.,  October  20,  2009  •  hTp://www.scrumalliance.org/arCcles   •  Scrum  and  CMMI  -­‐  Going  from  Good  to  Great,  •  hTp://www.agilechronicles.com/   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        
  1. A particular slide catching your eye?

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

×