Managing Software Debt in Practice 2011

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

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 Certiﬁed Scrum Trainer Blog: http://www.gettingagile.com Follow me on Twitter: @csterwa Innovation Games® Trained Facilitator Open Source Developer© 2009-2011, 2 2

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. Conﬁguration 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

Technical Debt“Lowering quality lengthens development time.” - From wiki page on “First Lawof Programming” (c2.com) 4 4

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 ﬁrst 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

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

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 ﬁrst glance, does refactoring look like a large endeavor involving signiﬁcant portions of the software’s components?© 2009-2010, 11 11

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 sufﬁciently? 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

Automate Testing to Support Refactoring Refactoring cannot be done effectively without automated tests surrounding code Start by creating automated test which fails If difﬁcult 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

Ji:er – Example TDD Session• Fake micro-‐blogging tool named “Ji4er” is made by Sea4le-‐based ﬁc::ous company that focuses on enabling coﬀee 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

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

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

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

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 ﬂag 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

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 modiﬁed 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

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 ﬁnal 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

Quality Debt“Promises make debt, and debt makes promises.” - Dutch Proverb 22 22

“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 reﬂected in the ﬁnancial statements.” - Ken Schwaber© 2009-2010, 24 24

Conﬁguration Management Debt“If releases are like giving birth, then you must be doing something wrong.” - Robert Beneﬁeld 26 26

Design DebtDesign decays when not attended to so design software continually 28 28

* 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

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 clariﬁcation on abuse stories that the Product Owner does not understand well.© 2009-2010, 31 31

Platform Experience Debt“As in Nature, if an organization is too inﬂexible or stands still too long it will geteaten.” - James Burke (author and historian) 36 36

Component Team Conﬁguration “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

Feature Team Conﬁguration “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

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

Thank youQuestions and Answers 41 41

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 Certiﬁed 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

http://www.gettingagile.com	542
url_unknown	5
http://www.kudutalk.com	3
http://translate.googleusercontent.com	1

Managing Software Debt in Practice 2011

by Chris Sterling on May 17, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 551

Statistics

Managing Software Debt in Practice 2011 — Presentation Transcript