technical debt - why should you care? (agiles buenos aires 2011)

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…!}!

what  the  hell  is  happening  with  this  project?!?  

How  is  your  boss  here?  

Technical Debt!Why should you care?!

www.ciandt.com!

{!

 Paulo  Roberto  Camara  Tech  Manager  at  Ci&T  proberto@ciandt.com  @proberto98  

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!  

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  code  •  complex  code  •  any  kind  of  “workaround”…  

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  

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  engineering  organizaCons  can  be  brought  to  a  stand-­‐sCll  under  the  debt  load  of  

an  unconsolidated  implementaCon…”    (Ward  Cunningham,  1992)  

Technical  Debt  Quadrant  (by  MarCn  Fowler  @  Agile  Brazil  2010)  

hTp://www.marCnfowler.com/bliki/TechnicalDebtQuadrant.html  

why  should  you  care?  

interest?!?  

•  bugs  •  extra  effort  •  slower  development  •  delays  

a  liTle  context  

(before  I  show  you  what  I  am  really  talking  about)  

2010

Ci&T at a glance!}!

www.ciandt.com / @ciandt!

Founded in 1995!HQ in Brazil w/ offices in the US, Japan, Europe & China!

Global Delivery Centers in Brazil, Argentina and China !Staff: 1,300+!Annual growth: 40%!Provide high performance teams to our clients!

Our  Clients  }!

www.ciandt.com / @ciandt!

What we do!}!

www.ciandt.com / @ciandt!

Service Offerings!

Application Development & Management!Mobile Solutions!Cloud Computing!Product Engineering!SAP!Business Intelligence!!

How  we  do  it  }

www.ciandt.com / @ciandt!

Ci&T runs 100% !Agile projects!!

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  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.  

Design  Stamina  Hypothesis  (by  MarCn  Fowler  @  Agile  Brazil  2010)  

hTp://www.marCnfowler.com/bliki/DesignStaminaHypothesis.html  

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?!?  

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  

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  

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?!?  

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,  doesn’t  it?  J  )  

you  may  see  him  as  the  bad  guy…  

Ø pushing  the  team  very  hard  

Ø adding  unnecessary  complexity  

Ø not  opened  to  technical  arguments  

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  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!  

final  words  

(if  you  have  just  waken  up)  

Paulo  Camara  proberto@ciandt.com  

hTp://www.linkedin.com/in/proberto  

proberto98  

this  deck:  h\p://bit.ly/mWmqan  

?

good  references  Sites  •  Being  Agile  –  blog  interno  da  Ci&T  •  hTp://www.controlchaos.com/  •  hTp://www.mountaingoatsobware.com/scrum  •  hTp://jeffsutherland.com/scrum/  •  hTp://www.scrumalliance.org/arCcles  •  hTp://www.agilechronicles.com/  

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  Manager's  

Guide  -­‐  By  Craig  Larman    •  Agile  Sobware  Development  -­‐  by  Alistair  Cockburn  

ArCcles  •  CMMI®  or  Agile:  Why  Not  Embrace  Both!  –  by  Hillel  

Glazer,  Jeff  Dalton,  David  Anderson,  Mike  Konrad  and  Sandy  Shrum  

•  PracCcal  Roadmap  To  Great  Scrum  -­‐  Jeff  Sutherland,  Ph.D.,  October  20,  2009  

•  Scrum  and  CMMI  -­‐  Going  from  Good  to  Great,  Carsten  Ruseng  Jakobsen,  Jeff  Sutherland,  Ph.D.