UW Agile CP202 Class 3: Managing Software Debt Continued Delivery of High Value as Systems Age Chris Sterling Technology Consultant / Agile Coach / Certified Scrum Trainer Sterling Barton, LLC Web: www.SterlingBarton.com Email: [email protected]Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt 1 Monday, May 10, 2010
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UW Agile CP202 Class 3:Managing Software DebtContinued Delivery of High Value as Systems Age
Chris SterlingTechnology Consultant / Agile Coach /
Software gets difficult to add features to as it ages
Business expectations do not lessen as software ages
Software must remain maintainable and changeable to meet needs of business over time
3Monday, May 10, 2010
Lack of emphasis on software quality attributes contributes to
decay
4Monday, May 10, 2010
Like-to-Like Migrations
“It will be easy since we worked on the original version” - although we understand the domain we will be fighting with new features, technology, tools, and processes
“We don’t have any other options” - Refactoring and test automation are potential alternatives to like-to-like migrations.
5Monday, May 10, 2010
Limited Platform Expertise
Risk and costs increase as expertise becomes more limited for aging software platforms.
6Monday, May 10, 2010
Costs for Release Stabilization
0
125000
250000
375000
500000
Release 1Release 2
Release 3Release 4
Release 5Release 6
Cost of Fixing Defects Cost for Feature Dev
7Monday, May 10, 2010
Regression Costs - Manual vs.
8Monday, May 10, 2010
Extreme Specialization
Knowledge and capability to maintain legacy software decays with time
Costs to maintain rarely used software platforms are higher
Leads to waiting for people in specialized roles to finish their tasks in support of development effort
9Monday, May 10, 2010
Software DebtCreeps into software slowly and leaves organizations with liabilities
10Monday, May 10, 2010
Software Debt Creeps In
Shows a relatively new system with little software debt accrued.
11Monday, May 10, 2010
Software Debt Creeps In
An aging software system slowly incurs significant debt in multiple functional areas.
12Monday, May 10, 2010
Software Debt Creeps In
An older system has accrued significant debt in all functional areas and components.
13Monday, May 10, 2010
Managing Software Debt – an
14Monday, May 10, 2010
Managing Software Debt
It is impossible to stop software debt from creeping into our software
Managing debt in software is based on putting frequent feedback mechanisms in place for code, quality assurance, configuration management, design, and organization of people on project team
Feedback mechanisms should be frequent, automated, and easy to use to support their continued use or modified to new needs
15Monday, May 10, 2010
Types of Software Debt
Technical Debt
Quality Debt
Configuration Management Debt
Design Debt
Platform Experience Debt
16Monday, May 10, 2010
Technical DebtIssues in software implementation that will impede future development
if left unresolved
17Monday, May 10, 2010
* Ward Cunningham on “Technical Debt”
Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring.
Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard).
“Technical debt is the decay of component and inter-component behavior when the application
functionality meets a minimum standard of satisfaction for the customer.”
19Monday, May 10, 2010
Test-Driven Development
Test-Driven Development (TDD)
The “Flow”
Integrating with Team
Difficulties with TDD
Example TDD Session
Refactoring
20Monday, May 10, 2010
Questions for You...
How many of you are practicing TDD?
What issues are you having currently with TDD?
21Monday, May 10, 2010
TDD - Basic “Flow”
22Monday, May 10, 2010
TDD - Basic “Flow”
Write Failing Test
22Monday, May 10, 2010
TDD - Basic “Flow”
Write Failing Test
Make Test Pass
22Monday, May 10, 2010
TDD - Basic “Flow”
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
22Monday, May 10, 2010
TDD - Basic “Flow”
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
22Monday, May 10, 2010
Steps of TDD “Flow”
1. Write a programmer test
2. Run the programmer test and it should fail (red bar)
3. Write just enough code to make failing test pass
4. Run programmer test successfully (green bar)
5. Refactor code to an acceptable design (green bar)
RISK: Pushing out refactoring to add more code first. Don’t forget to refactor frequently to an acceptable design.
23Monday, May 10, 2010
Be a User --“What should the software do next
This question helps you to decide what the next programmer test should model
24Monday, May 10, 2010
Integrating with Team
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
Make Test Pass
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
Make Test Pass
Integrate with Team
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
25Monday, May 10, 2010
Integrating with Team
Write Failing Test
Make Test Pass
Refactor to Acceptable Design
Integrate with Team
25Monday, May 10, 2010
Need-Driven Design
26Monday, May 10, 2010
Test-Driven Development
What Causes TDD to be so Difficult to Implement Well?
27Monday, May 10, 2010
Impediments to TDD
This simple technique for developing software, when used in a disciplined manner, will enable individuals and teams to improve software quality. The discipline necessary to do TDD is not easily attainable. Following is a list of environmental issues that lowers chances of effectively implementing TDD approach.
28Monday, May 10, 2010
Schedule Pressure
Pressure from management and stakeholders to release based on an unreasonable plan. Integrity of the software is always sacrificed when the plan is inflexible and unwilling to incorporate reality.
29Monday, May 10, 2010
Lack of Passion
Lack of passion for learning and implementing TDD effectively on Team. The amount of discipline required makes passion extremely helpful.
30Monday, May 10, 2010
Insufficient Experience
Insufficient team member ratio who have experience doing TDD well. When there is little experience on or coaching for the team success is minimal.
31Monday, May 10, 2010
Legacy Code
If the software’s design is poor or is difficult to test then finding a starting point could seem impossible. If legacy code is large and contains no, or only minimal, test coverage then disciplined TDD will not show visible results for some time.
32Monday, May 10, 2010
Introducing TDD Approach
To successfully adopt TDD, it is important to manage these environmental issues. This could include managing expectations, providing the Team support from a coach, and enabling sufficient learning of tools and techniques while working with an existing code base.
33Monday, May 10, 2010
Test-Driven Development
Quick Example
34Monday, May 10, 2010
Jitter – Example TDD SessionFake 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
35Monday, May 10, 2010
Expand LOL to “laughing out loud”
public class WhenUsersWantToExpandMessagesThatContainShorthandTest {
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