The Software Debt Bubble: Is It About to Burst
44
The So’ware Debt Bubble Is it about to burst? Chris Sterling VP of Engineering Agile Advantage, Inc. Web: www.AgileAdvantage.com Email: [email protected]om Blog: www.GettingAgil e.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt
-
Upload
chris-sterling -
Category
Technology
-
view
6.297 -
download
4
description
This is a keynote presentation that I am delivering at Cutter Agile Mexico 2011 in Mexico, City August 2011.
Transcript of The Software Debt Bubble: Is It About to Burst
The So'ware Debt Bubble Is it about to burst?
Chris Sterling VP of Engineering
Agile Advantage, Inc. Web: www.AgileAdvantage.com Email: [email protected] Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt
Un evento de
Chris Sterling -‐ Sr. Cu=er Consultant
• CTO at Agile Advantage, Inc. • Author of Book “Managing
So'ware Debt: Building for Inevitable Change”
• Consults on So'ware Debt Management Strategies
• Conducts Technical Debt Assessments
• CerIfied Scrum Trainer • InnovaIon Games® Trained
Facilitator email: csterling@cu=er.com blog: www.geOngagile.com web: www.AgileAdvantage.com follow me @csterwa hashtag: #swdebt
Un evento de
THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT*
Project size is easily the most significant determinant of effort, cost and schedule [for a so'ware project].
* “So'ware EsImaIon: DemysIfying the Black Art “ – Steve McConnell
Un evento de
“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spagheO-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. InformaIon is shared promiscuously among distant elements of the system, o'en to the point where nearly all the important informaIon becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recogniIon. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inerIa of the day-‐to-‐day chore of patching the holes in these failing dikes, are content to work on such systems.” *
Big Ball of Mud * Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Pa=erns Languages of Programs (PLoP '97/EuroPLoP '97) MonIcello, Illinois, September 1997
Un evento de
Un evento de 6
Lack of emphasis on so'ware quality a=ributes contributes to decay
Un evento de
The “Rewrite”, “NextGen” or “Like-‐to-‐like MigraIon”
• “It will be easy since we worked on the original version” -‐ although we understand the domain we will be fighIng with new features, technology, tools, and processes
• “We don’t have any other opIons” -‐ Refactoring and test automaIon are potenIal alternaIves to like-‐to-‐like migraIons.
7
Un evento de
Types of So'ware Debt
• Technical Debt: These are the acIviIes that a team or team members choose not to do well now and will impede future development if le' undone.
• Quality Debt: There is a diminishing ability to verify the funcIonal and technical quality of so'ware.
• ConfiguraDon Management Debt: IntegraIon 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 wriIng from scratch.
• PlaGorm Experience Debt: The availability of people to work on so'ware changes is becoming limited or cost-‐prohibiIve.
8
Un evento de
TECHNICAL DEBT
“Lowering quality lengthens development Ime.” -‐ From wiki page on “First Law of Programming” (c2.com)
9
Un evento de
Pa=erns of Technical Debt
10
Schedule Pressure
DuplicaIon
Get it “right” the first Ime mentality
Un evento de 11
Aspects of the so'ware’s design that teams agree to should be automated, if possible, and break the build when they are not
adhered to.
Un evento de 12
Keep DRY (Don’t Repeat Yourself)
* Sonar -‐ an open source quality dashboard h=p://www.sonarsource.org/
Un evento de 13
Remove Complexity
* Sonar -‐ an open source quality dashboard h=p://www.sonarsource.org/
Un evento de 14
Trend Technical Debt Metrics
* Sonar -‐ an open source quality dashboard h=p://www.sonarsource.org/
Un evento de 15
Trend Technical Debt Metrics
* SQALE -‐ a commercial Sonar plugin h=p://www.sonarsource.com/plugins/plugin-‐sqale/overview/
Un evento de 16
No ma=er what, the cost of addressing technical debt increases with Ime.
Un evento de
QUALITY DEBT “Promises make debt, and debt makes promises.” -‐ Dutch Proverb
17
Un evento de
Effect of Project Constraints on Quality
18
Un evento de 19
“For every [dollar] of compeIIve advantage gained by cuOng quality, it costs $4 to restore it;
and so'ware is an organizaIonal asset and decisions to cut quality must be made by
execuIve management and reflected in the financial statements.”
-‐-‐ Ken Schwaber, co-‐creator of Scrum
Un evento de
Acceptance Test-‐Driven Development
20
Un evento de
AN ACCEPTANCE TEST-‐DRIVEN DEVELOPMENT CASE STUDY
Cost reducIon using Fit for acceptance test automaIon for insurance company plasorm and data migraIon project
21
Un evento de
Manual Regression TesIng
• TesIng was taking 75 person hours during 2 full test runs consisIng of: – Comprehensive manual regression tesIng – Data conversion and validaIon
• Cost for tesIng was $17,000 each iteraIon
22
Un evento de
Introducing Fit into TesIng Process
• A'er 8 iteraIons team had introduced healthy amount of Fit fixtures and automated tests
• Reduced 70+ hour test runIme down to 6 hours which now included: – Fit automated regression tesIng
– Data conversion and validaIon automated with Fit fixtures
• Reduced cost of tesIng each iteraIon from $17,000 to $7,000
23
Un evento de
CONFIGURATION MANAGEMENT DEBT
“If releases are like giving birth, then you must be doing something wrong.” -‐-‐ Robert Benefield
24
Un evento de
Case Study: Enterprise Agile AdopIon
• 180+ person “Web 2.0” product organizaIon • Waterfall SDLC that development uses to deliver in 6 month release
cycles • Want to use Agile methods to be more responsive to users and keep up
with other “Web 2.0” companies • TransiIoned to Agile methods on 15 teams in 3 months • Changed release management strategy, added XP technical pracIces,
and implemented Scrum product development framework for scaled coordinaIon
• Able to release every week to users within 4 months • Used streamlined deployment environment process to validate
product changes daily using ConInuous IntegraIon and automated promoIons
25
Un evento de
The Power of 2 Scripts: Deploy and Rollback
26
Un evento de
Automated PromoIon to Environments
27
Un evento de
DESIGN DEBT Design decays when not a=ended to so design so'ware conInually
28
Un evento de 29
The value of technical aspects in an applicaIon or its surrounding infrastructure is
the cost of not addressing them.
Un evento de 30
Describe as Abuse User Stories
* From “User Stories Applied” presented by Mike Cohn Agile 2006
Un evento de
Some PotenIal Abusers
• Malicious Hacker
• Mass of users
• SQL injector • Disgruntled employee
• Naïve API user • ImpaIent clicker
• Denial-‐of-‐service (DoS) a=acker • Sleazy user
31
Un evento de
So'ware Quality A=ributes Defined
32
Un evento de
So'ware Quality A=ributes RaIng Tool
33
Un evento de
Put So'ware Debt on Product Roadmap
34
* Image from Dean Leffingwell’s blog -‐ h=p://scalingso'wareagility.wordpress.com/
Un evento de
PLATFORM EXPERIENCE DEBT
“As in Nature, if an organizaIon is too inflexible or stands sIll too long it will get eaten.” -‐ James Burke (author and historian)
35
Un evento de 36
Rather than creaIng teams to work on projects, let’s find ways to give projects to
cross-‐funcIonal teams.
Un evento de
Component Team ConfiguraIon
37
• “Component Team” structure
• Separate Product Backlog
• Managing dependencies is o'en serialized
• ProblemaIc integraIon issues are typically faced if mulIple components are required to release
• Use an “IntegraIon Team” to pull components together
• Causes more rework than “Feature Team” structure
Un evento de
Feature Team ConfiguraIon
38
• “Feature Team” structure
• Uses common Product Backlog
• IntegraIon is done in parallel
• Requires high levels of communicaIon across teams to resolve integraIon issues
• Forces Product Owners to be more coordinated
• Sprints should be synchronized
• Cross team ferIlizaIon is a requirement to successfully deliver in parallel
Un evento de
THE “NO DEFECT” MINDSET
“What he needs is some way to pay back. Not some way to borrow more.” -‐-‐ Will Rogers
39
Un evento de
Case Study: Field Support ApplicaIon
• 2000+ users access applicaIon each day • ApplicaIon supports mulIple perspecIves and workflows
from Field Support OperaIons to Customer Service
• Team of 5 people delivering features on exisIng Cold Fusion plasorm implementaIon
• MigraIng Architecture to Spring/Hibernate in slices while sIll delivering valuable features
• 36 2-‐week Sprints, 33 producIon releases, and only 1 defect found in producIon
• So, what was the defect you say? Let me tell you…
40
Un evento de
Can We Afford a “No Defect” Policy?
• This team worked on legacy codebase inherited from another vendor • Other vendor had been slowing down month a'er month and cost of
development was increasing
• In first iteraIon this team was able to deliver more than other vendor was able to in previous 2 months
• A'er 24 iteraIons this team was 10 Imes faster delivery than1st iteraIon
• Acceptance Test-‐Driven Development and ConInuous IntegraIon were greatest technical factors to support team in these results
• Can you afford not to have a “No Defect” policy?
41
Un evento de
Acceptance Test-‐Driven Development
42
Un evento de
The Power of 2 Scripts: Deploy and Rollback
43
Un evento de 44
Thank you
QuesIons and Answers
