The So'ware Debt Bubble Is it about to burst? Chris Sterling VP of Engineering Agile Advantage, Inc. Web: www.agileadvantage.com Email: chris@agileadvantage.com Blog: www.gettingagile.com Follow Me on Twitter: @csterwa Hash Tag for Presentation: #swdebt
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
Project size is easily the most significant determinant of effort, cost and schedule [for a so'ware project]. THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT* * So'ware EsImaIon: DemysIfying the Black Art Steve McConnell
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
Lack of emphasis on so'ware quality a=ributes contributes to decay 6
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
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
Lowering quality lengthens development Ime. - From wiki page on First Law of Programming (c2.com) TECHNICAL DEBT 9
Pa=erns of Technical Debt DuplicaIon Schedule Pressure Get it right the first Ime mentality 10
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. 11
Keep DRY (Don t Repeat Yourself) * Sonar - an open source quality dashboard h=p://www.sonarsource.org/ 12
Remove Complexity * Sonar - an open source quality dashboard h=p://www.sonarsource.org/ 13
Trend Technical Debt Metrics * Sonar - an open source quality dashboard h=p://www.sonarsource.org/ 14
Trend Technical Debt Metrics * SQALE - a commercial Sonar plugin h=p://www.sonarsource.com/plugins/plugin- sqale/overview/ 15
No ma=er what, the cost of addressing technical debt increases with Ime. 16
Promises make debt, and debt makes promises. - Dutch Proverb QUALITY DEBT 17
Effect of Project Constraints on Quality 18
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 19
Acceptance Test- Driven Development 20
Cost reducion using Fit for acceptance test automaion for insurance company plasorm and data migraion project AN ACCEPTANCE TEST- DRIVEN DEVELOPMENT CASE STUDY 21
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
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
If releases are like giving birth, then you must be doing something wrong. - - Robert Benefield CONFIGURATION MANAGEMENT DEBT 24
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
The Power of 2 Scripts: Deploy and Rollback 26
Automated PromoIon to Environments 27
Design decays when not a=ended to so design so'ware coninually DESIGN DEBT 28
The value of technical aspects in an applicaion or its surrounding infrastructure is the cost of not addressing them. 29
Describe as Abuse User Stories * From User Stories Applied presented by Mike Cohn Agile 2006 30
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
So'ware Quality A=ributes Defined 32
So'ware Quality A=ributes RaIng Tool 33
Put So'ware Debt on Product Roadmap * Image from Dean Leffingwell s blog - h=p://scalingso'wareagility.wordpress.com/ 34
As in Nature, if an organizaion is too inflexible or stands sill too long it will get eaten. - James Burke (author and historian) PLATFORM EXPERIENCE DEBT 35
Rather than creaing teams to work on projects, let s find ways to give projects to cross- funcional teams. 36
Component Team ConfiguraIon 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 37
Feature Team ConfiguraIon 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 38
What he needs is some way to pay back. Not some way to borrow more. - - Will Rogers THE NO DEFECT MINDSET 39
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
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
Acceptance Test- Driven Development 42
The Power of 2 Scripts: Deploy and Rollback 43
Thank you QuesIons and Answers 44