The Software Debt Bubble: Is It About to Burst

The Soware 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: #swdebtMonday, January 9, 2012

Chris Sterling -‐ Sr. Cuer 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 • CerGﬁed Scrum Trainer email: csterling@cuMer.com • InnovaGon Games® Trained blog: www.geNngagile.com Facilitator web: www.AgileAdvantage.com follow me @csterwa hashtag: #swdebt Un evento de Monday, January 9, 2012

Project size is easily the most signiﬁcant determinant of eﬀort, cost and schedule [for a so:ware project]. THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT* * “So@ware EsGmaGon: DemysGfying the Black Art “ – Steve McConnell Un evento de Monday, January 9, 2012

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spagheE-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. InformaJon is shared promiscuously among distant elements of the system, o:en to the point where nearly all the important informaJon becomes global or duplicated. The overall structure of the system may never have been well deﬁned. If it was, it may have eroded beyond recogniJon. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inerJa 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 PaTerns Languages of Programs (PLoP 97/EuroPLoP 97) MonJcello, Illinois, September 1997 Un evento de Monday, January 9, 2012

Un evento de Monday, January 9, 2012

Lack of emphasis on soware quality a2ributes contributes to decay Un evento de 6Monday, January 9, 2012

The “Rewrite”, “NextGen” or “Like-‐to-‐like MigraJon” • “It will be easy since we worked on the original version” -‐ although we understand the domain we will be ﬁghGng with new features, technology, tools, and processes • “We don’t have any other opGons” -‐ Refactoring and test automaGon are potenGal alternaGves to like-‐to-‐like migraGons. Un evento de 7Monday, January 9, 2012

Why RewriGng is (Almost) Never a Good Idea * 1.It will take longer than you think 2.Markets change 3.Exis=ng customers become frustrated 4.Refactoring can clean up the code 5.You don’t control the rewrite, it controls you “Why You Should (Almost) Never Rewrite Your Software” - post to OnStartups.com by Dharmesh Shah http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx Un evento de 8Monday, January 9, 2012

Types of So@ware Debt • Technical Debt: These are the acGviGes 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 funcGonal and technical quality of so@ware. • Conﬁgura<on Management Debt: IntegraGon 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 wriGng from scratch. • Pla@orm Experience Debt: The availability of people to work on so@ware changes is becoming limited or cost-‐prohibiGve. Un evento de 8Monday, January 9, 2012

“Lowering quality lengthens development Jme.” -‐ From wiki page on “First Law of Programming” (c2.com) TECHNICAL DEBT Un evento de 9Monday, January 9, 2012

PaMerns of Technical Debt Duplica@on Schedule Pressure Get it “right” the ﬁrst @me mentality Un evento de 10Monday, January 9, 2012

Aspects of the soJware’s design that teams agree to should be automated, if possible, and break the build when they are not adhered to. Un evento de 11Monday, January 9, 2012

Keep DRY (Don’t Repeat Yourself) * Sonar -‐ an open source quality dashboard hTp://www.sonarsource.org/ Un evento de 12Monday, January 9, 2012

Remove Complexity * Sonar -‐ an open source quality dashboard hTp://www.sonarsource.org/ Un evento de 13Monday, January 9, 2012

Trend Technical Debt Metrics * Sonar -‐ an open source quality dashboard hTp://www.sonarsource.org/ Un evento de 14Monday, January 9, 2012

Trend Technical Debt Metrics* SQALE -‐ a commercial Sonar plugin Un evento de 15hTp://www.sonarsource.com/plugins/plugin-‐sqale/overview/ Monday, January 9, 2012

No ma2er what, the cost of addressing technical debt increases with <me. Un evento de 16Monday, January 9, 2012

“Promises make debt, and debt makes promises.” -‐ Dutch Proverb QUALITY DEBT Un evento de 17Monday, January 9, 2012

Eﬀect of Project Constraints on Quality Un evento de 18Monday, January 9, 2012

“For every [dollar] of compe==ve advantage gained by cuAng quality, it costs $4 to restore it; and soJware is an organiza=onal asset and decisions to cut quality must be made by execu<ve management and reﬂected in the ﬁnancial statements.” -‐-‐ Ken Schwaber, co-‐creator of Scrum Un evento de 19Monday, January 9, 2012

Acceptance Test-‐Driven Development Un evento de 20Monday, January 9, 2012

Cost reducJon using Fit for acceptance test automaJon for insurance company plaeorm and data migraJon project AN ACCEPTANCE TEST-‐DRIVEN DEVELOPMENT CASE STUDY Un evento de 21Monday, January 9, 2012

Manual Regression TesGng • Tes=ng was taking 75 person hours during 2 full test runs consis=ng of: – Comprehensive manual regression tesJng – Data conversion and validaJon • Cost for tes=ng was $17,000 each itera@on Un evento de 22Monday, January 9, 2012

Introducing Fit into TesGng Process • A:er 8 itera@ons team had introduced healthy amount of Fit ﬁxtures and automated tests • Reduced 70+ hour test runJme down to 6 hours which now included: – Fit automated regression tesJng – Data conversion and validaJon automated with Fit ﬁxtures • Reduced cost of tesJng each iteraJon from $17,000 to $7,000 Un evento de 23Monday, January 9, 2012

“If releases are like giving birth, then you must be doing something wrong.” -‐-‐ Robert Beneﬁeld CONFIGURATION MANAGEMENT DEBT Un evento de 24Monday, January 9, 2012

Case Study: Enterprise Agile AdopJon • 180+ person “Web 2.0” product organizaJon • 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 • TransiJoned to Agile methods on 15 teams in 3 months • Changed release management strategy, added XP technical pracJces, and implemented Scrum product development framework for scaled coordinaJon • Able to release every week to users within 4 months • Used streamlined deployment environment process to validate product changes daily using ConJnuous IntegraJon and automated promoJons Un evento de 25Monday, January 9, 2012

The Power of 2 Scripts: Deploy and Rollback Un evento de 26Monday, January 9, 2012

Automated PromoGon to Environments Un evento de 27Monday, January 9, 2012

Design decays when not aTended to so design so:ware conJnually DESIGN DEBT Un evento de 28Monday, January 9, 2012

The value of technical aspects in an applica=on or its surrounding infrastructure is the cost of not addressing them. Un evento de 29Monday, January 9, 2012

Describe as Abuse User Stories Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006 Un evento de 30Monday, January 9, 2012

Describe as 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 Un evento de 30Monday, January 9, 2012

Some PotenGal Abusers • Malicious Hacker • Mass of users • SQL injector • Disgruntled employee • Naïve API user • ImpaJent clicker • Denial-‐of-‐service (DoS) aTacker • Sleazy user Un evento de 31Monday, January 9, 2012

So@ware Quality AMributes Deﬁned Un evento de 32Monday, January 9, 2012

So@ware Quality AMributes RaGng Tool Un evento de 33Monday, January 9, 2012

Put So@ware Debt on Product Roadmap * Image from Dean Leﬃngwell’s blog -‐ hTp://scalingso:wareagility.wordpress.com/ Un evento de 34Monday, January 9, 2012

“As in Nature, if an organizaJon is too inﬂexible or stands sJll too long it will get eaten.” -‐ James Burke (author and historian) PLATFORM EXPERIENCE DEBT Un evento de 35Monday, January 9, 2012

Rather than crea=ng teams to work on projects, let’s ﬁnd ways to give projects to cross-‐func<onal teams. Un evento de 36Monday, January 9, 2012

Component Team ConﬁguraGon • “Component Team” structure • Separate Product Backlog • Managing dependencies is o:en serialized • ProblemaJc integraJon issues are typically faced if mulJple components are required to release • Use an “IntegraJon Team” to pull components together • Causes more rework than “Feature Team” structure Un evento de 37Monday, January 9, 2012

Feature Team ConﬁguraGon • “Feature Team” structure • Uses common Product Backlog • IntegraJon is done in parallel • Requires high levels of communicaJon across teams to resolve integraJon issues • Forces Product Owners to be more coordinated • Sprints should be synchronized • Cross team ferJlizaJon is a requirement to successfully deliver in parallel Un evento de 38Monday, January 9, 2012

“What he needs is some way to pay back. Not some way to borrow more.” -‐-‐ Will Rogers THE “NO DEFECT” MINDSET Un evento de 39Monday, January 9, 2012

Case Study: Field Support ApplicaGon • 2000+ users access applicaGon each day • ApplicaGon supports mulGple perspecGves and workﬂows from Field Support OperaGons to Customer Service • Team of 5 people delivering features on exisGng Cold Fusion plahorm implementaGon • MigraGng Architecture to Spring/Hibernate in slices while sGll delivering valuable features • 36 2-‐week Sprints, 33 producGon releases, and only 1 defect found in producGon • So, what was the defect you say? Let me tell you… Un evento de 40Monday, January 9, 2012

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 iteraJon this team was able to deliver more than other vendor was able to in previous 2 months • A:er 24 iteraJons this team was 10 Jmes faster delivery than1st iteraJon • Acceptance Test-‐Driven Development and ConJnuous IntegraJon were greatest technical factors to support team in these results • Can you afford not to have a “No Defect” policy? Un evento de 41Monday, January 9, 2012

Acceptance Test-‐Driven Development Un evento de 42Monday, January 9, 2012

The Power of 2 Scripts: Deploy and Rollback Un evento de 43Monday, January 9, 2012

Thank you Ques=ons and Answers Un evento de 44Monday, January 9, 2012

http://www.gettingagile.com	1122
http://fasoulas.posterous.com	15
http://blog.fasoulas.com	5
http://twitter.com	2
http://tweetedtimes.com	2
http://www.onlydoo.com	1
http://posterous.com	1

The Software Debt Bubble: Is It About to Burst

by Chris Sterling on Aug 18, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 1,148

Statistics

The Software Debt Bubble: Is It About to Burst — Presentation Transcript