0
Technical Debt!  Why you should care!   	     Felipe	  Rubim	     Architect	  and	  Team	  Lead	  at	  Ci&T	     frubim@ci...
Oh,	  no!	  Another	   session	  about	      technical	         debt?!?	  
}!Audience survey!1.  Developers	  or	  Architects?	  2.  Product	  Owners/Project	  Managers?	  3.  Involved	  with	  Agi...
}!Different perspectives on technical debt!1.  Domain	  knowledge	  –	  ~Sprint	  3:	  “Now	  that	  we	  know	       more...
Face	  the	  brutal	  facts:	                   	     It	  will	  happen!	  
How	  is	  your	  P.O.	                                                                     here?	  what	  the	  hell	  is...
which	  opMon	  would	  you	  go	  for?	  1.  the	  easy	  and	  quick	  way,	  but	  the	  code	  and	                   ...
really?	  
really,	  really?	  
All	  right…	  
the	  metaphor	  
the	  metaphor…	  •  every	  Mme	  you	  choose	  the	  first	  opMon	  (the	     “dark	  side	  one”)	  you	  create	  deb...
“Technical	  debt	  is	     everything	  that	    makes	  your	  code	   harder	  to	  change.”	  	  (Tom	  Poppendiek	  -...
such	  as….	  •  Not	  the	  right	       design	  choices	  •  duplicated	  code	  •  lack	  of	  tests	  •  “workarounds...
interest?!?	  •    bugs	  •    extra	  effort	  •    slower	  velocity	  •    milestone	  delays	  
h_p://theagileexecuMve.com/category/technical-­‐debt/	  
“Every	  minute	  spent	  on	  not-­‐quite-­‐right	  code	  counts	  as	   interest	  	  on	  that	  debt.	  EnGre	  engin...
why	  you	  should	  care?	  
interest?!?	  •    bugs	  •    extra	  effort	  •    slower	  velocity	  •    delays	  
a	  li_le	  context	  
}!Ci&T!                            Nearshore Software Development Outsourcing company!                            HQ in Br...
}What	  do	  we	  deal	  with	      •  Different	  plaborms/technologies/       frameworks	      •  New	  developers	  (diff...
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	  •  Aggressive	  Mmeline	  to	  ship	  the	  product	      –  prudent	  technical	  de...
Design	  Stamina	  Hypothesis	  (by	  MarGn	  Fowler	  @	  Agile	  Brazil	  2010)	                       h_p://www.marMnfo...
let’s	  look	  another	  example…	                              almost	  40%	  of	                              the	  tota...
lack	  of	  automated	  tests	  and	  conMnuous	  integraMon!	  •  complex	  billing	  system	  for	  an	  insurance	  com...
a	  good	  reference	  now!	   •  a	  large	  construcMon	      company	   •  18	  months	  project	   •  High	  business	...
technical	  debt	  under	  control!	  •  code	  standards	  /	  design	  /	  code	  reviews	  /	     frequent	  refactorin...
how	  to	  pay	  the	  debt?	  
1	  –	  register	  
2	  –	  evaluate	  and	  prioriGze	  
3	  –	  do	  not	  accumulate	             	             	  
conMnuous	  integraMon	  	  	  TDD	  	  	  code	  reviews	  	  	  Refactoring	  (including	  reflecMng	  your	  new	  knowl...
And	  then	  add	  it	  to	  your	  so[ware	        development	  process	  as	  a	  technical	            debt	  reducMon...
Measure	  it	                                        Total	  Technical	  Debt	  Created	  18	  16	  14	  12	              ...
Measure	  it	  18	  16	  14	  12	                                                                                  Total	 ...
Measure	  and	  try	  and	  correlate	  it	  18	  16	  14	                                                                ...
and	  how	  about	  the	  product	                 owner?	    (because	  it	  seems	  he	  is	  somehow	        important,...
you	  may	  see	  him	  as	  the	  bad	  guy…	  Ø pushing	  the	  team	  extremely	  hard	  Ø adding	  unnecessary	  com...
but	  he	  is	  the	  one	  who	  will	  have	  to	  pay	               for	  the	  debt	  eventually!	  
it	  is	  all	  about	  communicaMon	  and	                             transparency	  •  The	  product	  owner	  –	  usua...
Technical	  Debt	  –	  To	  summarize:	  •  It’s	  expensive	  to	  fix,	  but	  much	  more	  expensive	                  ...
Thanks!	        Felipe	  Rubim	        frubim@ciandt.com	        frubim	  
?
references	  Sites	                                                                         ArMcles	  •  h_p://www.control...
Technical Debt (Qcon San Francisco 2011)
Technical Debt (Qcon San Francisco 2011)
Technical Debt (Qcon San Francisco 2011)
Technical Debt (Qcon San Francisco 2011)
Technical Debt (Qcon San Francisco 2011)
Upcoming SlideShare
Loading in...5
×

Technical Debt (Qcon San Francisco 2011)

1,728

Published on

Published in: Technology, Economy & Finance
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,728
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
47
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Technical Debt (Qcon San Francisco 2011)"

  1. 1. Technical Debt! Why you should care!   Felipe  Rubim   Architect  and  Team  Lead  at  Ci&T   frubim@ciandt.com   @frubim   www.ciandt.com! {!
  2. 2. Oh,  no!  Another   session  about   technical   debt?!?  
  3. 3. }!Audience survey!1.  Developers  or  Architects?  2.  Product  Owners/Project  Managers?  3.  Involved  with  Agile  projects?  
  4. 4. }!Different perspectives on technical debt!1.  Domain  knowledge  –  ~Sprint  3:  “Now  that  we  know   more  about  this  product,  we  should  do  something  about  that   code  we  shipped”  2.  Prudent  design  decisions  –  Sprint  1:  “Let’s  use  this   framework  now  and  adapt  to  a  beAer  framework  on  the   next  sprints”  3.  Sacrifice  of  good  soEware  development   pracGces  –  “No  Gme  for  refactoring.  We  will  deal  with   this  later”  
  5. 5. Face  the  brutal  facts:     It  will  happen!  
  6. 6. How  is  your  P.O.   here?  what  the  hell  is  happening  with  this  project?!?  
  7. 7. which  opMon  would  you  go  for?  1.  the  easy  and  quick  way,  but  the  code  and   soluMon  doesn’t  seem  quite  proper…              Future  looks  dark…  2.  a  proper  design  and  implementaMon   along  with  refactoring,  but  it  will  take   longer  to  ship.                    No  clouds  ahead!  
  8. 8. really?  
  9. 9. really,  really?  
  10. 10. All  right…  
  11. 11. the  metaphor  
  12. 12. the  metaphor…  •  every  Mme  you  choose  the  first  opMon  (the   “dark  side  one”)  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. “Technical  debt  is   everything  that   makes  your  code   harder  to  change.”    (Tom  Poppendiek  -­‐   Lean  So[ware   Development)  
  14. 14. such  as….  •  Not  the  right   design  choices  •  duplicated  code  •  lack  of  tests  •  “workarounds”  •  Unnecessary   complexity  •  …    
  15. 15. interest?!?  •  bugs  •  extra  effort  •  slower  velocity  •  milestone  delays  
  16. 16. h_p://theagileexecuMve.com/category/technical-­‐debt/  
  17. 17. “Every  minute  spent  on  not-­‐quite-­‐right  code  counts  as   interest    on  that  debt.  EnGre  engineering  organizaGons   can  be  brought  to  a  stand-­‐sGll  under  the  debt  load  of   an  unconsolidated  implementaGon…”     (Ward  Cunningham,  1992)  
  18. 18. why  you  should  care?  
  19. 19. interest?!?  •  bugs  •  extra  effort  •  slower  velocity  •  delays  
  20. 20. a  li_le  context  
  21. 21. }!Ci&T! Nearshore Software Development Outsourcing company! HQ in Brazil w/ offices in the US, Japan, Europe & China! Global Delivery Centers in Brazil, Argentina and China ! Number of developers: 1,100+! 100% agile projects!www.ciandt.com / @ciandt!
  22. 22. }What  do  we  deal  with   •  Different  plaborms/technologies/ frameworks   •  New  developers  (different  levels)   •  New  customers     •  Aggressive  Mmelines     •  One  ProducMon  System  across  the   organizaMon   www.ciandt.com / @ciandt!
  23. 23. some  sad  stories  (and  fortunately  other  very  happy  ones!)  
  24. 24. }!do you remember this chart?! what  the  hell  is  happening  with  this  project?!?  
  25. 25. it  is  a  true  project…  L  •  Aggressive  Mmeline  to  ship  the  product   –  prudent  technical  debt  (“let’s  fix  it  later!”)   –  yes!  We  met  the  milestone!  J  •  But….  a  new  “criMcal”  milestone  was  set…   –  reckless  technical  debt   –  things  got  more  difficult  (extra  effort,  extra  bugs,   frustrated  team,  unhappy  customer…)   –  two  sprints  spent  on  refactoring,  almost  no  new   funcMonality  delivered…   –  we  didn’t  meet  the  second  milestone…  L   –  a  long  Mme  to  recover  credibility.  
  26. 26. Design  Stamina  Hypothesis  (by  MarGn  Fowler  @  Agile  Brazil  2010)   h_p://www.marMnfowler.com/bliki/DesignStaminaHypothesis.html  
  27. 27. 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?!?  
  28. 28. lack  of  automated  tests  and  conMnuous  integraMon!  •  complex  billing  system  for  an  insurance  company   –  several  integraMons  with  legacy  systems   –  automated  tests  were  not  easy  to  be  created  (and  kept  working   later!)  à  not  prioriMzed   –  Product  Owner  wouldn’t  accept  to  spend  sprint  capacity  with   what  he  saw  as  “no  value”  •  a[er  some  Mme  (and  PO  not  so  happy)  team  was  able  to   create  a  minimal  test  suite  (one  enMre  sprint  spent  on   that!)   –  keep  this  tesMng  code  up  and  running  had  become  part  of  the   definiMon  of  done  (as  it  should  have  been  since  day  0)   –  in  the  following  sprint,  regression  tests  effort  dropped  half  as   well  as  the  bugs  found  by  the  PO!  J  
  29. 29. a  good  reference  now!   •  a  large  construcMon   company   •  18  months  project   •  High  business   complexity   •  company  board  as  the   main  stakeholders   (even  PO)   •  Ci&T  team:  12  people   •  monthly  shipping  
  30. 30. technical  debt  under  control!  •  code  standards  /  design  /  code  reviews  /   frequent  refactoring   –  cost  to  add  new  features  is  almost  the  same  since   sprint  3  •  conMnuous  integraMon  /  automated  tests   –  daily  builds  deployed  on  customer  environment   –  completely  automated  deploy  process   but  how?!?  
  31. 31. how  to  pay  the  debt?  
  32. 32. 1  –  register  
  33. 33. 2  –  evaluate  and  prioriGze  
  34. 34. 3  –  do  not  accumulate      
  35. 35. conMnuous  integraMon      TDD      code  reviews      Refactoring  (including  reflecMng  your  new  knowledge  about  business  domain)    Review  your  design  decisons  and  refactor  to  reflect  them       4  –  pay  
  36. 36. And  then  add  it  to  your  so[ware   development  process  as  a  technical   debt  reducMon  framework   e.g.:  part  of     ConMnuous  IntegraMon,     DefiniMon  of  done,   Daily  reviews   RetrospecMves,   …  h_p://theagileexecuMve.com/category/technical-­‐debt/  
  37. 37. Measure  it   Total  Technical  Debt  Created  18  16  14  12   Total  Technical  10   8   Debt  Created   6   4   2   0   1   2   3   4   5   6   7   8   Sprints  
  38. 38. Measure  it  18  16  14  12   Total  Technical  10   Debt  Created   Total  Technical   8   6   Debt  "Burned"   4   2   0   1   2   3   4   5   6   7   8   Sprints  
  39. 39. Measure  and  try  and  correlate  it  18  16  14   Total  Technical  Debt   Created  12  10   Total  Technical  Debt   8   "Burned"   6   Total  Value   4   AcMvaMon   2   0   1   2   3   4   5   6   7   8   Sprints  
  40. 40. and  how  about  the  product   owner?   (because  it  seems  he  is  somehow   important,  doesn’t  it?    )  
  41. 41. you  may  see  him  as  the  bad  guy…  Ø pushing  the  team  extremely  hard  Ø adding  unnecessary  complexity  Ø not  opened  to  technical  arguments  
  42. 42. but  he  is  the  one  who  will  have  to  pay   for  the  debt  eventually!  
  43. 43. it  is  all  about  communicaMon  and   transparency  •  The  product  owner  –  usually  -­‐  does  not  know   what  is  refactoring,  code  review,  TDD,  etc  •  He/she  needs  to  know  what  is  the  size  of  the   debt  and  make  conscious  decisions  about   when  and  how  to  pay  it  
  44. 44. Technical  Debt  –  To  summarize:  •  It’s  expensive  to  fix,  but  much  more  expensive   to  ignore   •  SMck  it  to  everyone’s  mind,  from  developers,   managers  to  P.Os.  The  metaphor  is  fantasMc   to  any  level  in  the  organizaMon   •  Establish  a  technical  debt  reducMon   framework  –  Measure,  correlate  and  act  
  45. 45. Thanks!   Felipe  Rubim   frubim@ciandt.com   frubim  
  46. 46. ?
  47. 47. references  Sites   ArMcles  •  h_p://www.controlchaos.com/   •  CMMI®  or  Agile:  Why  Not  Embrace  Both!  –  by  Hillel  •  h_p://www.mountaingoatso[ware.com/scrum   Glazer,  Jeff  Dalton,  David  Anderson,  Mike  Konrad   and  Sandy  Shrum  •  h_p://jeffsutherland.com/scrum/   •  PracMcal  Roadmap  To  Great  Scrum  -­‐  Jeff  •  h_p://www.scrumalliance.org/arMcles   Sutherland,  Ph.D.,  October  20,  2009  •  h_p://www.agilechronicles.com/   •  Scrum  and  CMMI  -­‐  Going  from  Good  to  Great,   Carsten  Ruseng  Jakobsen,  Jeff  Sutherland,  Ph.D.  Books    •  Agile  Project  Management  with  Scrum  -­‐  by  Ken   Schwaber  •  Lean  So[ware  Development:  An  Agile  Toolkit  -­‐  By   Mary  Poppendieck,  Tom  Poppendieck    •  Agile  and  IteraMve  Development:  A  Managers   Guide  -­‐  By  Craig  Larman    •  Agile  So[ware  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.

×