How to Troubleshoot Apps for the Modern Connected Worker
The Software Debt Bubble: Is It About to Burst
1. 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
Monday, January 9, 2012
2. 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
• CerGfied
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
3. 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
EsGmaGon:
DemysGfying
the
Black
Art
“
–
Steve
McConnell
Un
evento
de
Monday, January 9, 2012
4. “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
defined.
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
6. Lack
of
emphasis
on
so'ware
quality
a2ributes
contributes
to
decay
Un
evento
de
6
Monday, January 9, 2012
7. 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
fighGng
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
7
Monday, January 9, 2012
8. 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
8
Monday, January 9, 2012
9. 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.
• Configura<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
8
Monday, January 9, 2012
10. “Lowering
quality
lengthens
development
Jme.”
-‐
From
wiki
page
on
“First
Law
of
Programming”
(c2.com)
TECHNICAL
DEBT
Un
evento
de
9
Monday, January 9, 2012
11. PaMerns
of
Technical
Debt
Duplica@on
Schedule
Pressure
Get
it
“right”
the
first
@me
mentality
Un
evento
de
10
Monday, January 9, 2012
12. 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
11
Monday, January 9, 2012
13. Keep
DRY
(Don’t
Repeat
Yourself)
*
Sonar
-‐
an
open
source
quality
dashboard
hTp://www.sonarsource.org/
Un
evento
de
12
Monday, January 9, 2012
14. Remove
Complexity
*
Sonar
-‐
an
open
source
quality
dashboard
hTp://www.sonarsource.org/
Un
evento
de
13
Monday, January 9, 2012
15. Trend
Technical
Debt
Metrics
*
Sonar
-‐
an
open
source
quality
dashboard
hTp://www.sonarsource.org/
Un
evento
de
14
Monday, January 9, 2012
16. Trend
Technical
Debt
Metrics
*
SQALE
-‐
a
commercial
Sonar
plugin
Un
evento
de
15
hTp://www.sonarsource.com/plugins/plugin-‐sqale/overview/
Monday, January 9, 2012
17. No
ma2er
what,
the
cost
of
addressing
technical
debt
increases
with
<me.
Un
evento
de
16
Monday, January 9, 2012
18. “Promises
make
debt,
and
debt
makes
promises.”
-‐
Dutch
Proverb
QUALITY
DEBT
Un
evento
de
17
Monday, January 9, 2012
19. Effect
of
Project
Constraints
on
Quality
Un
evento
de
18
Monday, January 9, 2012
20. Effect
of
Project
Constraints
on
Quality
Un
evento
de
18
Monday, January 9, 2012
21. “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
reflected
in
the
financial
statements.”
-‐-‐
Ken
Schwaber,
co-‐creator
of
Scrum
Un
evento
de
19
Monday, January 9, 2012
23. 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
21
Monday, January 9, 2012
24. 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
22
Monday, January 9, 2012
25. Introducing
Fit
into
TesGng
Process
• A:er
8
itera@ons
team
had
introduced
healthy
amount
of
Fit
fixtures
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
fixtures
• Reduced
cost
of
tesJng
each
iteraJon
from
$17,000
to
$7,000
Un
evento
de
23
Monday, January 9, 2012
26. “If
releases
are
like
giving
birth,
then
you
must
be
doing
something
wrong.”
-‐-‐
Robert
Benefield
CONFIGURATION
MANAGEMENT
DEBT
Un
evento
de
24
Monday, January 9, 2012
27. 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
25
Monday, January 9, 2012
28. The
Power
of
2
Scripts:
Deploy
and
Rollback
Un
evento
de
26
Monday, January 9, 2012
30. Design
decays
when
not
aTended
to
so
design
so:ware
conJnually
DESIGN
DEBT
Un
evento
de
28
Monday, January 9, 2012
31. The
value
of
technical
aspects
in
an
applica=on
or
its
surrounding
infrastructure
is
the
cost
of
not
addressing
them.
Un
evento
de
29
Monday, January 9, 2012
32. Describe
as
Abuse
User
Stories
Implement Security
for User Information
*
From
“User
Stories
Applied”
presented
by
Mike
Cohn
Agile
2006
Un
evento
de
30
Monday, January 9, 2012
33. 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
30
Monday, January 9, 2012
34. 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
31
Monday, January 9, 2012
37. Put
So@ware
Debt
on
Product
Roadmap
*
Image
from
Dean
Leffingwell’s
blog
-‐
hTp://scalingso:wareagility.wordpress.com/
Un
evento
de
34
Monday, January 9, 2012
38. “As
in
Nature,
if
an
organizaJon
is
too
inflexible
or
stands
sJll
too
long
it
will
get
eaten.”
-‐
James
Burke
(author
and
historian)
PLATFORM
EXPERIENCE
DEBT
Un
evento
de
35
Monday, January 9, 2012
39. Rather
than
crea=ng
teams
to
work
on
projects,
let’s
find
ways
to
give
projects
to
cross-‐func<onal
teams.
Un
evento
de
36
Monday, January 9, 2012
40. Component
Team
ConfiguraGon
• “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
37
Monday, January 9, 2012
41. Feature
Team
ConfiguraGon
• “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
38
Monday, January 9, 2012
42. “What
he
needs
is
some
way
to
pay
back.
Not
some
way
to
borrow
more.”
-‐-‐
Will
Rogers
THE
“NO
DEFECT”
MINDSET
Un
evento
de
39
Monday, January 9, 2012
43. Case
Study:
Field
Support
ApplicaGon
• 2000+
users
access
applicaGon
each
day
• ApplicaGon
supports
mulGple
perspecGves
and
workflows
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
40
Monday, January 9, 2012
44. 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
41
Monday, January 9, 2012