recognizing software debt - beyond agile puget sound

Recognizing So+ware Debt

Wednesday, November 30, 2011

Chris Sterling

Co-‐founder of Agile Advantage and VP of Engineering (www.AgileAdvantage.com)

Author of Book “Managing SoAware Debt: Building for Inevitable Change”

Consults on soAware technology, Agile technical pracKces, Scrum, and effecKve management techniques

CerKfied Scrum Trainer

InnovaKon Games® Trained Facilitator

Open Source Developer

2

Email: [email protected] Web: h3p://www.agileadvantage.comFollow me on Twi0er: @csterwaBlog: h3p://www.ge8ngagile.comHashtag for presenta:on: #swdebt


http://www.AgileEVM.com

http://www.AgileEVM.com

mailto:[email protected]


http://chrissterling.gettingagile.com/




http://www.gettingagile.com




Go to ImpedimentMonkey.com!!!

3

Send an email to [email protected] to get invited with your first impediment now!!!




Agenda

Managing SoAware Debt• An OverviewTypes of SoAware Debt• Technical• Quality• ConfiguraKon Management

• Design• PlaUorm Experience

Balancing Signal to Noise• DefiniKon of Done• Source Control Management

• ConKnuous IntegraKon• Quality DashboardsRelease Management• The Power of 2 Scripts: Deploy and Rollback

• ConKnuous IntegraKon• Automated PromoKon

• Turn On/Off FeaturesExercise• SoAware Debt Management Strategy

4


Managing So+ware Debt

An Overview


THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT*

* “SoIware Es:ma:on: Demys:fying the Black Art “ – Steve McConnell

Project size is easily the most significant determinant of effort, cost and schedule [for a soIware project].


“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spagheZ-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Informa:on is shared promiscuously among distant elements of the system, oIen to the point where nearly all the important informa:on becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recogni:on. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the iner:a 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 Pa0erns Languages of Programs (PLoP '97/EuroPLoP '97) Mon:cello, Illinois, September 1997


Lack of emphasis on so'ware quality a2ributes contributes to decay


Types of So+ware Debt


Technical debt tended to focus more on programming aspects of soIware delivery and leI out full soIware development life cycle

Each type of soIware debt can be managed and monitored using different tools and approaches

Focusing on managing each type of soIware debt simplifies crea:on of an overall strategy that promotes holis:c perspec:ve

Why not just call it all “Technical Debt”

11


Types of SoIware Debt

Technical Debt: These are the ac:vi:es that a team or team members do not to do well now that will impede future development if leI as is.

Quality Debt: There is a diminishing ability to verify the func:onal and technical quality of soIware: the “Break/Fix” mentality.

ConfiguraHon Management Debt: Integra:on 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 wri:ng from scratch.

PlaJorm Experience Debt: The availability and alignment of people to business objec:ves that involve soIware changes is becoming more limited or cost-‐prohibi:ve.

8


Principle: No maOer what, the cost of addressing so+ware debt increases

with Hme.


Balancing Signal to Noise at Scale


Balancing Signal Indicators

Value

Quality Constraints(Schedule, Cost, Scope)Source: Jim Highsmith

15


DefiniMon of Done -‐ Assert QualityAcceptance defined criteria for each user story

Unit tests written and passed

Code compiles with no errors and no warnings

New code doesn’t break existing code

Test case review (Dev to review test case written)

Architectural impact assessed and artifacts updated if necessary

Comments in code

Error codes added

Code reviewed by peer

Code checked in with reference to US#/Task#

Tested on FE

Integration test written & passes

Test code reviewed

Environment requirements documented

Interface document updated/added and checked in to SVN

Acceptance criteria verified complete

All P1-P3 bugs for the story are closed

Test approves user story

Story demonstrated to product owner and accepted on Target Platform

16


Release DefiniMon of Done

Every release should have clear quality criteria

With a “Release Defini:on of Done” you can understand targets be0er

Measure the gap between the teams’ Defini:on of Done and a Release Defini:on of Done.• This gap is a source of quality issues and represents significant risk to schedule


TradiMonal Source Control Management

18



18

Main Branch



18

Main Branch

Version 1Branch

Integrate forVersion 2

CodeComplete



18

Main BranchDebt

Death March

Version 1Branch


CodeComplete



18

Main BranchDebt

Death March {Debt accrues quickly within stabilizaHon periods

Version 1Branch


CodeComplete


Flexible Source Control Management

19



19

Main Branch



19

Main Branch

Version 1



19

Main Branch

Version 1 Version 2



19

Main Branch

Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.


ConMnuous IntegraMon

20


21

Quality Dashboard -‐ Sonar


22



23



24



Early Warning Signs

25

Early Warnings:•Broken Builds•Broken Automated Tests•Broken Custom Thresholds


26

Early Warnings:•Design Debt in Duplica:on (DRY)•Technical Debt in Code Complexity•Quality Debt in Bug DB (Break/Fix)•Other Custom Thresholds

Early Warning on Quality Dashboard


Release Management Strategy


“If releases are like giving birth, then you must be doing something wrong.”

-‐ Robert Benefield


Case Study: Enterprise Agile AdopMon

180+ person “Web 2.0” product organiza:on

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

Transi:oned to Agile methods on 15 teams in 3 months

Changed release management strategy, added XP technical prac:ces, and implemented Scrum product development framework for scaled coordina:on

Able to release every week to users within 4 months

Used streamlined deployment environment process to validate product changes daily using Con:nuous Integra:on and automated promo:ons

29


The Power of 2 Scripts: Deploy & Rollback

30


Scaling ConMnuous IntegraMon

31

ComponentValidaHon

Integrated ComponentValidaHon

End-‐to-‐End &Load/Stress


Automated PromoMon to Environments

32


29

The value of technical aspects in an applica:on or its surrounding infrastructure

is the cost of not addressing them.


30

Describe as Abuse User Stories

Implement Securityfor User Information

* From “User Stories Applied” presented by Mike Cohn Agile 2006


30

Describe as Abuse User Stories

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


Some PotenMal Abusers

• Malicious Hacker

• Mass of users

• SQL injector• Disgruntled employee

• Naïve API user• ImpaBent clicker

• Denial-‐of-‐service (DoS) aFacker• Sleazy user

31


SoIware Quality A0ributes Defined

32


SoIware Quality A0ributes Ra:ng Tool

33


Put SoIware Debt on Product Roadmap

34

* Image from Dean Leffingwell’s blog -‐ h0p://scalingsoIwareagility.wordpress.com/

38


http://scalingsoftwareagility.wordpress.com/2009/06/18/agile-product-manager-in-the-enterprise-5-responsibility-3-maintain-the-product-roadmap/

http://scalingsoftwareagility.wordpress.com/2009/06/18/agile-product-manager-in-the-enterprise-5-responsibility-3-maintain-the-product-roadmap/

Exercise: So+ware Debt Management Strategy


Thank you!

QuesHons & Answers


Come see us at AgileAdvantage.com

41


recognizing software debt - beyond agile puget sound

Technology

quality debt

technical debt technical

design debt

congurahon management

technical quality of

plajorm experience debt

soiware project

soiware es