Embed Size (px)
DESCRIPTION
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.
Citation preview
Managing Software Debt in Practice
“What he needs is some way to pay back. Not some way to borrow more.” - Will Rogers
Chris SterlingVP of EngineeringAgileEVM Inc.
Web: www.AgileEVM.comEmail: [email protected]
Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
1
© 2009-2011,
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
Certified Scrum Trainer
Innovation Games® Trained Facilitator
Open Source Developer2
Email: [email protected] Web: http://www.agileevm.comBlog: http://www.gettingagile.comFollow me on Twitter: @csterwa
2
© 2009-2010,
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.
3
3
Technical Debt
4
“Lowering quality lengthens development time.” - From wiki page on “First Law of Programming” (c2.com)
4
© 2009-2010,
Patterns of Technical Debt
5
Schedule Pressure
Duplication
Get it “right” the first time mentality
5
© 2009-2010,
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.
6
6
© 2009-2010,
Keep DRY (Don’t Repeat Yourself)
7
7
© 2009-2010,
No matter what, the cost of addressing technical debt increases with time.
8
8
© 2009-2010,
Principles of Executable Design
9
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.
9
© 2009-2010,
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
10* From http://www.refactoring.com/
10
© 2009-2010,
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?
11
11
© 2009-2010,
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
12
12
© 2009-2010,
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
13
13
© 2009-2010,
TDD - Basic “Flow”
14
14
© 2009-2010,
TDD - Basic “Flow”
14
Write Failing Test
14
© 2009-2010,
TDD - Basic “Flow”
14
Write Failing Test
Make Test Pass
14
© 2009-2010,
TDD - Basic “Flow”
14
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
14
© 2009-2010,
TDD - Basic “Flow”
14
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
14
© 2009-2010,
Jitter – Example TDD Session
Fake micro-blogging tool named “Jitter” is made by Seattle-based fictitious 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 automatically expand common shorthand notation
The acceptance criteria for this user story are:
LOL, AFAIK, and TTYL are expandable
Expand lower and upper case versions of shorthand
15
15
© 2009-2010,
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"));
}
}
16
16
© 2009-2010,
But wait…what if…?
What if LOL is written in lower case?
What if it is written as “Lol”? Should it be expanded?
What if some variation of LOL is inside a word?
What if characters surrounding LOL are symbols, not letters?
Write these down as upcoming programmer tests as comments so I don’t forget them.
// shouldExpandLOLIfLowerCase
// shouldNotExpandLOLIfMixedCase
// shouldNotExpandLOLIfInsideWord
// shouldExpandIfSurroundingCharactersAreNotLetters
17
17
© 2009-2010,
Expand LOL If Lower Case
@Test
public 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.util.regex.Pattern to handle case insensitivity.
public String getNextMessage() {
String msg = session.getNextMessage();
return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE)
.matcher(msg).replaceAll("laughing out loud");
}
18
18
© 2009-2010,
Don’t Expand “Lol” – Mixed-Case
@Test
public 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 Pattern.CASE_INSENSITIVE flag in pattern compilation. Only use “LOL” or “lol” for now.
public String getNextMessage() {
String msg = session.getNextMessage();
return Pattern.compile("LOL|lol").matcher(msg)
.replaceAll("laughing out loud");
}
19
19
© 2009-2010,
Don’t Expand “LOL” If Inside Word
@Test
public 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 pattern matching is now modified to use spaces around each variation of valid LOL shorthand.
return Pattern.compile("\\sLOL\\s|\\slol\\s").matcher(msg)
.replaceAll("laughing out loud");
20
20
© 2009-2010,
Expand “LOL” If Not Inside Word
@Test
public void shouldExpandIfSurroundingCharactersAreNotLetters() {
when(session.getNextMessage()).thenReturn("Expand .lol! please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand .laughing out loud! please"));
}
Final implementation of pattern matching code:
return Pattern.compile("\\bLOL\\b|\\blol\\b").matcher(msg)
.replaceAll("laughing out loud");
21
21
Quality Debt
“Promises make debt, and debt makes promises.” - Dutch Proverb
22
22
© 2009-2010,
Effect of Project Constraints on Quality
23
23
© 2009-2010,
Effect of Project Constraints on Quality
23
23
© 2009-2010,
“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
24
24
© 2009-2010,
Acceptance Test-Driven Development
25
25
Configuration Management Debt
“If releases are like giving birth, then you must be doing something wrong.” - Robert Benefield
26
26
© 2009-2010,
The Power of 2 Scripts: Deploy and Rollback
27
27
Design Debt
Design decays when not attended to so design software continually
28
28
© 2009-2010,
The value of technical aspects in an application or its surrounding infrastructure is the cost of not addressing them.
29
29
© 2009-2010,
* Abuse User Stories
30
Implement Securityfor User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
30
© 2009-2010,
* Abuse User Stories
30
Implement Securityfor User Information
As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges
* From “User Stories Applied” presented by Mike Cohn Agile 2006
30
© 2009-2010,
Abuse Story Writing Workshop
31
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.
31
© 2009-2010,
Some Potential Abusers
Malicious Hacker
Mass of users
SQL injector
Disgruntled employee
Naïve API user
Impatient clicker
Denial-of-service (DoS) attacker
Sleazy user32
32
© 2009-2010,
Lack of emphasis on software quality attributes contributes to decay
33
33
© 2009-2010,
Software Quality Attributes Defined
34
34
© 2009-2010,
Software Quality Attributes Rating Tool
35
35
Platform Experience Debt
“As in Nature, if an organization is too inflexible or stands still too long it will get eaten.” - James Burke (author and historian)
36
36
© 2009-2010,
Rather than creating teams to work on projects, let’s find ways to give projects to cross-functional teams.
37
37
© 2009-2010,
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 “IntegrationTeam” to pull components together
Causes more rework than “Feature Team” structure
38
38
© 2009-2010,
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 arequirement to successfully deliver in parallel
39
39
© 2009-2010,
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!
40
40
Thank you
Questions and Answers
41
41
© 2009-2011,
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
Certified Scrum Trainer
Innovation Games® Trained Facilitator
Open Source Developer42
Email: [email protected] Web: http://www.agileevm.comBlog: http://www.gettingagile.comFollow me on Twitter: @csterwa
42
