1. Transitioning from working
software to quality software
a.k.a. caring instead of peonage

2. What is peonage?
Constantly growing technical debt in the name of business
needs. This results in a code base that makes it more
expensive to respond to changes over time. More and more
programmers are hired to keep control of the evolving code
base. This leads to Defect-Driven Development, where
developers keep introducing more defects while trying to fix
them. The code is constantly monitored and hacked while
trying to converge to it's original intention.

3. What is Technical Debt?
Ward Cunningham first drew the comparison between
technical complexity and debt in a 1992 experience report:
Shipping first time code is like going into debt. A little
debt speeds development so long as it is paid back
promptly with a rewrite... The danger occurs when the
debt is not repaid. Every minute spent on not-quite-right
code counts as interest on that debt. Entire engineering
organizations can be brought to a stand-still under the
debt load of an unconsolidated implementation, object-
oriented or otherwise.

4. What generates Technical Debt?
Pressure Lack of skills Lack of information
• "If we don't get this • Defining concrete • Unclear definition of
release done on time, goals. done.
• Creating Clean Code. • Insufficient business
there won't be a next
knowledge.
release"
• "We don't have time to
implement this the right
way; just hack it in and
we'll fix it after we ship."
• Expectation of
increasing velocity.

5. What is caring?
Constantly monitoring metrics that indicate the health
of the code base and responding to the changes in
the trends.
What do you get in return?
As a developer As a business owner As a customer
• Fearless code modification. • Constant overview of the • Working software.
• Fearless code commit. evolution of your product. • Significantly less bugs.
• Fearless release. • Ability to know the current
• Won't need to apologize state of development without
when showing your code to any human interactions.
others. • Confidence in your product.
• Self-confidence. • Trust in your team.
• Fast and constant feedback
about your work.

6. Metrics regarding code health
Exact measurements, straight-forward meanings:
1. Number of coding standard violations.
2. Number of duplicated code.
3. Amount of dead code.
4. Amount of code covered by (automated) tests.
Complex measurements and meanings:
1. Number of open tasks. (todo, etc. in code)
2. Amount of overly complicated expressions.
3. Relationship between packages and objects
(modularity).

7. What do these trends generally indicate*?
Constant low (~0) Constant high Lowering Growing
• Change is welcomed. • Lack of morale or • The development • Change in
• The code is stable. discipline. team wants to take circumstances that
• Fixing bugs is fast and • A fix of a bug control over the caused low morale
cheap. usually is hard code. or discipline.
and expensive. • Change will be • Too much pressure
• High probability of cheaper and less on the
introducing one or time-consuming. programmers.
more defects • Transition to a • Growing technical
while fixing one. higher level of debt.
• Change is hard software • Software becoming
and expensive. development and unstable.
demanding.
* assuming the engineers have the knowledge to realize the problems.

8. Measuring coding standard violations
Normally every coding
society has a standard that
they try to stick to. It usually
helps co-workers in
understanding each-other's
code and preventing bugs.

9. Measuring coding standard violations
What does the trend mean?
Constant low (~0) Growing
• Internal API-s are well documented, • Insane standard requirements.
reusability is easy.
• Programmers do a good job keeping
their artifact clean.
• Code is anytime easily readable and
presentable to anyone.

10. Measuring coding standard violations
What does it take to utilize the metric?
• A company-wide standard that all members
know about. (Requires constant training)
• The standard written in the form that an
automated tool can understand.
• An automated tool that can evaluate the code-
base and report violations.
• Continuous maintenance of the standard and
the tool.
• People caring about the trend!

11. Measuring duplicated code
What impact does duplicated code have?
"Code duplication harms the uniqueness of entities within a system.
For example, a class that offers a certain functionality should be
solely responsible for that functionality. If duplication appears, it
becomes much harder to locate errors because the assumption “only
class X implements this, therefore the error can be found there” does
not hold anymore. Thus, the presence of code duplication has (at
least) a double negative impact on the quality of a system: (1) the
bloating of the system and (2) the co-evolution of clones (the clones do
not all evolve the same way) which also implies the cloning of errors."
Michele Lanza, Radu Marinescu, Stéphane Ducasse - Object-oriented metrics in practice.

12. Measuring duplicated code
What does the trend mean?
Constant low (~0) Growing Constant high
• Optimal, clean code. • Fear of code • Bug fixes are
• Bug fixes are cheap and modification. expensive, time-
fast. consuming and error
prone.

13. Measuring duplicated code
What does it take to utilize the metric?
• A company-wide policy about the maximum
(lines/tokens) tolerated to be identical.
• Developer skill to avoid duplication.
• An automated evaluation and reporting tool.
• People caring about the trend!

14. Measuring dead code
What is dead code?
The dead code metrics measure the amount of dead or
inoperative code in the source.
Dead code means unnecessary, inoperative code that
can be removed. Being dead means that the element is
not used and you can remove it without affecting the
functionality of the program.

15. Measuring dead code
What does the trend mean?
Constant low (~0) Growing Constant high
• The code is commonly • There's no trigger • Too complex code
understood and the for at least one base.
responsibilities of objects is feature.
clear to everyone.

16. Measuring dead code
What does it take to utilize the metric?
• Full end-to-end tests with code-coverage logs.
• Regression tests to verify code removal has not broken
functionality.
• Developer confidence in removing code.
• People caring about the trend!

17. Measuring code covered by (automated) tests.
What is code coverage?
An analysis method that determines which
parts of the software have been executed
(covered) by the test case suite and which
parts have not been executed and therefore
may require additional attention.

18. Measuring code covered by
(automated) tests. What does the trend mean?
Code-coverage has the only trend where the higher is better.
G
Constant low (~0) Constant high
r
o
w
i
n
g
• • Fearless code commit.
T
Modification of the code is expensive,
h
e
r
e
'
s
•
n
o
t
r
i
g
g
time-consuming and error-prone.
e
r
f
o
r
a
t
l
e
a
s
t
o
n
e
f
e
a
t
u
r
e
.
Although 100% code coverage may appear like a best possible effort, even 100% code
coverage is estimated to only expose about half the faults in a system. Low code coverage
indicates inadequate testing, but high code coverage guarantees nothing.
When you focus more and more on making the coverage numbers
better, your motivation shifts away from finding bugs.

19. Measuring code covered by
(automated) tests.
What does it take to utilize the metric?
• A testing environment identical to the production
environment, but decoupled from it.
• Automated end-to-end, integration and unit tests with code-
coverage logs.
• Developer skill: creating all kinds of automated tests.
• Product skill: writing acceptance criteria for stories.
• QA skill: helping Product and Developer with efficient testing.
• Visualization of the log.
• People caring about the trend!

20. Number of open tasks
What is it? Occurrence of comments or
annotations in the source code
that indicate an unfinished
Marked tasks are
identified as possible
engineering task, suboptimal or
sources of technical hard-to-read code, or other kinds
debt. of technical debt.
• todo • review
Can occur in comment • fixme • refactor
blocks, having @ //, etc. • xxx • wtf
prefixes. • hack • omg

21. Number of open tasks
What does the trend mean?
Constant low (~0) Lowering
• Programmers have the opportunity • The development team is paying
to always do their best. back technical debt.
• No identified source of technical
debt.
• Well maintained code.
Annotations can be grouped by
importance. Critical, normal and
low priority can be distinguished.
If such categories exist, a more
precise trend can be drawn.

22. Number of open tasks
What does it take to utilize the metric?
• Automated task scanner and reporting tool.
• Company-wide policy for task annotations and their
categories.
• Developer confidence in completing these tasks.
• People caring about the trend!

23. Amount of overly complicated
expressions.
Code complexity can be defined as a metric which is directly
proportional to the amount of effort required to understand the
code and modify it correctly.
Code complexity metrics are directly related to the
maintainability and testability of the code. The more complex
a code is, the less maintainable and testable it is.
If the code is object oriented, the complexity metrics also
have a direct bearing on the extensibility and modularity of the
code.

24. Amount of overly complicated
expressions.
What does the trend mean?
Constant low (~0) Growing Constant high
• Optimal, well structured • Unclear business • Untestable,
code. logic. unreadable, hard to
• Lack of refactoring maintain code base.
skills. • Generates fear of
change.
• Not optimal code.

25. Amount of overly complicated
expressions.
What does it take to utilize the metric?
• Automated measurement and reporting tool.
• Company-wide policy for value limits.
• Developer skill to eliminate valuations.
• People caring about the trend!

26. Measuring modularity
"Modularity is a general systems concept, typically
defined as a continuum describing the degree to
which a system’s components may be separated and
recombined. It refers to both the tightness of coupling
between components, and the degree to which the
“rules” of the system architecture enable (or prohibit)
the mixing and matching of components."
Wikipedia

27. Measuring modularity
A tightly coupled application
operates with concrete
implementations where the
slightest modification to one of
the collaborators can cause big
impacts to the others.

28. Measuring modularity
A loosely coupled
architecture relies on
interfaces.
(Output, Database, NoSql)
Swapping one implementation to
another causes no impact on any
other collaborator!

29. Measuring modularity
Designs are more extensible
when they are independent of
implementation details, allowing
them to adapt to new
implementations without internal
modification or breaking their
existing contracts.
The maintainability of a design is improved when changes
can easily be made without propagating to other parts of the
system.

30. Measuring modularity
What does it take to utilize the measurements?
• Packages.
• Automated measurement and reporting tool.
• Developer skill to introduce abstraction.
• People caring about the trend!

31. Broken Window Syndrome
If a window in a
building is broken and
left unrepaired all the
rest of the windows
will soon be
broken. . .

32. Broken Window Syndrome
One unrepaired If disorder goes unchecked, a vicious
window is a signal cycle begins. First, it kindles a fear of
that no one cares, crime among residents, who respond by
so breaking more staying behind locked doors. Their
windows costs involvement in the neighborhood
nothing. . . . declines…they cease to exercise social
regulation over little things like litter on
the street, loitering strangers, or truant
schoolchildren. When law-abiding eyes
stop watching the streets, the social
order breaks down and criminals move
in.

33. Broken Window Syndrome
Understanding that such a vicious cycle exists is important in
creating a higher level of discipline and ownership in your
current projects. Teams who are not vigilant about
immediately fixing broken unit tests or builds, are in a sense,
creating a downward spiral within the project. Team
members who witness a single blatant act of project
vandalism will undoubtedly give into the lazy human nature
and retaliate with the common quote, “Well if he isn’t going
to do that, than neither am I…”. The spiral begins…
http://www.codesqueeze.com/

34. "You can't improve what you don't measure."
When do you start improving?