Managing Software Debt in Practice“What he needs is some way to pay back. Not some way to borrow more.”   - Will Rogers   ...
Chris Sterling – Sterling Barton, LLC               Partner, Sterling Barton, LLC               Author of Book “Managing S...
Types of Software Debt          Technical Debt: These are the activities that a team or team members          choose not t...
Technical Debt“Lowering quality lengthens development time.” - From wiki page on “First Lawof Programming” (c2.com)       ...
Patterns of Technical Debt                                                Duplication   Schedule Pressure                 ...
Aspects of the software’s design that teams agree to   should be automated, if possible, and break the build   when they a...
Keep DRY (Don’t Repeat Yourself)© 2009-2010,                          7                                          7
No matter what, the cost of addressing   technical debt increases with time.© 2009-2010,                                8 ...
Principles of Executable Design          The way we design can always be improved.          We’ll get it “right” the third...
Merciless Refactoring          Refactoring: a disciplined technique for restructuring          an existing body of code, a...
Where to Start Refactoring?           Does this change directly affect feature I am working           on?           Would ...
When to Stop Refactoring?          Am I refactoring code not directly affected by feature?          Is other code directly...
Automate Testing to Support Refactoring          Refactoring cannot be done effectively without          automated tests s...
TDD - Basic “Flow”© 2009-2010,            14                             14
TDD - Basic “Flow”                           Write	                          Failing	  Test© 2009-2010,                   ...
TDD - Basic “Flow”                           Write	                          Failing	  Test                               ...
TDD - Basic “Flow”                                       Write	                                      Failing	  Test       ...
TDD - Basic “Flow”                                       Write	                                      Failing	  Test       ...
Ji:er	  –	  Example	  TDD	  Session• Fake	  micro-­‐blogging	  tool	  named	  “Ji4er”	  is	  made	  by	    Sea4le-­‐based	...
Expand	  LOL	  to	  “laughing	  out	  loud”public class WhenMotherWantsToExpandMessagesThatContainShorthandTest {    @Test...
But	  wait…what	  if…?• What	  if	  LOL	  is	  wri:en	  in	  lower	  case?• What	  if	  it	  is	  wri:en	  as	  “Lol”?	  S...
Expand	  LOL	  If	  Lower	  Case@Testpublic void shouldExpandLOLIfLowerCase() {     when(session.getNextMessage()).thenRet...
Don’t	  Expand	  “Lol”	  –	  Mixed-­‐Case@Testpublic void shouldNotExpandLOLIfMixedCase() {     String msg = "Do not expan...
Don’t	  Expand	  “LOL”	  If	  Inside	  Word@Testpublic void shouldNotExpandLOLIfInsideWord() {     String msg = "Do not ex...
Expand	  “LOL”	  If	  Not	  Inside	  Word@Testpublic void shouldExpandIfSurroundingCharactersAreNotLetters() {    when(ses...
Quality Debt“Promises make debt, and debt makes promises.” - Dutch Proverb                                                ...
Effect of Project Constraints on Quality© 2009-2010,                                  23                                  ...
Effect of Project Constraints on Quality© 2009-2010,                                  23                                  ...
“For every [dollar] of competitive advantage gained by   cutting quality, it costs $4 to restore it; and software is   an ...
Acceptance Test-Driven Development© 2009-2010,                            25                                             25
Configuration Management Debt“If releases are like giving birth, then you must be doing something wrong.”   - Robert Benefie...
The Power of 2 Scripts: Deploy and Rollback© 2009-2010,                                     27                            ...
Design DebtDesign decays when not attended to so design software continually                                              ...
The value of technical aspects in an application or its   surrounding infrastructure is the cost of not   addressing them....
* Abuse User Stories       Implement Security      for User Information               * From “User Stories Applied” presen...
* Abuse User Stories                                                         As a Malicious Hacker I       Implement Secur...
Abuse Story Writing Workshop          Identify a user role who will try to abuse the application.          Set a time box ...
Some Potential Abusers          Malicious Hacker          Mass of users          SQL injector          Disgruntled employe...
Lack of emphasis on software quality attributes   contributes to decay© 2009-2010,                                        ...
Software Quality Attributes Defined© 2009-2010,                            34                                             34
Software Quality Attributes Rating Tool© 2009-2010,                                 35                                    ...
Platform Experience Debt“As in Nature, if an organization is too inflexible or stands still too long it will geteaten.” - J...
Rather than creating teams to work on projects, let’s   find ways to give projects to cross-functional teams.© 2009-2010,  ...
Component Team Configuration                         “Component Team” structure                         Separate Product Ba...
Feature Team Configuration                          “Feature Team” structure                          Uses common Product  ...
Principles for Managing Software Debt          Maintain one list of work          Emphasize quality          Evolve tools ...
Thank youQuestions and Answers                        41                             41
Chris Sterling – Sterling Barton, LLC               Partner, Sterling Barton, LLC               Author of Book “Managing S...
Upcoming SlideShare
Loading in...5
×

Managing Software Debt in Practice 2011

2,765

Published on

This presentation is from Scrum Gathering 2011 in Seattle, WA, USA. Much of the presentation involved showing tools and techniques outside the slide deck along with exercises that the participants would perform for learning purposes.

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

No Downloads
Views
Total Views
2,765
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
60
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Managing Software Debt in Practice 2011

  1. 1. Managing Software Debt in Practice“What he needs is some way to pay back. Not some way to borrow more.” - Will Rogers Chris Sterling VP of Engineering AgileEVM Inc. Web: www.AgileEVM.com Email: chris@agileevm.com Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt 1
  2. 2. Chris Sterling – Sterling Barton, LLC Partner, Sterling Barton, LLC Author of Book “Managing Software Debt: Building for Inevitable Change” Consults on software technology, Agile technical practices, Scrum, and effective management techniques Email: chris@sterlingbarton.com Web: http://www.agileevm.com Certified Scrum Trainer Blog: http://www.gettingagile.com Follow me on Twitter: @csterwa Innovation Games® Trained Facilitator Open Source Developer© 2009-2011, 2 2
  3. 3. Types of Software Debt Technical Debt: These are the activities that a team or team members choose not to do well now and will impede future development if left undone. Quality Debt: There is a diminishing ability to verify the functional and technical quality of software. Configuration Management Debt: Integration and release management become more risky, complex, and error-prone. Design Debt: The cost of adding features is increasing toward the point where it is more than the cost of writing from scratch. Platform Experience Debt: The availability of people to work on software changes is becoming limited or cost-prohibitive.© 2009-2010, 3 3
  4. 4. Technical Debt“Lowering quality lengthens development time.” - From wiki page on “First Lawof Programming” (c2.com) 4 4
  5. 5. Patterns of Technical Debt Duplication Schedule Pressure Get it “right” the first time mentality© 2009-2010, 5 5
  6. 6. Aspects of the software’s design that teams agree to should be automated, if possible, and break the build when they are not adhered to.© 2009-2010, 6 6
  7. 7. Keep DRY (Don’t Repeat Yourself)© 2009-2010, 7 7
  8. 8. No matter what, the cost of addressing technical debt increases with time.© 2009-2010, 8 8
  9. 9. Principles of Executable Design The way we design can always be improved. We’ll get it “right” the third time. We will not get it “right” the first time. Design and construct for change rather than longevity. Lower the threshold of pain. If we are not enhancing the design then we are just writing a bunch of tests.© 2009-2010, 9 9
  10. 10. Merciless Refactoring Refactoring: a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.* Merciless: having or showing no [mercy - showing great kindness toward the distressed] Relieve your distressed code through kindness and disciplined restructuring * From http://www.refactoring.com/© 2009-2010, 10 10
  11. 11. Where to Start Refactoring? Does this change directly affect feature I am working on? Would change add clarity for feature implementation? Will change add automated tests where there are none? If “yes” to any question above, ask following question to decide if you should work on it now: At first glance, does refactoring look like a large endeavor involving significant portions of the software’s components?© 2009-2010, 11 11
  12. 12. When to Stop Refactoring? Am I refactoring code not directly affected by feature? Is other code directly affected by feature I am working on that has not been refactoring sufficiently? If refactoring is exploding feature estimate given to Customer then I should bring it up to Team to decide how we should progress If Team decides that refactoring can be absorbed into current iteration without affecting delivery on our commitments then continue refactor If refactoring affects commitments then bring it to Customer for discussion how to proceed© 2009-2010, 12 12
  13. 13. Automate Testing to Support Refactoring Refactoring cannot be done effectively without automated tests surrounding code Start by creating automated test which fails If difficult to create at unit level look at automated acceptance tests from functional perspective Over time look for ways to create automated unit tests© 2009-2010, 13 13
  14. 14. TDD - Basic “Flow”© 2009-2010, 14 14
  15. 15. TDD - Basic “Flow” Write   Failing  Test© 2009-2010, 14 14
  16. 16. TDD - Basic “Flow” Write   Failing  Test Make  Test   Pass© 2009-2010, 14 14
  17. 17. TDD - Basic “Flow” Write   Failing  Test Refactor  to   Make  Test   Acceptable   Design Pass© 2009-2010, 14 14
  18. 18. TDD - Basic “Flow” Write   Failing  Test Refactor  to   Make  Test   Acceptable   Design Pass© 2009-2010, 14 14
  19. 19. Ji:er  –  Example  TDD  Session• Fake  micro-­‐blogging  tool  named  “Ji4er”  is  made  by   Sea4le-­‐based  fic::ous  company  that  focuses  on  enabling   coffee  injected  folks  to  write  short  messages  and  have   common  online  messaging  shorthand  expanded  for  easy   reading.  The  user  story  we  are  working  on  is: So  it  is  easier  to  read  their  kid’s  messages,  Mothers  want   to  automaFcally  expand  common  shorthand  notaFon• The  acceptance  criteria  for  this  user  story  are: – LOL,  AFAIK,  and  TTYL  are  expandable – Expand  lower  and  upper  case  versions  of  shorthand 15 Copyright © 2010 Sterling Barton. All rights reserved. 15
  20. 20. Expand  LOL  to  “laughing  out  loud”public class WhenMotherWantsToExpandMessagesThatContainShorthandTest { @Test public void shouldExpandLOLToLaughingOutLoud() { JitterSession session = mock(JitterSession.class); when(session.getNextMessage()).thenReturn("Expand LOL please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please")); }}public class MessageExpander { public String getNextMessage() { String msg = session.getNextMessage(); return msg.replaceAll("LOL", "laughing out loud"); } 16 Copyright © 2010 Sterling Barton. All rights reserved. 16
  21. 21. But  wait…what  if…?• What  if  LOL  is  wri:en  in  lower  case?• What  if  it  is  wri:en  as  “Lol”?  Should  it  be  expanded?  • What  if  some  variaFon  of  LOL  is  inside  a  word?• What  if  characters  surrounding  LOL  are  symbols,  not  le:ers?  Write  these  down  as  upcoming  programmer  tests  as  comments  so  I   don’t  forget  them.  // shouldExpandLOLIfLowerCase// shouldNotExpandLOLIfMixedCase// shouldNotExpandLOLIfInsideWord// shouldExpandIfSurroundingCharactersAreNotLetters 17 Copyright © 2010 Sterling Barton. All rights reserved. 17
  22. 22. Expand  LOL  If  Lower  Case@Testpublic void shouldExpandLOLIfLowerCase() { when(session.getNextMessage()).thenReturn("Expand lol please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please"));}This  forced  use  of  java.u1l.regex.Pa6ern  to  handle  case  insensi1vity.public String getNextMessage() { String msg = session.getNextMessage(); return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE) .matcher(msg).replaceAll("laughing out loud");} 18 Copyright © 2010 Sterling Barton. All rights reserved. 18
  23. 23. Don’t  Expand  “Lol”  –  Mixed-­‐Case@Testpublic void shouldNotExpandLOLIfMixedCase() { String msg = "Do not expand Lol please"; when(session.getNextMessage()).thenReturn(msg); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg));}This  forced  me  to  stop  using  Pa6ern.CASE_INSENSITIVE  flag  in  pa6ern   compila1on.  Only  use  “LOL”  or  “lol”  for  replacement  criteria.public String getNextMessage() { String msg = session.getNextMessage(); return Pattern.compile("LOL|lol").matcher(msg) .replaceAll("laughing out loud");} 19 Copyright © 2010 Sterling Barton. All rights reserved. 19
  24. 24. Don’t  Expand  “LOL”  If  Inside  Word@Testpublic void shouldNotExpandLOLIfInsideWord() { String msg = "Do not expand PLOL or LOLP or PLOLP please"; when(session.getNextMessage()).thenReturn(msg); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg));}The  pa6ern  matching  is  now  modified  to  use  spaces  around  each   varia1on  of  valid  LOL  shorthand.return Pattern.compile("sLOLs|slols").matcher(msg) .replaceAll("laughing out loud"); 20 Copyright © 2010 Sterling Barton. All rights reserved. 20
  25. 25. Expand  “LOL”  If  Not  Inside  Word@Testpublic void shouldExpandIfSurroundingCharactersAreNotLetters() { when(session.getNextMessage()).thenReturn("Expand .lol! please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand .laughing out loud! please"));}The  final  implementa1on  of  pa6ern  matching  code  looks  as  follows.return Pattern.compile("bLOLb|blolb").matcher(msg) .replaceAll("laughing out loud"); 21 Copyright © 2010 Sterling Barton. All rights reserved. 21
  26. 26. Quality Debt“Promises make debt, and debt makes promises.” - Dutch Proverb 22 22
  27. 27. Effect of Project Constraints on Quality© 2009-2010, 23 23
  28. 28. Effect of Project Constraints on Quality© 2009-2010, 23 23
  29. 29. “For every [dollar] of competitive advantage gained by cutting quality, it costs $4 to restore it; and software is an organizational asset and decisions to cut quality must be made by executive management and reflected in the financial statements.” - Ken Schwaber© 2009-2010, 24 24
  30. 30. Acceptance Test-Driven Development© 2009-2010, 25 25
  31. 31. Configuration Management Debt“If releases are like giving birth, then you must be doing something wrong.” - Robert Benefield 26 26
  32. 32. The Power of 2 Scripts: Deploy and Rollback© 2009-2010, 27 27
  33. 33. Design DebtDesign decays when not attended to so design software continually 28 28
  34. 34. The value of technical aspects in an application or its surrounding infrastructure is the cost of not addressing them.© 2009-2010, 29 29
  35. 35. * Abuse User Stories Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006© 2009-2010, 30 30
  36. 36. * Abuse User Stories As a Malicious Hacker I Implement Security want to steal credit card for User Information information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006© 2009-2010, 30 30
  37. 37. Abuse Story Writing Workshop Identify a user role who will try to abuse the application. Set a time box of 30 minutes to 1 hour for generating abuse stories. As pairs or individually, assume persona of the abuser role and brainstorm as many abuse stories as possible. This should take 5 to 15 minutes. As a team, identify abuse stories that are not valid or are duplicates and remove them. This should take 10 to 20 minutes. Prioritize abuse stories in terms of impact or value. Do this fast as possible. Give all abuse stories in priority order to the Product Owner to be prioritized in the Product Backlog. Provide clarification on abuse stories that the Product Owner does not understand well.© 2009-2010, 31 31
  38. 38. Some Potential Abusers Malicious Hacker Mass of users SQL injector Disgruntled employee Naïve API user Impatient clicker Denial-of-service (DoS) attacker Sleazy user© 2009-2010, 32 32
  39. 39. Lack of emphasis on software quality attributes contributes to decay© 2009-2010, 33 33
  40. 40. Software Quality Attributes Defined© 2009-2010, 34 34
  41. 41. Software Quality Attributes Rating Tool© 2009-2010, 35 35
  42. 42. Platform Experience Debt“As in Nature, if an organization is too inflexible or stands still too long it will geteaten.” - James Burke (author and historian) 36 36
  43. 43. Rather than creating teams to work on projects, let’s find ways to give projects to cross-functional teams.© 2009-2010, 37 37
  44. 44. Component Team Configuration “Component Team” structure Separate Product Backlog Managing dependencies is often serialized Problematic integration issues are typically faced if multiple components are required to release Use an “Integration Team” to pull components together Causes more rework than “Feature Team” structure© 2009-2010, 38 38
  45. 45. Feature Team Configuration “Feature Team” structure Uses common Product Backlog Integration is done in parallel Requires high levels of communication across teams to resolve integration issues Forces Product Owners to be more coordinated Sprints should be synchronized Cross team fertilization is a requirement to successfully deliver in parallel© 2009-2010, 39 39
  46. 46. Principles for Managing Software Debt Maintain one list of work Emphasize quality Evolve tools and infrastructure continually Improve system design always Share knowledge across the organization And most importantly, get the right people to work on your software!© 2009-2010, 40 40
  47. 47. Thank youQuestions and Answers 41 41
  48. 48. Chris Sterling – Sterling Barton, LLC Partner, Sterling Barton, LLC Author of Book “Managing Software Debt: Building for Inevitable Change” Consults on software technology, Agile technical practices, Scrum, and effective management techniques Email: chris@sterlingbarton.com Certified Scrum Trainer Web: http://www.agileevm.com http://www.sterlingbarton.com Blog: http://www.gettingagile.com Innovation Games® Trained Follow me on Twitter: @csterwa Facilitator Open Source Developer© 2009-2011, 42 42
  1. A particular slide catching your eye?

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

×