Cómo reducir la fricción en el desarrollo de software
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Cómo reducir la fricción en el desarrollo de software

on

  • 401 views

Como sabemos, la fricción es "la resistencia que encuentra un objeto o superficie al intentar moverse sobre otra". Por analogía, en el desarrollo de software la fricción es el conjunto de factores ...

Como sabemos, la fricción es "la resistencia que encuentra un objeto o superficie al intentar moverse sobre otra". Por analogía, en el desarrollo de software la fricción es el conjunto de factores que limitan el progreso y por lo tanto reducen la velocidad (productividad).

Los dos principales elementos de fricción que enfrentan los proyectos de software son la deuda técnica y la deuda social. En esta conferencia platicaremos sobre cómo reconocer ambos tipos de deuda y como lidiar con cada una, para lograr así reducir la fricción y aumentar la velocidad en nuestros proyectos de software.

Semblanza del conferencista:
Philippe Kruchten ha sido arquitecto de software por más de 35 años, primero en Alcatel y posteriormente en Rational Software (ahora IBM), trabajando principalmente en el desarrollo de grandes sistemas para los sectores aeroespacial, telecomunicación y transporte. Philippe dirigió el desarrollo del Rational Unified Process (RUP) de 1995 a 2003, y es autor del modelo arquitectónico de "4+1 vistas" que utilizaba el RUP. Actualmente es profesor de ingeniería de software en la Universidad de British Columbia en Vancouver, y su investigación de los últimos años se ha enfocado en los temas de deuda técnica, y administración del conocimiento arquitectónico. @pbpk

Statistics

Views

Total Views
401
Views on SlideShare
401
Embed Views
0

Actions

Likes
1
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

Cómo reducir la fricción en el desarrollo de software Document Transcript

  • 1. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   1   Cómo  reducir  la  fricción  en   el  desarrollo  de  soAware    Philippe  Kruchten   Mexico,  June  26,  2014     Reducing  FricIon  in   SoAware  Development    Philippe  Kruchten   Mexico,  June  26,  2014    
  • 2. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   2   Philippe  Kruchten,  Ph.D.,  P.Eng.,  CSDP   Professor  of  So)ware  Engineering   NSERC  Chair  in  Design  Engineering   Department  of  Electrical  and  Computer  Engineering   University  of  BriIsh  Columbia   Vancouver,  BC  Canada   pbk@ece.ubc.ca           Founder  and  president   Kruchten  Engineering  Services  Ltd   Vancouver,  BC  Canada     philippe@kruchten.com     3 Copyright  ©  2014    Philippe  Kruchten   FricIon   “There  is  sIll  much  fricIon  in  the  process  of   craAing  complex  soAware;  the  goal  of  creaIng   quality  soAware  in  a  repeatable  and  sustainable   manner  remains  elusive  to  many  organizaIons,   especially  those  who  are  driven  to  develop  in   Internet  Ime.”   Copyright  ©  2014    Philippe  Kruchten   Grady  Booch’s  keynote  at   ICSE  2000  in  Limerick,  Ireland  
  • 3. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   3   FricIon   “FricIon:  the  resistance  that     one  surface  or  object  encounters    when  moving  over  another.”     In  soAware  development,  fricIon  is  the  set  of   phenomena  that  limits  or  constraints  our  progress,   therefore  reduces  our  velocity  (or  producIvity).     Technical  debt  causes  fricIon.   Copyright  ©  2014    Philippe  Kruchten   6   FricIon  and  Debt   Copyright  ©  2014    Philippe  Kruchten   7   Technical  Debt   Social  Debt   Fric@on   Reduced  velocity   Defects   Delays   …  
  • 4. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   4   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   8  Copyright  ©  2014    Philippe  Kruchten   Technical  Debt   •  Concept  introduced  by  Ward  Cunningham   •  OAen  menIoned,  rarely  studied   •  All  experienced  soAware  developers  “feel”  it.   •  Drags  long-­‐lived  projects  and  products  down   9  Copyright  ©  2014    Philippe  Kruchten  
  • 5. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   5   Origin  of  the  metaphor   •  Ward  Cunningham,  at  OOPSLA  1992    “Shipping  first  Ime  code  is  like  going   into  debt.  A  liile  debt  speeds  development     so  long  as  it  is  paid  back  promptly  with  a     rewrite…   The  danger  occurs  when  the  debt  is  not     repaid.  Every  minute  spent  on  not-­‐quite-­‐right  code   counts  as  interest  on  that  debt.  EnIre  engineering   organizaIons  can  be  brought  to  a  stand-­‐sIll  under  the   debt  load  of  an  unconsolidated  implementaIon,   object-­‐oriented  or  otherwise.”   Cunningham,  OOPSLA  1992   10  Copyright  ©  2014    Philippe  Kruchten   Technical  Debt  (S.  McConnell)   •  Implemented  features  (visible  and     invisible)  =  assets  =  non-­‐debt   •  Type  1:  unintenIonal,  non-­‐strategic;     poor  design  decisions,  poor  coding   •  Type  2:  intenIonal  and  strategic:     opImize  for  the  present,  not  for  the     future.   –  2.A  short-­‐term:  paid  off  quickly  (refactorings,  etc.)   •  Large  chunks:  easy  to  track   •  Many  small  bits:  cannot  track   –  2.B  long-­‐term   McConnell  2007   11  Copyright  ©  2014    Philippe  Kruchten  
  • 6. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   6   Technical  Debt  DefiniIon  (2013)   •  A  design  or  construcIon  approach   that  is  expedient  in  the  short   term,  but  that  creates  a  technical   context  in  which  the  same  work   will  cost  more  to  do  later  than  it   would  cost  to  do  now  (including   increased  cost  over  Ime).   McConnell  2013   12  Copyright  ©  2014    Philippe  Kruchten   Technical  Debt  (M.    Fowler)   Fowler  2009,  2010   13  Copyright  ©  2014    Philippe  Kruchten  
  • 7. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   7   First  more  capabiliIes   First  more  infrastructure   Then,  more  infrastructure   Then,  more  capabiliIes   underesImated     re-­‐architecIng  costs   neglected  cost  of  delay   to  market   need  to  monitor  technical   debt  to  gain  insight  into   life-­‐cycle  efficiency   Example   Ozkaya,  SEI,2010   14  Copyright  ©  2014    Philippe  Kruchten   Technical  Debt  (Chris  Sterling)   •  Technical  Debt:  issues  found  in  the  code   that  will  affect  future  development  but   not   those  dealing  with  feature  completeness.   Or   •  Technical  Debt  is  the  decay  of     component  and  intercomponent     behaviour  when  the  applicaIon   funcIonality  meets  a  minimum     standard  of  saIsfacIon  for  the   customer.   15  Copyright  ©  2014    Philippe  Kruchten  
  • 8. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   8   Time  is  Money  (I.  Gat)   •  Convert  this  in  monetary  terms:      “Think  of  the  amount  of  money  the     borrowed  Ime  represents  –  the     grand  total  required  to  eliminate     all  issues  found  in  the  code”   Gat  2010   16  Copyright  ©  2014    Philippe  Kruchten   Example:  TD  is  the  sum  of…   •  Code  smells    167  person  days   •  Missing  tests    298  person  days   •  Design        670    person  days   •  DocumentaIon      67  person  days       Totals    Work          1,202  person  x  days    Cost          $577,000   17  Copyright  ©  2014    Philippe  Kruchten  
  • 9. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   9   Tech  Debt  (Jim  Highsmith)   Source:  Highsmith,  2009  18  Copyright  ©  2014    Philippe  Kruchten   Value,  Quality,  Constraints   •  Value  =  extrinsic  quality   –  Metric:  Net  present   value   •  Quality  =  intrinsic   quality   –  Metric:  Technical  debt   •  Constraints  =  cost,   schedule,  scope   –  Metric:  Cost   Value   Quality         Cost    Highsmith  2010   19  Copyright  ©  2014    Philippe  Kruchten  
  • 10. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   10   State  of  affairs   •  Opinions,  posturing,  proclamaIons   •  Liile  objecIve  facts   “...there  is  a  plethora  of  aienIon-­‐grabbing   pronouncements  in  cyberspace  that  have  not   been  evaluated  before  they  were  published,   oAen  reflecIng  the  authors’  guesses  and   experience  on  the  subject  of  Technical  Debt.”   Copyright  ©  2014    Philippe  Kruchten   20   Spinola  et  al.  2013   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   21  Copyright  ©  2014    Philippe  Kruchten  
  • 11. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   11   Visible   New  features   Technological  gap   Architectural  debt   Structural  debt   Code  smells   Defects  Low  internal  quality   AddiIonal  funcIonality   Low  external  quality   Mostly  invisible   Test  debt   DocumentaIon  debt   EvoluIon  issues:  evolvability   Quality  issues:  maintainability   Visible   architecture   code   Code  complexity   Coding  style  violaIons   Technical  debt  landscape   Copyright  ©  2014    Philippe  Kruchten   22   Kruchten  et  al  2012   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   23  Copyright  ©  2014    Philippe  Kruchten  
  • 12. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   12   Causes  of  Technical  Debt   TECHNOLOGY • Technology limitations • Legacy code • COTS • Changes in technology • Project maturity PROCESS • Little consideration of code maintenance • Unclear requirements • Cutting back on process (code reviews) • Little or no history of design decisions • Not knowing or adopting best practices PEOPLE • Postpone work until needed • Making bad assumptions • Inexperience • Poor leadership/team dynamics • No push-back against customers • “Superstars” – egos get in the way • Little knowledge transfer • Know-how to safely change code • Subcontractors PRODUCT • Schedule and budget constraints • Poor communication between developers and management • Changing priorities (market information) • Lack of vision, plan, strategy • Unclear goals, objectives and priorities • Trying to make every customer happy • Consequences of decisions not clear Lim  et  al.  2012   24  Copyright  ©  2014    Philippe  Kruchten   Israel  Gat,  2010   hip://theagileexecuIve.com/2010/09/20/how-­‐to-­‐break-­‐the-­‐vicious-­‐cycle-­‐of-­‐technical-­‐debt/   (more)   Relentless   Pressure   Take   Technical   Debt   Fail  to  Pay   back   Technical   debt   Technical   Debt  Accrues   Reduced   Development   Team   Velocity   25  Copyright  ©  2014    Philippe  Kruchten  
  • 13. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   13   Tensions  /  Factors  to  Consider   •  Engineers  don’t  like  technical  debt      they  want  to  be  technically  flawless     •  Project  managers  or  business  people  don’t  mind   technical  debt      they  want  to  capture  market  share   •  However,  tolerance  for  TD  changes  over  the   system  lifeIme  of  the  system   Lim  et  al.  2012   26  Copyright  ©  2014    Philippe  Kruchten   Copyright  ©  2014    Philippe  Kruchten   27 Frog:  “All  projects  are  the  same”   Time Quality Risk Intent Time Quality Risk Product Time Quality Risk Work Time Quality Risk People Value   Value   Cost   Cost  
  • 14. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   14   Octopus:  “All  projects  are  different!”   Copyright  ©  2014    Philippe  Kruchten   28   Context   Size   CriIcality   Business   model   Stable   architec ture  Team   distribu Ion   Gover nance   Rate  of   change   Age  of   the   system   Domain,   Industry   Corporate  &   Na@onal  Culture   Organiza@onal   Maturity   Degree  of     Innova@on   •  A  project  is  all  the  work  that  people  have  to   accomplish  over  @me  to  realize  in  a  product   some  specific  intent,  at  some  level  of  quality,   delivering  value  to  the  business  at  a  given  cost,   while  resolving  many  uncertain@es  and  risk.   •  All  aspects  of  soAware  projects  are  affected  by   context:  size,  criIcality,  team  distribuIon,  pre-­‐ existence  of  an  architecture,  governance,   business  model,  which  will  guide  with  pracIces   will  actually  perform  best,  within  a  certain   domain  and  culture.   29  Copyright  ©  2014    Philippe  Kruchten  
  • 15. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   15   Value  and  Cost   •  Value:  to  the  business  (the  users,  the  customers,   the  public,  etc.)   •  Cost:  to  design,  develop,  manufacture,  deploy,   maintain   •  Simple  system,  stable  architecture,  many  small   features:   –  Roughly,  value  aligns  to  cost   •  Large,  complex,  novel  systems  ?   –  Not  quite  so   30  Copyright  ©  2014    Philippe  Kruchten   Time Quality Risk Intent Time Quality Risk Product Time Quality Risk Work Time Quality Risk People Value   Cost   31  Copyright  ©  2014    Philippe  Kruchten  
  • 16. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   16   What’s  in  your  backlog?   New  features   Added   func@onality   Architectural,   Structural   features   Defects   Technical   Debt   Visible   Invisible   PosiIve   Value   NegaIve   Value   Copyright  ©  2014    Philippe  Kruchten   32   TD:  negaIve  value,  invisible   New  features   Added   func@onality   Architectural,   Structural   features   Defects   Technical   Debt   Visible   Invisible   PosiIve   Value   NegaIve   Value   Copyright  ©  2014    Philippe  Kruchten   33  
  • 17. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   17   Technical  Debt  (1)   12   12   a   $15   $5   12   b   $16   $3   12   $18   $20   $19   $18   34  Copyright  ©  2014    Philippe  Kruchten   Technical  Debt  (2)   12   12   a   $15   $5   12   b   $16   $3   12   $18   8   8   $5   8   $8   8   $10   $25   $27   $28   35  Copyright  ©  2014    Philippe  Kruchten  
  • 18. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   18   Technical  Debt  (3)   12   12   a   +$2   $5   12   $18   8   8   $5   $30   36  Copyright  ©  2014    Philippe  Kruchten   Israel  Gat,  2010   hip://theagileexecuIve.com/2010/09/20/how-­‐to-­‐break-­‐the-­‐vicious-­‐cycle-­‐of-­‐technical-­‐debt/   (more)   Relentless   Pressure   Take   Technical   Debt   Fail  to  Pay   back   Technical   debt   Technical   Debt  Accrues   Reduced   Development   Team   Velocity   37  Copyright  ©  2014    Philippe  Kruchten  
  • 19. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   19   Technical  Debt   •  Defect  =  Visible  feature  with  negaIve  value   •  Technical  debt  =  Invisible  feature  with   negaIve  value   – Cost  ….      of  fixing     – Value  ….  of  repaying  technical  debt,  interests  loss   of  producIvity,  etc.   38  Copyright  ©  2014    Philippe  Kruchten   Interests   •  In  presence  of  technical  debt,    cost  of  adding  new  features  is  higher;    velocity  is  lower.   •  When  repaying  (fixing),  addiIonal  cost  for   retrofixng  already  implemented  features   •  Technical  debt  not  repaid  =>  lead  to  increased   cost,  forever   •  Cost  of  fixing  (repaying)  increases  over  Ime   M.  Fowler,  2009   39  Copyright  ©  2014    Philippe  Kruchten  
  • 20. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   20   TD  litmus  test   •  If  you  are  not  incurring  any  interest,  then  it   probably  is  not  a  debt   Copyright  ©  2014    Philippe  Kruchten   40   McConnell  2013   Deferring  implementaIon:   Value  decreases   Time   R1   R2   R3   R4   8   8   7.5   7   6   41  Copyright  ©  2014    Philippe  Kruchten  
  • 21. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   21   But  technical  debt  increases  over   Ime   Time   R1   R2   R3   R4   -­‐8   -­‐8   -­‐8.5   -­‐9   -­‐10   42  Copyright  ©  2014    Philippe  Kruchten   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   43  Copyright  ©  2014    Philippe  Kruchten  
  • 22. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   22   Tech  Debt  (mis)-­‐concepIons   •  Technical  debt  reifies  an  abstract  concept   •  Technical  debt  does  not  equate  to  bad  quality   •  Technical  debt  can  be  induces  by  a  shiA  in   context   •  Defects  are  not  technical  debt   •  Lack  of  progress  is  not  technical  debt   •  New  features  yet  to  be  implemented  is  not   technical  debt   Copyright  ©  2014    Philippe  Kruchten   44   It’s  only  a  Metaphor!   •  Metaphors  give  meaning  to  form,  help  ground   our  conceptual  systems.   •  CogniIve  transfer:  source  domain  to  target   domain   –   the  <target>  is  the  <source>   •  Do  not  push  any  metaphor  too  far….   Lakoff  and  Johnson  (1980)  Metaphors  we  live  by     45  Copyright  ©  2014    Philippe  Kruchten  
  • 23. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   23   Where  the  metaphor  breaks   •  Technical  debt  does  not  always  have  to  be   repaid   •  What  does  it  mean  to  be  “debt  free”?   – TD  has  a  large  part  of  subjecIvity   •  NegaIve  connotaIon   •  May  increase  the  value  of  a  project  for  a  Ime   •  Tech  Debt  as  Investment?   46  Copyright  ©  2014    Philippe  Kruchten   Where  the  metaphor  breaks   •  IniIal  investment  at  T0  in  an  environment  E0.   Now  in  T2,  E  has  changed  to  E2,  a  mismatch   has  occurred,  which  creates  a  debt.     – The  debt  is  created  by  the  change  of  environment.   The  right  decision  in  the  right  environment  at   some  Ime  may  lead  to  technical  debt.   •  Prudent,  inadvertent   47  Copyright  ©  2014    Philippe  Kruchten  
  • 24. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   24   Where  the  metaphor  breaks…   •  Technical  debt  depends  on  the  future   •  Technical  debt  cannot  be  measured   •  You  can  walk  away  from  technical  debt   •  Technical  debt  should  not  be  completely   eliminated   •  Technical  debt  cannot  be  handled  in  isolaIon   •  Technical  debt  can  be  a  wise  investment   Copyright  ©  2014    Philippe  Kruchten   48   Real  OpIons  Theory   •  OAen  menIoned,  but  rarely  put  in  applicaIon   in  soAware   49  Copyright  ©  2014    Philippe  Kruchten  
  • 25. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   25   TD  and  Real  OpIons   P1:   S0   Market  loves  it   +  $4M   Market  hates  it   +  $1M   S1   NPV  (P1)  =  -­‐2M  +  0.5x4M  +  0.5x1M  =  0.5M   -­‐2M   p=0.5   p=0.5   Source:  K.  Sullivan,  2010   at    TD  Workshop  SEI  6/2-­‐3   50  Copyright  ©  2014    Philippe  Kruchten   TD  and  Real  OpIons  (2)   P2:   S0   Market  loves  it   Market  hates  it   +  $1M   Sd   NPV  (P2)  =  -­‐1M  +  0.5x3M  +  0.5x1M  =  1M   -­‐1M   Source:  K.  Sullivan,  2010   p=0.5   p=0.5   -­‐1M   S1   +4M   Taking  Technical  Debt  has  increased  system  value.   51  Copyright  ©  2014    Philippe  Kruchten  
  • 26. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   26   TD  and  Real  OpIons  (3)   P2:   S0   Market  loves  it   Market  hates  it   +  $1M   Sd   NPV  (P3)  =  -­‐1M  +  0.67  x  2.5M  +  0.33  x  1M  =  1M   -­‐1M   p=0.33   p=0.67   -­‐1.5M   S1   +4M   More  realisIcally:   Debt  +  interest   High  chances  of  success   Take  Debt   Repay  debt   52  Copyright  ©  2014    Philippe  Kruchten   TD  and  Real  OpIons  (3)   P2:   S0   Market  loves  it   Market  hates  it   +  $1M   Sd   NPV  (P3)  =  -­‐1M  +  0.67  x  2.5M  +  0.33  x  1M  =  1M   -­‐1M   p=0.33   p=0.67   -­‐1.5M   S1   +4M   More  realisIcally:   Debt  +  interest   High  chances  of  success   Higher  chance   of  success   Repay  debt  +   50%  interest   53  Copyright  ©  2014    Philippe  Kruchten  
  • 27. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   27   TD  and  Real  OpIons  (4)   S0   Favourable   Unfavourable   Sd   p=?   p=?   S1   S2   S2d   …..   …..   Not  debt  really,  but  op@ons  with  different  values…     Do  we  want  to  invest  in  architecture,  in  test,  etc…   Refactor   Add  feature   Add  feature   ?   Source:  K.  Sullivan,  2010   54  Copyright  ©  2014    Philippe  Kruchten   OpIons  Theory   •  OAen  menIoned,  but  rarely  put  in  applicaIon   in  soAware   •  Not  even  scratched  the  surface   •  Pay-­‐off  not  obvious,  though…   – Too  much  guesswork  involved  to  trust  results,     – Lot  of  work  involved   55  Copyright  ©  2014    Philippe  Kruchten  
  • 28. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   28   PotenIal  vs.  actual  debt   •  PotenIal  debt   – Type  1:OK  to  do  with  tools  (see  Gat  &  co.   approach)   – Type  2:  structural,  architectural,  or  technological   gap:  Much  harder   •  Actual  debt   – When  you  know  the  way  forward   Copyright  ©  2014    Philippe  Kruchten   56   K.Schmid  2013   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   57  Copyright  ©  2014    Philippe  Kruchten  
  • 29. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   29   How  do  people  “tackle”   technical  debt   Tackling  Technical  Debt   Axtudes  and  approaches  found:   1.  Ignorance  is  bliss   2.  The  elephant  in  the  room   3.  Big  scary  $$$$  numbers   4.  Five  star  ranking   5.  Constant  reducIon   6.  We’re  agile,  so  we  are  immune!   59  Copyright  ©  2014    Philippe  Kruchten  
  • 30. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   30   Ignorance  is  bliss   You’re  just  slower,  and  slower,  but  you  do  not   know  it,  or  do  not  know  why   0   2   4   6   8   10   12   1   2   3   4   5   6   7   Func@onal  requirement  delivered   Itera@ons   Velocity   accumulated  technical  debt   impacts  ability  to  deliver   60  Copyright  ©  2014    Philippe  Kruchten   The  elephant  in  the  room   •  Many  in  the  org.  know   about  technical  tech.   •  Indifference:  it’s   someone  else’s  problem   •  OrganizaIon  broken   down  in  small  silos   •  No  real  whole  product   mentality   •  Short-­‐term  focus   61  Copyright  ©  2014    Philippe  Kruchten  
  • 31. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   31   Big  scary  $$$$  numbers   •  Code  smells    167  person  days   •  Missing  test    298  person  days   •  Design        670    person  days   •  DocumentaIon      67  person  days       Totals    Work          1,202  person  x  days    Cost          $577,000   62  Copyright  ©  2014    Philippe  Kruchten   StaIc  analysis  +  ConsulIng   •  Cuier  ConsorIum:  Gat,  et  al.   – Use  of  Sonar,  etc.   – Focused  on  code  analysis   – TD  =  total  value  of  fixing  the  code  base   •  CAST  soAware   •  ThoughtWorks     Debt  analysis  engagements   Debt  reducIon  engagements   63  Copyright  ©  2014    Philippe  Kruchten  
  • 32. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   32   Issues   •  Fits  the  metaphor,  indeed.     •  Looks  very  objecIve…  but…   •  SubjecIve  in:   –  What  is  counted   –  What  tool  to  use   –  Cost  to  fix       Not  all  fixes  have  the  same  resulIng  value.   Sunk  cost  are  irrelevant,  look  into  the  future  only.   What  does  it  mean  to  be  “Debt  free”??   64  Copyright  ©  2014    Philippe  Kruchten   Five  star  ranking   •  Define  some  maintainability  index   •  Benchmark  relaIve  to  other  soAware  in  the  same   category   •  Re-­‐assess  regularly  (e.g.,  weekly)   •  Look  at  trends,  correlate  changes  with  recent   changes  in  code  base   •  SIG  (SoAware  Improvement  Group),  Amsterdam   •  Powerful  tool  behind   65  Copyright  ©  2014    Philippe  Kruchten  
  • 33. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   33   Constant  debt  reducIon   •  Make  technical  debt  a  visible  item  on  the   backlog   •  Make  it  visible  outside  of  the  soAware  dev.   organizaIon   •  Incorporate  debt  reducIon  as  a  regular   acIvity   •  Use  buffer  in  longer  term  planning  for  yet   unidenIfied  technical  debt   •  Lie  (?)   66  Copyright  ©  2014    Philippe  Kruchten   Buffer  for  debt  repayment   Simple  work   EsImate     uncertainIes   Defect     correcIon   Debt   Repayment   67  Copyright  ©  2014    Philippe  Kruchten  
  • 34. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   34   A  later  release   68  Copyright  ©  2014    Philippe  Kruchten   We  are  agile,  so  we’re  immune!   In  some  cases  we  are  agile  and  therefore  we  run  faster  into  technical  debt   69  Copyright  ©  2014    Philippe  Kruchten  
  • 35. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   35   Agile  moios   •  “Defer  decision  to  the  last  responsible  moment”   •  “YAGNI”  =  You  Ain’t  Gonna  Need  It   –  But  when  you  do,  it  is  technical  debt   –  Technical  debt  oAen  is  the  accumulaIon  of  too  many   YAGNI  decisions   •  “We’ll  refactor  this  later”   •  “Deliver  value,  early”   •  Again  the  tension  between  the  yellow  stuff  and   the  green  stuff   •  You’re  sIll  agile  because  you  aren’t  slowed  down   by  TD  yet.   70  Copyright  ©  2014    Philippe  Kruchten   Story  of  a  failure   •  Large  re-­‐engineering  of    a  complex  distributed     world-­‐wide  system;     2  millions  LOC  in  C,     C++,  Cobol  and  VB   •  MulIple  sites,  dozens  of  data  repositories,  hundreds   of  users,  24  hours  operaIon,  mission-­‐criIcal   ($billions)   •  xP+Scrum,  1-­‐week  iteraIons,  30  then  up  to  50   developers   •  Rapid  progress,  early  success,  features  are  demo-­‐able   •  Direct  access  to  “customer”,  etc.   •  A  poster  project  for  scalable  agile  development   71  Copyright  ©  2014    Philippe  Kruchten  
  • 36. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   36   Hixng  the  wall   •  AAer  4  ½    months,  difficulIes     to  keep  with  the  1-­‐week     iteraIons   •  Refactoring  takes  longer     than  one  iteraIon   •  Scrap  and  rework  raIo     increases  dramaIcally   •  No  externally  visible  progress  anymore   •  IteraIons  stretched  to  3  weeks   •  Staff  turn-­‐over  increases     •  Project  comes  to  a  halt   •  Lots  of  code,  no  clear  architecture,  no  obvious  way  forward   72  Copyright  ©  2014    Philippe  Kruchten   WTF/min  
  • 37. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   37   Managing  TD…   •  IdenIfy  sources  of  TD   •  Locate  TD   –  Not  easy  for  McConnell  type  2   •  QuanIfy  TD   –  Principal,  Interest   •  Define  acIons   –  PrioriIes   –  Tooling   •  Assessment   Copyright  ©  2014    Philippe  Kruchten   74   Octopus:  “All  projects  are  different!”   Copyright  ©  2014    Philippe  Kruchten   75   Context   Size   CriIcality   Business   model   Stable   architec ture  Team   distribu Ion   Gover nance   Rate  of   change   Age  of   the   system   Domain,   Industry   Corporate  &   Na@onal  Culture   Organiza@onal   Maturity   Degree  of     Innova@on  
  • 38. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   38   Debt  at  the  Architectural  level   •  Design  Structure  Matrix  (DSM)   – a.k.a,  Dependency  Structure  Matrix   •  Domain  Mapping  Matrix  (DMM)   •  Tools  to  create  and  manipulate  DSMs  and   DMMs   76  Copyright  ©  2014    Philippe  Kruchten   Outline   •  What  is  technical  debt?     •  The  technical  debt  landscape   •  Causes  of  technical  debt   – Cost  vs.  value   •  Limits  of  the  metaphor   •  Tackling  Technical  debt   •  FricIon  in  soAware  development   77  Copyright  ©  2014    Philippe  Kruchten  
  • 39. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   39   FricIon   “FricIon:  the  resistance  that     one  surface  or  object  encounters    when  moving  over  another.”     In  soAware  development,  fricIon  is  the  set  of   phenomena  that  limits  or  constraints  our  progress,   therefore  reduces  our  velocity  (or  producIvity).     Technical  debt  causes  fricIon.   Copyright  ©  2014    Philippe  Kruchten   78   FricIon  and  Debt   Copyright  ©  2014    Philippe  Kruchten   79   Technical  Debt   Social  Debt   Fric@on   Reduced  velocity   Defects   Delays   …  
  • 40. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   40   Social  debt   •  Social  debt  is  a  state  of  a  development  project   which  is  the  result  of  the  accumulaIon  over   Ime  of  decisions  about  the  way  the   development  team  (or  community)   communicates,  collaborates  and  coordinates.   Copyright  ©  2014    Philippe  Kruchten   80   Tamburri  et  al.  2013   Social  debt   •  In  other  words,  decisions  about  :   – the  organizaIonal  structure,     – the  process,     – the  governance,     – the  social  interacIons,     •  or  some  elements  inherited  through  the   people:     – their  knowledge,  personality,  working  style,  etc.   Copyright  ©  2014    Philippe  Kruchten   81   Tamburri  et  al.  2013  
  • 41. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   41   Parallel  Technical    &  Social  Debt   New  features   Added   func@onality   Architectural,   Structural   features   Defects   Technical   Debt   Visible   Invisible   PosiIve   Value   NegaIve   Value   Copyright  ©  2014    Philippe  Kruchten   82   Social  debt   Community   Features   Community   Structure   Community   Defects     Social   Debt   Visible   Invisible   PosiIve   Value   NegaIve   Value   Copyright  ©  2014    Philippe  Kruchten   83   Tamburri  et  al.  2013  
  • 42. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   42   Architecture  of   the  System   Structure  of  the   Development  Organiza@on   Produc@on   Infrastructure   Architecture  of   the  System   Structure  of  the   Development  Organiza@on   Produc@on   Infrastructure   Socio-­‐technical  congruence   Socio-­‐technical   congruence  
  • 43. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   43   Architecture  of   the  System   Structure  of  the   Development  Organiza@on   Produc@on   Infrastructure   DevOps:  Development+OperaIons   DevOps   Conclusion   •  Technical  debt  is  sIll  more  a  rhetorical   category  than  a  technical  or  ontological   category.     •  The  concept    resonates  well  with  the   development  community,  and  someImes  also   with  management.   •  It  bridges  the  gap  between  business  decision   makers  and  technical  implementers.   •  It’s  only  a  metaphor;  do  not  push  it  too  far.   •  It’s  not  all  bad.   87  Copyright  ©  2014    Philippe  Kruchten  
  • 44. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   44   Visible   New  features   Technological  gap   Architectural  debt   Structural  debt   Code  smells   Defects  Low  internal  quality   AddiIonal  funcIonality   Low  external  quality   Mostly  invisible   Test  debt   DocumentaIon  debt   EvoluIon  issues:  evolvability   Quality  issues:  maintainability   Visible   architecture   code   Code  complexity   Coding  style  violaIons   Technical  debt  landscape   Copyright  ©  2014    Philippe  Kruchten   88   Kruchten  et  al  2012   References   §  Brown,  N.,  Cai,  Y.,  Guo,  Y.,  Kazman,  R.,  Kim,  M.,  Kruchten,  P.,  et  al.  (2010).  Managing   Technical  Debt  in  So)ware-­‐Intensive  Systems.  Paper  presented  at  the  Future  of  soAware   engineering  research  (FoSER)  workshop,  part  of  FoundaIons  of  SoAware  Engineering  (FSE   2010)  conference.     §  Brown,  N.,  Nord,  R.,  Ozkaya,  I.,  Kruchten,  P.,  &  Lim,  E.  (2011).  Hard  Choice:  A  game  for   balancing  strategy  for  agility.  Paper  presented  at  the  24th  IEEE  CS  Conference  on  SoAware   Engineering  EducaIon  and  Training  (CSEE&T  2011),  Honolulu,  HI,  USA.   §  Cunningham,  W.  (1992).  The  WyCash  PorPolio  Management  System.  Paper  presented  at  the   OOPSLA'92  conference,  ACM.  Retrieved  from  hip://c2.com/doc/oopsla92.html   §  CurIs,  B.,  Sappidi,  J.,  &  Szynkarski,  A.  (2012).  EsImaIng  the  Principal  of  an  ApplicaIon’s   Technical  Debt.  IEEE    SoAware,  29(6).   §  Denne,  M.,  &  Cleland-­‐Huang,  J.  (2004).  So)ware  by  Numbers:  Low-­‐Risk,  High-­‐Return   Development,  PrenIce  Hall.   §  Denne,  M.,  &  Cleland-­‐Huang,  J.  (2004).  The  Incremental  Funding  Method:  Data-­‐Driven   SoAware  Development,  IEEE  So)ware,  21(3),  39-­‐47.   §  Fowler,  M.  (2009),  Technical  debt  quadrant,  Blog  post  at:   hip://www.marInfowler.com/bliki/TechnicalDebtQuadrant.html     §  Gat,  I.  (ed.).  (2010).  How  to  seVle  your  technical  debt-­‐-­‐a  manager's  guide.  Arlington  Mass:   Cuier  ConsorIum.   §  Kruchten,  Ph.  (2010)  Contextualizing  Agile  SoAware  Development,”  Paper  presented  at  the   EuroSPI  2010  conference  in  Grenoble,  Sept.1-­‐3,  2010       89  Copyright  ©  2014    Philippe  Kruchten  
  • 45. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   45   References   §  Kruchten,  P.,  Nord,  R.,  &  Ozkaya,  I.  (2012).  Technical  debt:  from  metaphor  to  theory  and  pracIce.   IEEE    So)ware,  29(6).     §  Kruchten,  P.,  Nord,  R.,  Ozkaya,  I.,  &  Visser,  J.  (2012).  Technical  Debt  in  SoAware  Development:  from   Metaphor  to  Theory-­‐-­‐Report  on  the  Third  InternaIonal  Workshop  on  Managing  Technical  Debt,   held  at  ICSE  2012  ACM  SIGSOFT  So)ware  Engineering  Notes,  37(5).     §  Li,  Z.,  Madhavji,  N.,  Murtaza,  S.,  Giiens,  M.,  Miranskyy,  A.,  Godwin,  D.,  &  Cialini,  E.  (2011).   CharacterisIcs  of  mulIple-­‐component  defects  and  architectural  hotspots:  a  large  system  case   study.  Empirical  So)ware  Engineering,  16(5),  667-­‐702.  doi:  10.1007/s10664-­‐011-­‐9155-­‐y   §  Lim,  E.  (2012).  Technical  Debt:  What  So)ware  PracIIoners  Have  to  Say.  (Master's  thesis),   University  of  BriIsh  Columbia,  Vancouver,  Canada.         §  Lim,  E.,  Taksande,  N.,  &  Seaman,  C.  B.  (2012).  A  Balancing  Act:  What  SoAware  PracIIoners  Have  to   Say  about  Technical  Debt.  IEEE    So)ware,  29(6).   §  MacCormack,  A.,  Rusnak,  J.,  &  Baldwin,  C.  Y.  (2006).  Exploring  the  structure  of  complex  soAware   designs:  An  empirical  study  of  open  source  and  proprietary  code.  Management  Science,  52(7),   1015-­‐1030.     §  Nord,  R.,  Ozkaya,  I.,  Kruchten,  P.,  &  Gonzalez,  M.  (2012).  In  search  of  a  metric  for  managing   architectural  technical  debt.  Paper  presented  at  the  Working  IEEE/IFIP  Conference  on  So)ware   Architecture  (WICSA  2012),  Helsinki,  Finland.   §  McConnell,  S.  (2007)  Notes  on  Technical  Debt,  Blog  post  at:  hip://blogs.construx.com/blogs/ stevemcc/archive/2007/11/01/technical-­‐debt-­‐2.aspx   §  Special  issue  of  CuVer  IT  Journal  on  Technical  Debt,  edited  by  I.  Gat  (October  2010)  Cuier  IT   Journal,  23  (10).   §  Sterling,  C.  (2010)  Managing  So)ware  Debt,  Addison-­‐Wesley.   90  Copyright  ©  2014    Philippe  Kruchten   References  (cont.)   §  R.  O.  Spinola,  N.  Zazworka,  A.  Vetrò,  C.  B.  Seaman,  and  F.  Shull,  "InvesIgaIng  Technical  Debt   Folklore:  Shedding  Some  Light  on  Technical  Debt  Opinion,"  in  Proceedings  of  the  4th   Workshop  on  Managing  Technical  Debt,  at  ICSE  2013,  P.  Kruchten,  I.  Ozkaya,  and  R.  Nord,   Eds.,  IEEE,  2013.   §  K.  Schmid,  "On  the  Limits  of  the  Technical  Debt  Metaphor,"  in    Proceedings  of  the  4th   Workshop  on  Managing  Technical  Debt,  at  ICSE  2013,  P.  Kruchten,  I.  Ozkaya,  and  R.  Nord,   Eds.,  IEEE,  2013,  pp.  63-­‐66.   §  K.  Schmid,  "A  Formal  Approach  to  Technical  Debt  Decision  Making,"  in  Proceedings  of  the   Conference  on  Quality  of  SoAware  Architecture  QoSA'2013,  Vancouver,  2013,  ACM.   91  Copyright  ©  2014    Philippe  Kruchten  
  • 46. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   46   Other  sources  (Talks/slides)   •  Gat,  I.,  Heintz,  J.  (Aug.  19,  2010)  Webinar:  Reining  in  Technical  Debt,   Cuier  ConsorIum.   •  McConnell,  S.  (October  2011)  Managing  technical  debt.  (Webinar)     •  Kniberg,  H.  (2008)  Technical  debt-­‐How  not  to  ignore  it,  at  Agile  2008   conference.   •  Kruchten,  P.  (2009)  What  colour  is  your  backlog?  Agile  Vancouver   Conference.  hip://philippe.kruchten.com/talks   •  Sterling,  C.  (2009)  hip://www.slideshare.net/csterwa/managing-­‐ soAware-­‐debt-­‐pnsqc-­‐2009   •  Short,  G.  (2009)  hip://www.slideshare.net/garyshort/technical-­‐ debt-­‐2985889   •  West,  D.  (January  2011),  Balancing  agility  and  technical  debt,  Forrester  &   Cast  SoAware   92  Copyright  ©  2014    Philippe  Kruchten   Other  pointers   hip://techdebt.org       hip://www.ontechnicaldebt.com/     @OnTechnicalDebt   Copyright  ©  2014    Philippe  Kruchten   93  
  • 47. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   47   Acknowledgements   •  My  research  partly  funded  by  the       – Ipek  Ozkaya,  Rod  Nord   – They  have  also  contributed  to  building  this  tutorial   over  the  last  2  years.   •  UBC  master  student  Erin  Lim  Kam-­‐Yan…   – And  some  industry  partners  in  Canada   94   Slides?   hip://philippe.kruchten.com/talks/   Copyright  ©  2014    Philippe  Kruchten   95  
  • 48. Technical  Debt   January  2014   Copyright  ©  2014  by  Philippe  Kruchten   48   96  Copyright  ©  2014    Philippe  Kruchten   Copyright  ©  2014    Philippe  Kruchten   97