Avoiding Software Insanity - Flash (Medium) - 20111012 09.38.06AM
X
Avoiding Software Insanity
Code Quality? Nice to have, but we can address that later…
Poll Results from NEJUG, February 2011
Part I: Well Known Symptoms of Complexity
Erosion of Architecture – Symptoms (Robert C. Martin)
Erosion of Architecture – Reasons
Cost of Structural Erosion / Technical Debt
Part II: Technical Quality
What is Technical Quality
How to Measure Technical Quality
How to model Architecture
00:00
/
00:00
CC
18:15©
2005-2011,
hello2morrow1Alexander
v.
Zitzewitzhello2morrow
Inc.
Does
that
sound
familiar?Interactive
poll:Do
you
have
binding
rules
for
code
quality?
Is
your
architecture
defined
in
a
formal
way?
Do
you
measure
quality
rule
violations
on
a
daily
base?
Do
you
measure
architecture
violations
on
a
daily
base?Does
quality
management
happen
at
the
end
of
development?
Do
you
think,
that
more
needs
to
be
done
in
that
area
and
that
this
would
be
beneficial
for
the
team
and
the
company?10/11/11©
2005-2011,
hello2morrow2
Do
you
have
binding
rules
for
code
quality?
40%Is
your
architecture
defined
in
a
formal
way?
10%Do
you
measure
quality
rule
violations
on
a
daily
base?
10%Do
you
measure
architecture
violations
on
a
daily
base?
1
personDoes
quality
management
happen
at
the
end
of
development?
40%Do
you
think,
that
more
needs
to
be
done
in
that
area
and
that
this
would
be
beneficial
for
the
team
and
the
company?
99%10/11/11©
2005-2011,
hello2morrow3
18:37©
2005-2011,
hello2morrow4
18:38©
2005-2011,
hello2morrow5Rigidity
–
The
system
is
hard
to
change
because
every
change
forces
many
other
changes.Fragility
–
Changes
cause
the
system
to
break
in
conceptually
unrelated
places.Immobility
–
It's
hard
to
disentangle
the
system
into
reusable
components.Viscosity
–
Doing
things
right
is
harder
than
doing
things
wrong.Opacity
–
It
is
hard
to
read
and
understand.
It
does
not
express
its
intent
well.Overall:
“The
software
starts
to
rot
like
a
bad
piece
of
meat”
18:38©
2005-2011,
hello2morrow6System
knowledge
and
skills
are
not
evenly
distributedComplexity
grows
faster
than
system
sizeUnwanted
dependencies
are
created
without
being
noticedCoupling
and
complexity
are
growing
quickly.
When
you
realize
it,
it
is
often
too
lateMost
projects
don’t
measure
quality
on
a
regular
baseManagement
considers
software
as
a
black
boxQuality
measurement
is
done
at
the
end
of
developmentTime
pressure
is
always
a
good
excuse
to
sacrifice
structureThe
Law
of
Entropy?
18:41©
2005-2011,
hello2morrow7
10/11/11©
2005-2011,
hello2morrow8
“Technical
quality
of
software
can
be
defined
as
the
level
of
conformance
of
a
software
system
to
a
set
a
set
of
rules
and
guidelines
derived
from
common
sense
and
best
practices.
Those
rules
should
cover
software
architecture,
programming
in
general,
testing
and
coding
style.”Technical
quality
affects:TestabilityExpandabilityMaintainabilityComprehensibilityIt
cannot
be
achieved
by
testing
onlyTechnical
quality
has
the
following
aspectsArchitecture
and
dependency
structure
of
the
codeSoftware
metricsCommon
sense
coding
rulesTest
coverage10/11/11©
2005-2011,
hello2morrow9
ArchitectureMeasure
number
of
dependencies
violating
architecture
rulesStructureMeasure
size
and
coupling
of
package
cycle
groups
in
relation
to
the
size
of
the
systemMetricsDefine
a
reasonably
(small)
number
of
metric
thresholds
and
measure
the
number
of
threshold
violationsCoding
rulesUse
automated
rule
checkers
and
configure
a
reasonable
set
of
guidelines
and
rules.
Measure
number
of
rule
violationsTest
CoverageRun
your
unit
tests
with
a
coverage
tool
to
measure
the
test
coverage.
Focus
efforts
to
improve
coverage
on
complex
code10/11/11©
2005-2011,
hello2morrow10
18:59©
2005-2011,
hello2morrow11
.