FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT

Technical Debt and

Software Craftsmanship eMag Issue 27 - April 2015

ARTICLE INTERVIEW ARTICLE

Creating a Culture James Grenning on Managing

of Quality Technical Excellence Technical Debt
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 1
Bad Code, Craftsmanship,
Engineering & Certification
Robert C. Martin, during his keynote at QCon London 2010,
tried to figure out why there is so much bad code written. He
offers advice on writing good code talking about a bad code
example, Boy Scout rule, functions, arguments, craftsmanship,
TDD, continuous integration, pairing, small cycles, patterns,
engineering, certification, and other elements contributing to
quality code.
Creating a Culture of Quality
Every company wants to delight customers with a high-
quality product, and many organizations naturally focus
on process improvements to reach quality goals. But
organizational culture eats process for breakfast. So how
do you create a culture of quality? New research on 850
employees who impact quality from 80 companies presents
new strategies for shifting values, norms, beliefs, and habits.

Michael Feathers on
Technical Debt, Process,
and Culture
Michael Feathers offers advice on creating an
organizational process and culture that can enhance
software development in a way that reduces technical
debt.

Managing
Technical Debt
Technical Debt is widely regarded as a bad
thing that should be paid back as soon as
possible, however it can be a strategy that
helps balance short-term wins and long-
term productivity. This article describes
different ways that a project could pay
back Technical Debt and what factors must
be considered when deciding if you should
repay, convert debt or just pay the interest.

Technical Debt: James Grenning on

A Repayment Plan
All teams eventually face technical debt. In this article Jeremy
presents what technical debt is...and isnt, as well as introducing
some of the different types of technical debt and how to deal with
them. Finally, he presents a metaphor for understanding technical
debt, explaining it to stakeholders, and then dealing with it in an
efficient way.
Technical Excellence
At the recent Agile Singapore conference James Greening
presented two technically focused talks - one on the
importance of technical excellence and the other teaching
test driven development. He spoke to InfoQ about the
importance of strong technical practices to enable true
agility in software development.

FOLLOW US CONTACT US
GENERAL FEEDBACK feedback@infoq.com

ADVERTISING sales@infoq.com

EDITORIAL editors@infoq.com
facebook.com @InfoQ google.com linkedin.com
/InfoQ /+InfoQ company/infoq
 NEW YORK
Jun 8-12, 2015
Conference for Professional Software Developers
qconnewyork.com
SAVE $100 WHEN YOU REGISTER WITH PROMO CODE TECHDEBT
Tracks for QCon NY 2015
Applied Data Science and Machine Learn-
ing - Putting your data to use. The latest pro-
duction methods for deriving novel insights
Engineering Culture - Building and scaling a
compelling engineering culture
Modern Advances in Java Technology - Tips,
techniques and technologies at the cutting
edge of modern Java
Monoliths to Microservices - How to evolve
beyond a monolithic system -- successful mi-
gration and implementation stories
The Art of Software Design - Software Arch
as a craft, scenario based examples and gen-
eral guidance
Architecting for Failure - War stories and les-
sons learned from building highly robust and
resilient systems
Emerging Technologies in Front-end De-
velopment - The state of the art in client-side
web development
Fraud Detection and Hack Prevention -
Businesses are built around trust in systems
and data. Securing systems and fighting fraud
throughout the data in them.
High Performance Streaming Data - Scal-
able architectures and high-performance
frameworks for immediate data over per-
sistent connections
Reactive Architecture Tactics - The how
of the Reactive movement: Release It! tech-
niques, Rx, Failure Concepts, Throughput,
Availability
Architectures Youve Always Wondered
about - Learn from the architectures power-
ing some of the most popular applications
and sites
Continuously Deploying Containers in Pro-
duction - Production ready patterns for grow-
ing containerization in your environment
Mobile and IoT at Scale - Trends and technol-
ogies for building mobile applications
Modern Computer Science in the Real
World - How modern CS tackles problems in
the real world
Optimizing Yourself - Maximizing your im-
pact as an engineer, as a leader, and as a per-
son
 SHANE is an agile coach, trainer and consultant working for SoftEd in Australia,
New Zealand and around the world. He is the lead editor for Process
HASTIE and Practice on InfoQ.com and blogs on the SoftEd blog.
A LETTER FROM
THE EDITOR
Technical debt is a hackneyed phrase that refers
to the likely cost of maintaining and enhancing a
software product. To many, the existence of technical
debt is a curse and indicates a lack of professionalism
or craftsmanship in the code whereas others find it
a natural by-product of the many different trade-offs
that have to be made when delivering solutions to
meet market and organisational needs. Whatever
way you view it, technical debt is something that will
most probably impact every codebase at some point.
This e-mag brings together a number of authors who
have addressed the topic on InfoQ and suggests ways
to identify, monetize, and tackle technical debt in
your products.
We start with a prcis of Robert Uncle Bob
Martins 2010 QCon keynote in which he presented
a clear picture of what bad code is and how code
rot happens, gave sound advice on how to avoid
it, and discussed important aspects of software
craftsmanship. He emphasizes the importance of
code quality as a means to speed development: The
only way to really go fast is to go as well as you possibly
can.
Jonathan Levene has written about how to
create a culture of quality. He asks why so many
quality initiatives do not succeed and presents his
thoughts on creating a pervasive quality culture
that will allow true craftsmanship to emerge and
flourish. He identifies effective leadership, credibility
of the message, peer involvement, and ownership
and empowerment of team members as elements
4 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
necessary for a quality culture to flourish. The quality
of the product is a manifestation of the quality of the
process that was used to create it, he writes.
Building on the culture theme, Michael
Featherss 2012 IEEE Software Experts Summit talk
examined the different types of technical debt. He
argues that not all technical debt is bad but it is
unavoidable and we need to plan and budget to
address it so it doesnt inhibit new value. He identifies
a variety of factors that contribute to technical debt
and places where it is likely to accumulate in a
codebase and presents some advice on how to deal
with them. According to Feathers, technical debt is
the effect of unavoidable growth and remnants of
inertia inside software systems.
Sven Johann and Eberhard Wolff present
some ideas about managing technical debt. They
challenge the idea that technical debt should always
be paid back as quickly as possible and present
the case for consciously selecting which areas
and types of technical debt are worth addressing
and which can be left to chance. They discuss the
surprising variety of stakeholders who have interest
in technical debt and what those interests are. They
discuss some ways to select the areas to address and
different approaches to addressing the accumulated
debt. They conclude that messy code, which is rarely
read or touched and doesnt implement important
requirements, does not have to be absolutely perfect
and therefore we dont need to spend a lot of effort
on refactoring it into great code.
Jeremy Jarrell presents his thoughts in
Technical Debt: A Repayment Plan. He discusses
the types of debt and the importance of putting
aside some of the teams budget for addressing both
bit rot and consciously incurred technical debt. He
suggests how to identify the necessary budget and
where and when to spend it: Like financial debt,
when taking on technical debt, we need to establish
how and when it will be repaid.
Finally, in an interview from Agile
Singapore2014, James Grenning reminded us what
technical excellence actually means, why it is so
important that strong technical practices become
the norm, and the value of constantly learning about
our craft as well as the product under development.
He calls test-driven development one of the
important techniques to use to prevent bit rot and
maintain a high-quality codebase. Most people are
doing the best that they know but they dont know
what they dont know, he cautions.
 READ ONLINE ON InfoQ

Bad Code, Craftsmanship, Engineering &

Certification

Robert C. Martin (Uncle Bob) has been a software professional since 1970 and an international
software consultant since 1990. He is founder and president of Object Mentor Inc., a team of
experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO,
Patterns, UML, Agile Methodologies, and Extreme Programming.

In his keynote at QCon London 2010, Robert C. Martin tried to figure out why
developers write so much bad code.

He opened his talk with an example of truly bad code:
two classes from a product that were massive and
had very large methods. He described the nature of
the code and then asked how many in the audience
have been significantly impeded by bad code.
Almost everyone in the audience responded
that bad code had impeded work. Martin challenged
them:
Why did you write it? You know, of course, that it is
going to impede you. You know, of course, that this
code will slow you down. What in the world would
motivate you to do the thing that you know it is going
to significantly impede you and everyone else on your
team? Why in the world would someone write that
code?
He presented some potential excuses for why
bad code could be written:
Is it the pressure of time schedules that makes us do the
thing that slows us down? I will leave you to deal with
the oxymoronic consequences of that one. We must
make a mess because (it is) the only way for us to go
fast. So, we accept the fact that it will slow us down
forever so that we can make a mess today and save 5
milliseconds. Obviously, that is probably not the right
trade-off to make. Is it just sheer laziness? I do not
think that the developers who wrote that thing were
lazy. You have got to work hard on a mess like that.
It takes real effort to keep that thing in such horrible
situation. Maybe it was boredom, maybe these guys
just did not care anymore, maybe they were just going
in every single day and slinging code and collecting
their paycheck and going home saying Who the hell
cares? Maybe that was it. I do not know. Or maybe
they were benefiting themselves: Try to fire us. See if

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 5

anybody else can deal with this pile of crap that we
have created. Ha ha ha!Martin explained his view of
the essence of the software-craftsmanship movement:
the only way to really go fast is to go as well as you
possibly can.
He admired the Boy Scout practice of leaving a
campground cleaner than when you found it.
When you spend some time at a campground and then
you leave it, clean it up. Do a little bit more than just
cleaning it up: improve it slightly.
He indicated what would happen if we did the
same with our code:
If we all did that with our code, our code will get
incrementally better all the time. Every time we check
a module out to do whatever we had to do with that
module, we could clean it up a little bit and make
sure that it was as clean or cleaner than it was when
we checked it out. We could take a moment to do
one random act of kindness to the code: improve one
variable name or shorten one method, and then check
it in just a little bit better than it was when we checked
it out. And if we all did that, the codebase everywhere
would just gradually improve.He discussed some of
the characteristics of the bad code he had shown at the
start.
He asked how large a function should be and
concluded it should take up one screen or less,
meaning 20 lines at most and ideally only four or
five lines long. He discussed the extract method
of refactoring (which many editors can do) and
suggested a rule for using it:
My rule for keeping a function short is to extract
methods until you cannot extract methods anymore. I
call this extract till you drop. You take every function
that you used and you start extracting and extracting
and continue to extract until you cannot extract
anymore. By doing so, you are creating functions
that literally do one thing. (There is only) one possible
concept in that function, one level of abstraction in
that function. Every function is tiny. Every function
calls other functions that have names.
He explained how a large function is navigable
by someone who has worked with it for a long time as
they are able to recognize the shape of the features
and can use the landmarks to help them navigate
through it. Someone without that experience with
the code will be lost, as the landmarks mean nothing
to them. Extracting the methods creates a map and
puts the elements into well-named places:
We chose our names carefully so that other people can
go through this code and say, What in the world does
this code do? It is four lines long and the name of the
function is delete_all_rows(). Oh, I think I know what
this does. When your functions name tells you what
the next four lines do, you can pretty well work out
6 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
what the code is doing. So, I like my functions to be
short.
Martin said the best number of arguments
a function should have is none: It is very easy to
understand the arguments of a function when a
function takes no arguments.
The next best number of arguments is one,
which is also easy to understand: pass one argument
in, get one value out. As for more than one argument:
Two is not too bad. Humans are not bad at juggling
two things. They can keep two things in order. Usually,
we have conventions for this, like X and Y we all
know that X comes first and Y comes second.
Three starts to become a problem because when
you have three arguments, there are three different
ways to arrange them. What order do they come in?
How many of you have seen a function that has three
arguments? It ought to be pretty obvious, but its not
if you spend hours looking at it only to eventually find
that two of the arguments have been flipped.
He discussed using Boolean values as
arguments:
Do not pass Booleans into functions. I will find
you. Booleans into functions are the worst possible
abomination. When you pass a Boolean into a
function, you are loudly declaring to the entire world
that this function does two things: one in the true
case, one in the false case. Why did you not make two
functions? Have the caller call the right one. Do not
pass Booleans into functions and do not ever pass two
Booleans into a function.
Martin discussed naming conventions and
how the length of a name should be inversely
proportional to its scope:
There is a rule that I like to follow. The length of a
name is inversely proportional to its scope. Long
scopes, short names short scopes, long names. Say I
have a class with some public function. Those public
functions have a long scope so I want their names
to be short. An example of that is class file, public
method, open for characters that is good. Open the
file! But deep down inside the class, there would be
private methods and those private methods, especially
if you are extracting until you drop, will have longer
and longer names so that they can be more and more
precise about what they are doing. The worst you can
possibly have is a private method named G. No one
is going to know what that means, right? We want to
have private-method names that have nicely spelled
out functions. And you know what is nice about that?
Hardly anyone calls those private methods. It is not
like a million people are going to call the private
method. The private method only gets called by a few
methods so it is harmless to have really long names
that specify what those private functions do.
 He discussed the ideal size for a class:
Well, it is hard to say a class should be four lines. It
would be an interesting class that was four lines. We
need more than four lines in a class. We probably need
a hundred or maybe two hundred. A class is going to
be bigger than a function. And how many variables
should a class have? Six? Eight, maybe? Two is good.
I like two.
We do not want to see lots of functions in a class.
How many? Well, a few dozen. It would be okay to
have 12 or 24 functions in a class, but I do not want
to see 700 functions in a class. I do not want to see
100 functions in a class. A class should be a short,
little batch of code, something nice to organize a few
concepts that we put into a nice namespace with a nice
name.
He encouraged the audience to think about
their actions when writing code:
It would help us in our writing of code if we (think)
Uh, this class is a little too big. This function is a little
too large. That name is a little too strange. It would
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
help us if we thought about that and then gradually
refactored it, according to the Boy Scout rule. Every
once in a while, we come around and say, That
function is a little too long. Lets split it apart. That
class is a little too big. Lets make two classes out of it.
That way, we are always improving.
Another element Martin discussed is getting rid
of all duplication:
Of course, the final, horrible scene in any piece of
code is duplication. We want to get rid of as much
duplication as possible. How many of you have seen
code that looks like somebody got nuts with the mouse:
scrape, paste, paste, paste, paste, paste. Oh, that piece
of code is really good! I think I will use it here and here
and here and here.
The problem with that is that when you have to
change it in one place, you have to change it in many
places, and if there was a bug in it when you copied
it, you just replicated that bug throughout the whole
batch of code. We dont want to see replicated code
at all. Any time there is duplication in the code, we
7
want that duplication eliminated through the use of
something called abstraction something that we
are supposed to be good at, something that we are
supposed to be masters of in our particular trade. We
use abstraction to eliminate duplication.
Martin addressed the topic of craftsmanship
and showed the audience the Manifesto for
Software Craftsmanship (http://manifesto.
softwarecraftsmanship.org/).
He discussed how the Agile Manifesto
(agilemanifesto.org) influenced the Manifesto for
Software Craftsmanship and how the latter takes the
outcomes of the Agile Manifesto and extends them
with the ideals of craftsmanship.
He said that the idea of craftsmanship is based
on the need for disciplines that entered the field
starting around 1995. The first of these is test-driven
development:
Nowadays, we have a set of disciplines that help us
write code. And, of course, the one that I like the best
is test-driven development. Test-driven development
is one of those practices that started out remarkably
controversial, but the jury is in. It is no longer a big
controversy. Some people still argue it, but it is no
longer a big controversy. Test-driven development
works! It works very, very well. It is a powerful
discipline that helps to organize your code, to organize
your tests, to organize your time. It helps you with
your design. It helps you with everything else that you
do in software.
He challenged the audience regarding code
coverage in unit tests:
If you do not have coverage over it, if you cant test
it and, by the way, manual testing does not count,
because humans do not test things well. If you do not
have automated test coverage over your code, you do
not know if it works. How can you, as a professional,
ship code that you are not certain works?... How can
I claim to be a professional and not know that my
code works? The way to be sure is through test-driven
development.
He discussed other benefits derived from test-
driven development such as the courage to make
changes to the code:
If you have a suite of tests that you can run, and if you
trust those tests, then you can make the change. It is
a little hard, but you go in and make a small change
and you run the tests and all the tests pass and you
say, I did not break it! You make another small
improvement, you run the test, and you say, The test
passed. I did not break it! And as you learn to trust
those tests, you realize that you can change the code.
He spoke about the importance of good design
and architecture how we want software to be well
structured and maintainable, able to survive for a
8 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
long time, and how test-driven development helps
achieve this:
Nothing makes a software system more flexible that a
suite of tests. Nothing! By a huge order of magnitude.
You can have a terrible design but if you have a suite
of tests, you are not afraid to improve the design. But
if you have a terrific design, you are afraid to touch it
if you do not have tests. It is very difficult to improve
or change code that does not have tests. It is very, very
easy to modify and improve code if you do have tests.
He discussed the value of continuous
integration and the importance of build failures:
When we have a test failure in the build, we need to
look at that as a critical event. Something has gone
terribly wrong because something that used to work
no longer works. So, we have to get on that fast. And
we should stop making progress everywhere and focus
our efforts on getting that thing to pass in a matter of
an hour or so and then everybody can relax and the
build is back again. I want a little siren going Oh my
God! Something is broken!
He explained the danger of tolerating a broken
test in the build:
If you tolerate a broken test in the build, if you say to
yourself, Well, I will go back and fix that later, the
next thing that you are going to do is to take that test
out of the build because it turns the build red and that
is ugly. So, you pat yourself on the back and you
take it out of the build. Now, the build is green. Now
this is a behavior that you can repeat many times to
keep the build green and everyone is happy because
the build is green.
Of course, what you are doing is destroying the
test. Then, at the release, somebody remembers finally,
Oh, there are 18 tests we forgot to fix. And then you
got a mess on your hands. Always keep the build
passing by fixing any build errors immediately.
He advised taking a quality-first perspective to
checking in code and ensuring the build does not
get broken:
No developer should check in code until they are
certain that it passes the build. So you should run a
private build before you have finished committing
your check-ins. You made a change; you should be
able to run a private build on your machine.
Martin challenged the argument that it takes a
long time to run a suite of tests and indicated that it is
a symptom of dismissing the real value of tests. They
should be treated in the same way as production
code:
If your test suite is so long that it takes hours to run,
something is wrong somewhere. It means that you
have been lazy with your tests; it means that you
have allowed your test to take a long time. This is not
uncommon. When they are writing tests, people think
that tests are somehow different from production code,
that they should follow a different set of standards
than the production code does. We like our production
code to be fast, we like it to be efficient, but we look
at our tests and think, Well, who cares about them?
No, we do care about them. We want our tests held to
the same standard as our production code. If our tests
are slow, it is because our tests are poorly designed. If
our tests are rickety, if they break a lot, if you have the
fragile-test problem, you have not designed your tests
well. You cannot look at test as some kind of second-
class citizen. They are, for all intents and purposes,
equivalent to production code in the level that you
must maintain them.
Next he discussed pair programming as a
technique of craftsmanship. He does not encourage
100% pairing:
I think there are tasks that you ought to be able to
work on your own for. You are writing for a bunch of
error messages there is really no point in pairing.
Sometimes you cant pair; sometimes you have to
think really hard and long on something. Usually, that
means you are doing something wrong, but sometimes
you have to do it that way. All right, fine! So I am not
going to tell you that you have to pair all the time.
He does encourage a lot of time in pairing:
I think people ought to pair as much as they feel
comfortable with and that ought to be in the order
of 50% to 70% of the time. You should be working
together, as a team. The worst possible situation for
a development team is for all the developers to sit in
their cubicles, facing their terminals with headphones
on and not interacting with each other.
If you are going to have a team, that team needs
to be working together, looking at each other, talking
to each other all of the time. So, a fair bit of pairing, I
think, is very important.
He said that QA should find no bugs, and the
lack of bugs produces pride in workmanship:
We do not want to treat QA as this group that sweeps
all the bugs back into development. We want to look
at QA as the people we are going to impress. They are
going to find nothing. And of course they find things
and we should be shattered when that occurs. Oh, my
goodness! How did that bug get out of development all
the way into QA? QA should find nothing. This should
be our fundamental view of what QA should find. Our
level of standard is so high that QA finds nothing and
that leads to pride of workmanship. Are we proud of
the way we work? This is really what craftsmanship is
all about at an emotional level.
On the topic of convincing others to take up
these ideas, he said:
I have come to the conclusion that there is no way
to convince others, that the best thing you can do is
to do the best job you possibly can and act as a role
model. And no matter what else happens, you will do
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
the best job you possibly can, you will adhere to your
disciplines and, hopefully, other people will observe
that you are massively outperforming them and they
will start to ask why. And they will adopt the things
that you have begun to do.
I think that, in the end, if we all just buckle down
and we do what we know we are supposed to do, write
the best code we possibly can, write the tests we know
we are supposed to write, then, gradually, everything
else will change. Other people will join because they
see it is a better approach.
He challenged the need to convince
management to allow teams to work in this way.
Management wants quality work and should support
methods that get teams there:
Management does not need convincing. Go ask a
manager, Sir, what would you like? Good code or
crap?
I guarantee you will get an answer that is not
crap. They are just not going to say, Oh, well, we want
crap. They are not going to do that.
From that point on, you can say, You want good
code? Well, then I must work in a way that provides
you good code. Thank you. Nothing else is necessary.
You do not have to ask for permission to write tests
because they want good code: Then I am going to
have to write tests in order to give you good code.
You do not have to ask permission to pair because you
cannot give good code unless you are pairing: So I
will pair. I am going to do all the things necessary to
give you good code.
Management does not need convincing that they
want quality.
The area where management does need
convincing is in understanding that development
teams are not children, which we do by showing
them that we are worthy of their trust:
Management sometimes treats us like we are children
because, frankly, in the past, we have acted like
children. Our room has been messy and the managers
had to come into the room and clean it up too many
times. Now, maybe, we can begin to act more like
adults.
He discussed the importance of small cycles
and feedback loops in iterations one to two weeks
long:
I like one week one week is a nice size. Not a lot of
bad stuff can happen in a week. In two weeks, more
bad stuff can happen. When you close that feedback
loop is when you have to deal with the bad stuff. We
have learned in our industry that working in short
cycles is better than having long development phases.
Something else that we have learned is that
we can also work in extremely short cycles if we are
practicing test-driven development, because if you are
doing test-driven development, you are going around
9
the test/code/test/code loop once every 30 seconds
or maybe once a minute or so. So, you are getting
feedback all the time. We have learned in the last
decade the importance of very small cycles.
He presented the idea that source code is
the design:
Despite our search for a proper blueprinting
mechanism, despite our search for the
diagramming notation that will solve all software
worries, the real design is in the source code.
There is no design documentation that uses a
diagrammatic notation that is good enough. The
real design of our software lives in the source
code, not in any pretty pictures we might draw.
He ended his talk with a skeptical discussion
of certification. He stated that certification over-
promises and under-delivers in our industry:
Consider what the certification schemes out there
right now have to offer. Come to our course for
four days and we will give you a certificate. What
does that certificate mean? It means that you paid
for a course for four days. Does it mean that you
actually attended the course? It is not clear, but
you did at least pay to attend the course. Maybe
there is some test at the end. It does not really
help anybody that you have this piece of paper....
I think the only people who benefit from it are
the certification bodies, the people collecting the
fees. I do not think the rest of us benefit from a
certification.
He contends that certification does not
help employers select good people and a
certificate does not tell them that:
How do we determine who to hire? Well, I have a
revolutionary idea about this and it is something
that, I dont know, maybe I can bounce it off you.
Maybe, just maybe, when you are thinking about
hiring someone, you should talk to them. Maybe
for an hour. Maybe you should have several
people at your company talk to them. Maybe you
should have them write a little code for you to see
what kind of code they might write. This is not a
guarantee of much, but at least it is something.
Maybe you should have them give you the e-mail
addresses and phone numbers of people they have
worked with and this is really radical maybe
you should check those references.
 READ ONLINE ON InfoQ

Creating a Culture of Quality

Jonathan Leveneis a Boston-based executive coach specializing in leadership development

of engineering managers and executives. He is a 14-year veteran of product-development
organizations in small and mid-size companies and has held prior roles in engineering, product
management, sales, marketing, and business development.Jonathan provides engineering
managers and executives with tools and evidence-based training and coaching programs
on leading effective virtual and self-managed teams, influencing leaders in other functions,
and developing technical talent for peak performance. For articles and tools on engineering
leadership, visit his websiteor contact him atjonathan@levenecoaching.com.

Every company wants to delight customers with a high-quality product, and

many engineering organizations naturally focus on process improvements to
reach quality goals. But organizational culture eats strategy and process for
breakfast. So how do you create a culture of quality?
Product quality is one of the areas that engineering of the Martin Trust Center for MIT Entrepreneurship
teams monitor closely throughout the software and a senior lecturer at the MIT Sloan School of
development lifecycle. Most often, a mix of both Management, reminds us, culture eats strategy
external quality measures visible to customers for breakfast and, I argue, process as well. When
such as defects, reliability, or security are tracked organizational culture clashes with the spirit of a
alongside internal quality measures not visible process change such as when a command-and-
to customers such as conformance to a spec, control culture tries to achieve productivity gains
maintainability, efficiency of code, or codebase size. through self-managed, agile teams culture wins
When significant or recurring external/internal quality every time.
improvements are needed, though, engineering Culture manifests itself through an
teams often focus on process improvements as the organizations values, norms, beliefs, and habits and
way to get there. After all, the quality of the product these, in turn, impact product quality by guiding team
is a manifestation of the quality of the process that actions. Im not talking about what an organization
was used to create it, right? says it does, Im talking about what it actually does
Products are manifestations of the culture that - at all levels. To begin with, organizational values
create them, too. As Bill Aulet, managing director typically help prioritize whats most important to

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 11

teams. For example, an organization that highly values
simplicity in design may revert a fix for a defect if it
accidentally adds complexity to the user experience.
The overall quality of a release may be assessed by
the elegance of the implementation of new features
it planned to introduce.
Organizational norms define what is considered
acceptable behavior, typically through an
organizations track record. An example might include
whether past releases required developers to work
extra hours to fix critical defects towards the end of
a release. Without this track record, planning a high-
quality release would require a project manager to
be over-conservative in estimating team productivity
- since a team may not accept putting in the extra
hours to meet a quality commitment.
Organizational beliefs are shared ideas or
principles about the way things should be. These
might include the belief that developers should
have ownership of and accountability for the code
they write so that their code is reflective of their
own diligence and hard work. When major defects
are traced to their code, these developers will feel a
healthy sense of embarrassment from having missed
something and will try to resolve it as quickly as
possible. Contrast this with the behavior resulting
from an organizational belief that every project and
every area of enhanced code will have defects
and that these should be expected. With this belief,
developers will be slower to react when defects are
found in their code.
The last element of culture is organizational
habits, and these guide the regular and often
unspoken tendencies of the companys teams. One
example is the style of making decisions. For some
organizations, decisions require deferring to the most
senior person in the room, while other organizations
will define and use evidence-based criteria that
people at any level can apply to support a decision.
It can be quite instructive to observe how a team
decides whether quality is good enough to release
since this is perhaps the single most-important
decision about quality made during a release.
So how do you drive quality through culture?
In their Harvard Business Review article, Creating
a Culture of Quality, Ashwin Srinivasan and Bryan
Kurey of CEB share the results of their recent research
on this question. They studied over 850 employees
who impact quality in 80 multinationals to find four
factors that drive quality as a cultural value:
1. Leadership emphasis. Managers need to
demonstrate how to walk the walk with respect
to quality, and this must come right from the top.
You can do this if you:
Track quality metrics. Define meaningful
measures of quality that senior leadership,
12 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
product management, QA, and engineering
can all agree to.
Make your metrics visible. Pull them out
frequently in meetings, and review them in
regular check-ins with your team.
Use quality in trade-offs. Create clear
definitions and guidelines for minimum
quality levels, and use them in meetings when
trade-offs need to be made at the end of a
release. When your team sees quality metrics
being used in trade-off decision-making,
theyll know that quality matters.
A special note is warranted here about
introducing or changing metrics in your organization.
As with any change initiative, it is critical to balance
buy-in with mandates to adopt the change. The risk
with metrics is that different teams may begin using
their own variations that emphasize their interests
over those of others. Since the purpose of metrics is
to measure and shift team behavior across the board,
its critical that all stakeholders (senior leadership,
product, QA, and engineering) agree and adhere to a
common set. You can achieve this if you:
Form a cross-functional working group with
purpose. Motivate the need for the metrics by
clearly identifying the current pain points that
exist without them, why action is imperative
now, and how common metrics will help. Invite
influential stakeholders from across senior
leadership, product, QA, and engineering to
design the metrics. Each participant can represent
their teams interests during discussions, as well as
help sell the metrics internally to others. Choose
a good facilitator and be sure to explicitly ask
participants to sell the result to their peers after
the metrics have been designed.
Measure for outcomes that matter. Ask the
working group to begin by identifying the
desired, qualitative product outcomes that
different stakeholders expect. Once these
outcomes have been identified, invite the group
to work backwards to select metrics that measure
movement towards or away from each outcome.
For example, lets say your product is a cloud
application whose computational costs are rising
faster than adoption and senior management
is concerned. The working group might identify
various metrics to measure efficiency, such as
CPU utilization across servers, which can be
tracked during development and testing. Once
the metrics are finalized and in use, show your
teams what impact they are having.
Standardize metrics use across teams. Charge
the working group with creating the templates
and dashboards that all teams will use to view
the metrics. Invite each participant to present
 the results to their respective teams and ensure
these are used consistently. Since all functions
had input into the process, set clear expectations
that these metrics should be used going forward
by everyone.
2. Message credibility. Successful managers
carefully choose the right way to communicate
the quality message based on what resonates with
their teams. This may take some experimentation
to get right. Communicate the perspective of
different internal or external stakeholders about
product quality and see what lights your team up.
Examples might include:
Customer satisfaction. Interview or survey
customers on their overall satisfaction with
the product, and include quotes to bring their
sentiment to life.
Sales experience during demos. As any sales
rep will tell you, having the product crash
during a prospect demo can be very damaging
and awkward for the sales rep. Find out how
sales reps experience the product during
demos and how reliably they can show it off.
Perceptions of senior leadership. In many
organizations, senior leaders (especially
founders) love to play with new product
capabilities. Invite them to get involved
towards the tail end of a release and interview
them about their experience.
3. Peer involvement. Your team will internalize
quality once they begin engage each other about
it and you can help encourage this by taking
various steps:
Create rituals at design time. During design
discussions, help your team develop a routine
to evaluate the quality impact of various design
options. Provide questions for the team to
answer for each design being considered, and
after a release, show how these contributed to
overall quality.
Invite peer assessments. During periodic status
meetings, show your team the latest quality
metrics and ask each person to make their own
assessment of where you stand. Where is there
agreement and where do conclusions diverge?
Regardless of the answer, simply inviting the
team to make their own assessment will get
them thinking about quality.
Encourage pair programming. If done at
regular intervals, particularly between
junior and senior developers, this will help
encourage discussions of quality at design
and implementation time. Encourage your
senior developers to discuss this in each pair-
programming session.
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
4. Employee ownership and empowerment. You
can empower your team to make quality decisions
and feel greater ownership over the results. To do
this, consider the following:
Recognize quality initiatives. Create individual
measures of quality (such as bugs per developer,
perhaps scaled by project complexity) and provide
visibility and recognition to those on your team
who get results. Create a dashboard displayed
prominently for people to see how they stack up
against peers. Use this in meetings.
Create competitions. For a big project, consider
awarding prizes to the top performers who
implement the highest-quality code. Be sure to
announce the competition at the outset and
clarify how people will be measured. Have fun
with it.
Construct learning opportunities. Invite team
members with the best track records to deliver
lunch talks on how they approach quality, the
design choices they made, and the outcomes of
recent projects. Encourage team members to show
links between their approach to quality during a
feature implementation and how customers, sales
reps, or senior leaders experienced it.
In my 15 years of engineering and product
management experience at small and mid-size
software companies, I have found that the two most
powerful approaches to influencing culture are
creating rituals and recognizing achievements. Rituals
have the capacity to powerfully align teams behind
a common practice (forging a team identity), and
rewarding successful initiatives creates incentives for
team members to feel a sense of ownership over their
decisions and focus on what matters most.
My first startup experience brought this home.
I was a junior engineer fresh out of graduate school,
and our VP of engineering would define phases of our
release cycle to control changes made to our source
repository. The green phase early on in the release
meant that our codebase was open for all manner
of changes, the yellow phase in mid-release meant
that only low-risk changes were accepted, and the
red phase at the end meant that each change had to
be peer-reviewed to meet a certain quality standard.
Looking back, our VP continually broadcast the phase
we were in (demonstrating a leadership emphasis),
and the rituals of peer reviews in the red phase really
helped us internalize a quality-oriented mindset.
At the end of each release, our VP would also invite
peer nominations for high-quality efforts, which
wisely reinforced peer involvement while recognizing
achievement. The result was a strong sense of team
identity and shared values that persist with me to this
day.
13
 READ ONLINE ON InfoQ

Michael Feathers on
Technical Debt, Process, and Culture

Michael C. Feathers is a member of the technical staff at Groupon. Prior to joining Groupon,
Michael was the chief scientist of Obtiva and a senior consultant with Object Mentor
International. Over the years, Michael has spent a great deal of time helping teams alter design
over time in code bases. Michael is also the author of Working Effectively with Legacy Code
(Prentice Hall, 2004).

At the IEEE Software Experts Summit in 2012, Michael Feathers gave a talk
titled Technical Debt, Process, and Culture in which he presented his ideas on
creating an organizational culture and processes that can enhance software
development and reduce technical debt.
He reminded the audience how Ward Cunningham Quite often now, technical debt is used as a generic
oined the term technical debt to describe a specific term for the type of entropy that we see in software
strategy he had used in decisions about building a development systems. You work on something, and
software product. Feathers explained it as follows: maybe you havent done exactly the best thing you
We have some short-term goal that we need to meet, could and as a result you end up having something
and (we are) basically going to do it in a rather quick which is a little bit sour over time maybe earlier
and dirty way. And once we do this, we are going to technical decisions impede (you) as you are trying
say we have accumulated this particular amount of to add technical features later on, and we see that as
technical debt and thats fine as long as we go back being the result of technical debt.
later and clean this up. He maintains that the definition of technical
Cunningham described this as a specific debt that is most prevalent today is generalized
approach, with emphasis on going back and cleaning entropy in software systems as a result of personal
it up. decision making when we are designing things.
Feathers said that the way the term was treated He proposed taking another view of technical
in 2012 is quite different than Cunninghams original debt as the effect of unavoidable growth and
intent: remnants of inertia inside software systems.

14 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015

 Feathers said that this view of technical debt
makes it something that can be effectively managed ORGANIZATIONS I HAVE SEEN
and addressed through the software development
process. It is something to be avoided where possible
but it is part of the fundamental characteristics of
THAT HAVE NOT KEPT A GOOD
software products.
Building on that understanding of what BOUND ON TEAM SIZE QUITE
technical debt is, he asked, What if the wear and
tear of evolution is normal inside a software system?
Working from that premise, he identified
OFTEN END UP IN A SITUATION
trends in the shape and design of a software system.
Feathers challenged the perception of software as WHERE THE CODE SUFFERS
something that is deliberately designed and built
using a predefined process, asserting instead that
software is more organic and evolutionary in nature.
VERY DRAMATICALLY.
He said that any software system that has been
around for a number of years has characteristics
that are contradictory to the design model of to it having biological-like qualities. So, we should
development. not be surprised by what we see today in software
To illustrate his point, he posed two questions: development.
If you are working on an existing software product, is He went on to explore the similarities between
it easier to add code to an existing method or to add biological systems and software systems in the aspect
a new method? Is it easier to add code to an existing of piecemeal growth new parts of a system (biological
class or to add a new class? or software) do not grow out of nothing but almost
He said that more diligent development always grow from something that is already there. It is
professionals will maintain that it is easier to add always easier to add something on top of an existing
a new method rather than to modify an existing construct than to build something completely new,
one as it allows for better separation of concerns, even if the latter would be a more ideal solution to the
simplification of logic, etc. problem faced.
While Feathers called this the better approach, He used the example of language design,
he pointed out that the reality can be measured by specifically the C++ language. He said that C++ is
looking at existing software products to see what an old and established language that was designed
has actually been done to the codebase. In doing with allegiance to existing structure and concern for
so, we see systems with very large classes, with backwards compatibility:
very large methods systems which just grow and
grow over time despite the
widespread knowledge that
small classes and methods
are generally considered
better design. The average
developer working in a
system will typically go ahead
and add more code to an
existing method rather than
creating a new method and
the same with classes, he
said.
This tends to result in the
organic growth of systems
they grow over time. He said:
We as an industry really
havent adjusted to this reality
all that much, havent really
settled into the notion that it is
our interaction as people with
the software system that leads

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 15

(Looking at C++) feels almost as if you are looking at
a tree or something like that. The fundamental design
decisions that were made early on plus that allegiance
to previous structure, to previous design decisions, has
led to an increasing amount of complexity over time.
This complexity does not grow uniformly but
comes in waves and at different times in different
parts of the system:
When you look at something like the design of the C++
language, (you find) that some things are not quite as
simple as they could have been, and thats a natural
consequence of having to deal with previous design
decisions.
He said that this happens in most software
systems it costs too much to remove pieces made
in response to previous design decisions. We make
decisions in the context of what is already there,
which results in complexity that would otherwise
not be necessary.
Feathers said piecemeal growth biases toward
the existing structure of the system. Maybe.
He explained the maybe in reference to
the strong push over the last decade towards
iterative development. The recognition that big,
up-front design approaches do not work well and
the consequent influence of the agile software-
development movement have led more and more
organizations to adopt iterative development
practices. He reminded the audience that iterative
models of development are not new; they have been
around since the early days of software development
but the degree to which they are being adopted is
unprecedented and becoming universal.While
acknowledging that he did not have conclusive
evidence, he said that it appears that the widespread
adoption of iterative models can help reduce the
bias towards organic growth in systems.
He continued with a discussion of the different
forces that act on software and influence the
structure of systems. Software development is not
a mechanistic set of activities but a creative activity
influenced by a complex set of factors.
Conways Law
http://www.thoughtworks.com/insights/blog/
demystifying-conways-law
Conways law indicates that the structure of the
team impacts the structure of the software system
produced by the team. Feathers said that this is not
unique to software systems but is reflected in most
knowledge-based products. He pointed out the
implication of Conways law:
When staffing projects in IT, organizations should
be looking at what the architecture will be and at
the impact of having particular groups of people on
particular areas and should treat the entire thing as
16 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
an organic process. If they arent, they will quite often
be sideswiped by unintended consequences.
A corollary to Conways law is what Feathers
called the tragedy of the commons.
The perception that adding more and
more people to a team can accelerate software
development is something that he maintained is a
potential risk of agile development. Despite Brookss
Law (http://www.techopedia.com/definition/18085/
brooks-law), there is a temptation to create larger
and larger teams (possibly split into sub-teams) but
this brings risk to the quality of the codebase:
Organizations I have seen that have not kept a good
bound on team size quite often end up in a situation
where the code suffers very dramatically. It comes
down to the fact that anybody can come in and touch
any part of the code that they want to. It still amazes
me that people attempt to staff very large projects with
scads and scads of people and believe that is going to
be okay and that everything is going to scale nicely. It
just doesnt happen that way.
Another corollary to Conways law he identified
was process shapes software, too: any organization
that uses a process will inevitably produce artifacts
with grain mirroring the period of the process.
One potential impact of this is that highly
iterative projects run the risk of accelerated entropy
in the software. He indicated that this is an intuitive
rather than empirical statement and that research
needs to examine it.
Feathers also tied interface bulge to Conways
law.
In large software projects, we could have
multiple teams working on different parts of the
system, and those teams are defining components
with interfaces between them. Right behind the
API, there is often a place of accelerated change and
complexity. He indicated that this is a result of how
hard it is to change the interface between teams;
instead of changing the interface, there is a tendency
to add workarounds to the code behind the interface
in order to avoid API change. This adds complexity
on either side of the interface, which is beyond the
general characteristics of the overall codebase. This,
too, is an area that Feathers suggested for further
study, and is something that needs to be considered
carefully when structuring teams and software
systems.
In considering how software structure impacts
process, Feathers referenced Peter Provosts talk on
the butterfly effect (http://conferences.agilealliance.
org/sessions/20106353), in which Provost showed
an organization, which may be building safety-
critical software, should have rigorous processes for
checking in code with code reviews and other quality-
assurance activities. The unintended consequence

Figure 1
of raising the check-in bar is less frequent check-
ins of code, which makes the impact of regression
larger and more expensive. It moves product
design to favor more monolithic components and
significantly reduces the amount of refactoring that
team members do, which makes the product less
adaptable.
Feathers then asked, Are there qualitative
differences in exquisitely designed systems?
He raised this as a question for further study,
and considered the hypothesis that exquisitely
designed (defined by significant up-front design
effort) systems or parts of systems may well be more
robust:
Its not that Im not a fan of incremental development
I love it, I think its a great thing but I think there
is so much to learn if we discover that certain areas
of a system might be better if they were designed up
front based upon the structuring side effects that we
see within the codebases.
Feathers switched from what he called macro-
level impacts on software systems to micro-level
factors.
He mentioned research that showed the
likelihood a judge would grant parole strong
correlated with time of day. A judge is more likely to
approve parole right after a break, when the judge is
less distracted, not hungry, more alert, and inclined
to examine all the pros and cons of the case. At other
times, judges are less likely to grant parole.
Feathers wondered what impact mood, physical
and mental fatigue, hunger, etc. have on the quality
of the software we produce.
He presented some metrics that can be used
to track development work and the likely state of
the codebase, and discussed how analytics can help
to expose what is happening in the development
process.
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
He showed a graph (Figure 1) of the size of a
single method over time. Working on the basis that
the number of lines of code in a method is a simple
analogy for the complexity of that method, we can
examine the impact of such things as organizational
restructures or other drivers of change.
Feathers presented examples of the aspects
such as cadence of inter-commit intervals across
team members, complexity count across methods,
and what he calls ownership effect, and indicated
that there is an opportunity for further study into the
behaviors and practices of team members and the
quality of the system over time. These could allow
us to identify practices that result in more or less
complexity and fragility in the codebase.
Given his experience as a consultant in a
wide range of organizations, Feathers has been
able to identify clear differences in approaches to
software systems between organizations for which
technology is their business versus those who
perceive technology as peripheral to their core
business, whether it is or not. Technology-based
organizations tend to understand the cost and value
of software quality over time whereas the other types
of organization easily lose sight of these aspects (or
never consider them in the first place). Feathers said:
It seems that banks and insurance companies tend to
be relatively high in that area. They tend to think of
themselves as being financial and not really technical,
and as a result there is a schism in communication
between those two halves of the business.
On the other hand, technically focused
organizations face different risks:
It is very easy to get locked in. If you work for somebody
who knows how things were done ten years ago and
hasnt really moved on, you get some entropy in terms
of skill and acceptance of technical risk.
He indicated that there is a strong need for
organizations to more strongly consider the quality
of the code in their systems as an asset and to actively
manage that asset.
He discussed the impact of what he called
code blindness organizations where senior and
middle management have absolutely no knowledge
or understanding of the actual state of the code on
which their business runs.
Sometimes organizations target metrics as a
way to improve the code quality. Feather warned
of the danger of rampant second-order effects, the
unintended consequences of people working to the
target instead of to the intent behind the goals. He
told the story of an organization that set a target of
increasing the number of tests across a codebase and
how the teams produced many ineffective, difficult-
to-maintain tests that had no impact on the quality
of the product but did meet the numeric target.
17

Figure 2
He recommended that organizations start to
qualitatively assess their codebase. He showed how
to use spatial analysis to visualize the complexity of
the code in a system with some simple graphs that
were produced by analyzing the links and nodes in a
codebase. (Figure 2 & 3)
Figure 3
18 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
The more complex the graph, the more likely
it is that the codebase is complex and difficult to
maintain.
Feathers concept of lifecycle managing holds
that there is a scale point beyond which systems
become unmaintainable:
What I would love to see is people do studies to figure
out at what point in terms of complexity and size are
software pieces about to become unmaintainable,
and then discover if its more economical to rewrite
those pieces at the moment you discover that as
opposed to letting (the code) grow beyond the bounds
of reasonable, financial stability.
He suggested that integrated knowing can
help walk an organization out of code blindness:
Organizations that understand what software really
is for their organization also understand how all
the decisions they make within their organization
impact the structure of their software and also impact
the future directions in which they can take their
business because of the associated costs of the software
development.
Feathers concluded that at least one kind of
technical debt is unavoidable. The characteristic
growth of software means that we will get entropy.
Its just the way things are and we have to get used
to it.
 READ ONLINE ON InfoQ

Managing Technical Debt

Sven Johannis working as a software developer for Trifork Amsterdam. Sven is an avid user of
XP practices like pair programming, TDD, and small releases. Currently, hes developing online
assessment software for schools in Switzerland and the Netherlands based on Triforks QTI
engine.

Eberhard Wolffis working as architecture and technology manager for adesso AG in Germany.
His focus is on Java, cloud, and software architecture. He is a regular contributor at international
conferences and author of several books and articles.

Technical debt is widely regarded as a bad thing that should be avoided or

should be paid back as soon as possible.
Should you? We dont think so.

Developers can choose to implement new features
in two ways. They can do it quickly and messily,
which will make future changes very hard. The other
way is a clean and smart solution that takes longer
to implement but makes future changes easier (see
the thoughts of Martin Fowler). But why should the
sponsors of a project accept higher costs for a clean
implementation of a feature that if implemented
with a messy solution delivers the same functionality
and costs less? Why should they spend money on
automated test coverage? Tests are not features and
therefore dont deliver business value!
Although messy code or code without tests
works perfectly for customers if it delivers the desired
business value, this will lead to an uncontrollable
codebase, extremely specialised developers,

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 19

and eventually to an inflexible software product.
Enough messy code may bring a whole engineering
department to astandstill.
In that linked article from 1992, Ward
Cunningham was the first to use the debt metaphor
for technical debt as he explained this problem to
non-technical stakeholders. Code with low quality
and no automatic test coverage can be compared
to financial debt. This code is like a financial burden,
which imposes on all stakeholders - not only on the
developers - a debt that incurs interest with time.
The principal amount is the cost of refactoring the
codebase to a clean design, which allows easy future
changes. The interest is the extra costs, which have
to be paid in the future if the team has to work with a
messy codebase instead of a clean one.
Unlike financial debt, you dont have to pay
back technical debt. Sometimes, paying it back
would even be pointless: some pieces of code are
rarely or never read or changed. Therefore technical
debt needs to take into account a probability of
occurrence: how probable and how often will the
messy code be touched in the future? Another
difference compared to financial debt is that the
originators of technical debt wont necessarily
pay back the debt themselves; that is left to the
developers who maintain the codebase later.
Like financial debt, technical debt is not
necessarily to be avoided. Like Eric Allman explains,
Not all debt (whether technical or financial) is
bad. Few of us can afford to pay cash for a house,
and going into debt to buy one is not financially
irresponsible, provided that we know how to pay
it back. In contrast, charging up luxury items on a
credit card, knowing very well that your paycheck
wont cover them, is usually a recipe for disaster.
In software development, technical debt might
lead to early release and profit the organization more
than it costs to pay back. In finance, debt is a good
thing, if the principal amount plus interest is less
than the yield of the investment. The same is true
for software. If you sacrifice internal quality for being
the first on the market, it only pays off if the yield
you make with this decision is greater than it would
be coming later to the market with better internal
quality. There is, however, a risk, because uncertainty
makes it hard to estimate these benefits up front.
Technical debt and strategic design
Eric Evanss concept of strategic design gives us an
idea how to deal with technical debt. He says that
a system cant have the same high level of quality
throughout. Therefore, a team can choose either to
leave to chance which parts of the system have good
or bad quality or to actively control the quality. Code
that is rarely read or touched and doesnt implement
20 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
important requirements does not have to be
absolutely perfect and therefore we dont need to
spend a lot of effort making it great. So, which parts
of the code should have high quality? Its possible
that a piece of the implementation has a poor design
but not bad quality if it doesnt require good design,
but while each particular piece of code doesnt need
to have good quality, you might be creating an
unmaintainable system as a whole.
Understanding strategic design and technical
debt leads to better communication within a project
and therefore to better decisions by its stakeholders.
Developers might realize that not every requirement
has to be implemented elegantly, if this requires
too much effort. The customer understands that
quick and dirty solutions lead to debt the project
eventually has to pay back. Technical debt consists
of hidden quality problems, which like an iceberg
might lead to a failure of the project once they
surface e.g. too many bugs may pop up too late to
fix cost-effectively.
Stakeholders of technical debt
Technical debt concerns many stakeholders of a
software project:
Customers are annoyed by bugs or missing
features due to low productivity.
This leads to additional costs for thehelp desk,
which annoys the people there, too.
Increased development time and quality issues
are also a problem formarketing.
Bugs lead to frequent patches, which annoy
theoperations team.
Many annoyed parties definitely dont make
the management happy, especially if there is
bad publicity due to bugs, delays, or security
problems.
Last but not least, thedevelopersalso suffer. No
one wants to deliver bad work. Furthermore, no
one wants to take over the bad work of others.
Technical debt is unavoidable
But why dont projects avoid technical debt from
the start? Assuming that developers arent lazy and
are experienced with the relevant technology and
patterns, technical debt almost always arises from
time pressure. The developers hope to gain higher
short-term productivity and to lower costs with a
quick and dirty implementation of the current release,
well aware that they will face lower productivity and
higher costs in future releases. The team, however,
can never be really sure that it actually will achieve
higher productivity or lower costs with the current
release. Possibly, the shortcuts boomerang earlier
than expected and the team has to pay the interest
earlier than expected.
 But developers usually dont really want
shortcuts or compromises in quality. Sometimes,
external conditions force them to work quickly on
a release because otherwise there wont be a next
release. Or the team assumes that the code wont
be read or changed often. The previously discussed
strategic design definitely allows compromises
in quality. In that case, good code might be gold
plating, overkill with little effect.
The metaphor of technical debt helps
stakeholders to discuss the problem of poor quality
that might otherwise go unnoticed until it is too late.
The metaphor of technical-debt aptly symbolizes
subsequent damage due to bad code quality and the
increasing degeneration of quality over time. But the
metaphor also falls a bit short: not all technical debt
must be repaid. The team also doesnt know exactly
how much debt has accumulated and when it needs
to pay it back. The person who incurs the debt is not
necessarily the one who repays it fancy that in real
life!
Identifying technical debt
A major problem of technical debt is that its not
obvious. Anyone can see the amount of debt on an
account statement. But how can a team recognize
technical debt? What are the indicators?
General smells may manifest themselves in
statements from team members: the only one
who can ever change this code is Carl; lets just
copy and paste this code; if I touch that code
everything will break; or too many TODO or
FIXME comments in the code (nicely described
by Nico Zazworka).
Scrum teams have a velocity. The software
system has probably too much technical debt
if the velocity decreases even though neither
the team nor the external circumstances have
changed.
Software ages. One indicator for technical debt
is a system that uses old libraries that are no
longer maintained or of which new versions are
much more productive (e.g. EJB 2 vs. EJB 3). In
the worst case, the libraries are already so old
that the developers of the libraries no longer
support them.
Automatically measuring technical debt is
partially possible. Correctly configured, tools like
Sonar, Sonargraph for Java, or Structure101 find
important violations of best coding practices.
Asthisblog post shows, this is not the ultimate
solution but is a very good one. With Sonar,
you ensure that developers follow important
code metrics like appropriate class and method
size or low cyclomatic complexity. Tools like
Structure101 find structural problems, including
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
cyclic dependencies. If two elements depend on
each other, any change in one of the elements
potentially affects the other. These two elements
can only be changed together although they
actually should be separated and be developed
independently. Furthermore, Structure101 finds
complex code: it is all about the dependencies
among the elements. A system is hard to
understand and therefore to maintain if its classes
or packages have too many dependencies to
other classes or packages. If developers want to
make a change, they have to understand many
classes and packages and have to consider many
dependencies. These problems point to key
challenges in the architecture.
Code-coverage tools can detect how much
code automatic tests really cover. This metric
should be used with care since there are no strict
guidelines but, generally, coverage of more than
90% is a good indicator that there are enough
test cases available. Conversely, coverage below
75% may indicate a serious problem.
A very bad indicator is frequent problems in
production. This means that the problems in the
system are so extensive that reliable operation is
no longer possible.
There are also many cases in which systems have
technical debt that cannot be measured directly in
the code, e.g. clumsy solutions, the wrong choice
of technology, a well-executed but wrong design
for a solution, or simply evil hacks that tools cannot
easily detect. In these cases, technical debt must be
measured with general conditions: the number of
bugs per release rises rapidly, work velocity decreases
permanently, or the team is under extreme stress at
the end of a release.
The sooner debt-incurring problems are solved,
the cheaper. If developers identify technical debt
and communicate it, and nothing happens, sooner
or later business people will feel these problems, too.
Technical debt is not a gimmick of developers who
want beautiful code. It is a tangible cost factor and
may be a risk for a project, and so must be made
visible and manageable.
As in real life, debt is not necessarily a bad
thing, but it must be used consciously and properly.
For software projects, this means that paying back
technical debt is purely a business decision. It must
not simply be a developers decision.
How to manage technical debt?
Technical debt cannot be ignored, and even the non-
technical management on the client side must have
an interest in managing it as smartly as possible to
achieve the best balance between short-term, mid-
term, and long-term success. What can a team do to
21
avoid wasting time with unimportant beautification
but still make meaningful business decisions for
improving code quality?
Coarse-grained statements such as do nothing
or if the code is unmaintainable anymore, develop
anew do not help.
Two promising approaches have already proven
useful in several projects are a technical backlog and
including the cost of technical debt in requirements
estimates.
Two other critical processes probably make
sense in certain project contexts: buffer tasks for
refactoring and clean-up releases.
Buffer tasks
The team creates one buffer task per release with, say,
10% of the available time. Team members can record
time for that task as for unscheduled refactorings; it
is used for unpredicted problems that might appear
in the future. Such a buffer is easy to schedule and
use but also risks wasting that time on unimportant
work. A buffer doesnt force anyone to consider
whether the time is spent for useful refactorings
or not. The developers simply record their time
on the buffer task. Most likely, the developers may
not optimally use their buffer time especially in
deciding which refactorings to do, although that
should really be a business decision. Using buffer
tasks unfortunately means that what should be done
is not really defined.
Clean-up releases
Some teams do a purely technical release from time
to time to improve the codebase. This approach
is only useful if a list of the necessary refactorings
already exists. Otherwise, the team risks wasting
time on unimportant refactorings. The business side
must also support this approach because doing it
might delay new features. Of course, this means
that business people have to understand technical
debt. Teams should think about a pure technical
release to clean up the codebase and to rework
the architecture if some major effort is needed. For
example, the same parts of the code might always
cause problems during development or operations
or the current architecture might no longer fit the
current requirements. Such problems cannot be
solved within small refactorings. A clean-up release
allows extensive changes.
It makes no sense to do a clean-up release after
a hectic and time-critical release that has created a
lot of technical debt. At that point, the team has little
experience with the new codebase so no one can say
which part of the code needs to be improved. There
is a danger in changing code that does not really
need improvement.
22 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
Technical backlog
The technical backlog is an established best practice
to define purely technical work packages. Tasks
for this purpose are created in a task tracker or a
requirements management tool. Each task has a brief
description of the technical change to be made, why
this technical change is important for the project,
and in which part of the code the technical change
has to be performed. As with any other task, we need
an estimate of how long it takes to develop a good
enough solution. In addition, we need to estimate
the interest that is inherent in this code. A precise
estimation is difficult but often a rough estimate
of small, medium, or high is sufficient to guide a
decision. We also need to gauge how likely it is that
this code will be read or changed in the near future.
This approach has several advantages:
Technical debt is made visible and clear for
everybody. A unanimous decision on if and
when a refactoring task should be done can be
based on the estimated effort and the impact on
future code changes.
The cost per task is easily tracked.
There is no mixture between technical tasks and
feature tasks.
However, this approach also has some disadvantages:
The customer must decide and prioritize tasks
in the backlog. A customer cannot determine
the value of a technical task without detailed
knowledge of the software and technical issues.
In addition, the customer may not really
understand the business benefit of a purely
technical task. In many cases, customers may
not understand why a technical task without a
feature relevant to them is really needed.
Only in special situations should the customer be
able to have a final decision with, for example,
software updates. It is obvious to most customers
that outdated software causes problems. Whether
or not to proceed with an update has to be decided
case by case, based on cost, risk, and necessity of
the upgrade. Updates of components such as the
Java Runtime Environment, or an O/R mapper do
usually not require a lot of effort and dont risk much
if done regularly. Very expensive changes like the
replacement of a web framework or a change from a
relational database to a NoSQL solution must always
have a business reason e.g. the performance or
the user experience of an application will improve.
For this purpose, the technical backlog is also well
suited. But for such tasks, developers may also
initiate a separate project, depending on how much
effort they expect to need.
If a new codebase requirement should be
implemented in a codebase that is not well designed
for this new requirement, a refactoring might be
needed first. To do this, you have to add the extra
effort for the refactoring during the estimation of the
requirement.
Requirements estimation with effort for
technical debt
Strategic design has taught us that not every
part of the codebase must be very good only those
parts whose changeability brings business value
or which need to be changed frequently for other
reasons. The quality of code that is rarely or never
changed can be ignored and no technical debt will
accrue.
Its also important that code should never be
refactored without good reason. If a new requirement
provides concrete business value then we should
never implement this requirement based on badly
written code but instead refactor beforehand. That
way, the really important requirements can be
brought to a good enough standard. A team that
has been assigned to implement such an important
feature in an upcoming release should have this
refactoring in the budget and then implement it.
There are exceptions, discussed in the next section.
This procedure ensures that no unnecessary
beautification work is done and that refactorings
are always directly associated with a requirement.
This allows the customer to discuss and prioritize
the refactoring with the team. The customer can
also decide whether or not a requirement should
be implemented based on debt and interest. There
might be other factors to take into account, such
as time to market. The customer might also already
know about future changes to the code that are
based on these requirements and might therefore
decide to refactor to a clean codebase in order to
save costs in the future.
Problems arise if the team runs into a problem
with the codebase during the implementation.
Then the team must decide what to do. If meeting
the delivery date with all promised functionality
is very important, the team must accept the
resulting technical debt and interest payments. If all
development based on bad code is considered waste
and there is no real deadline pressure, the team
should schedule the refactoring and push release to
a later date. This all depends on the context and, in
particular, the needs of customers.
To pay or not to pay?
One question that must always be addressed in
the discussion of technical debt is should it ever be
repaid?
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
Only important parts of the code must be
really clean and code should only be refactored
if necessary. However, it is hard to decide what
solution might be best for a specific scenario. Frank
Buschmanndescribesthree strategies:
Debt repayment: refactor or replace the code,
framework or platform that is considered a
technical debt.
Debt conversion: replace the current solution
with a good-but-not-perfect solution. The new
solution has a lower interest rate. That might be a
good option if a perfect solution is prohibitively
expensive to build.
Just pay the interest: live with the code, because
refactoring is more expensive than working with
the not-quite-right code
Developers and customers have to decide on the
basis of cost, risk, and urgency. Such a substantial
refactoring should always be a business decision.
Another important factor for paying interest is the
lifespan of the software: is a refactoring sufficiently
valuable if the system will be redeveloped or retired
soon anyway?
Conclusion
Technical debt can be seen as a shortcut that saves
teams time, effort, or money today but that might
lead to increased costs in the future. Technical debt
cannot really be avoided in software projects. But it is
not necessarily a bad thing, if handled properly.
It is difficult to handle properly, however.
The effect bad code has for future requirements is
difficult or even impossible topredict but completely
ignoring technical debt can have a disastrous impact
on the software. If the team and the customer
properly handle the risk of technical debt, it should
remain manageable, and there are several ways to
respond to it. Each of these options should only be
used in a specific context.
It is important to accept that:
there is always technical debt;
technical debt is not always bad; and
technical debt does not have to be (fully) repaid
in every case.
Any repayment should be a business decision. Even
if the repayment is so small that a consultation with
the customer does not make sense, developers must
always ask themselves whether an improvement of
the code justifies the increased time and effort.
23
 READ ONLINE ON InfoQ

Technical Debt: A Repayment Plan

Jeremy Jarrellis a professional software developer and agile coach specializing in commercial
application development for the private sector.He is heavily involved in the local developer
community, both as a highly rated speaker throughout the East Coast of the United States as
well as a syndicated author whose articles and videos have appeared on sites such asSimple-
Talk, DZone,Pluralsight, andScrum Alliance. Jeremy loves to discuss all topics related to software
development or agile methodologies and can be reached through Twitter at@jeremyjarrellor
athis website.

Many teams struggle with technical debt but few teams devise a plan to get
out from under it. To better understand how we can escape the debt, we first
have to understand exactly what it is.

Technical debt is incurred by a team that knowingly
makes a less-than-optimal technical decision in
return for a short-term gain in their project. For
example, team members may decide to forego
writing automated tests as in-depth as they
normally would for a tricky section of code in order
to get a product to market sooner. Or they may
decide to build a project on an aging, soon-to-be-
deprecated framework rather than investing in the
purchase of an upgraded, better-supported version
of that framework. Whatever the decision is, the
key to recognizing true technical debt is that the
team knowingly (and not accidentally) decides to
incur long-term debt in favor of a short-term gain.
This means that many things we
commonly attribute to technical
debt are not actually debt at all.
For example, normal bit rot that
occurs as a system ages under a
team that fails to keep up with
coding best practices is not debt. A technical decision
that a team willingly made and implemented that
later turned out to be incorrect is not technical
debt. In neither case did the team knowingly enter
into a less-than-optimal long-term decision in favor
of a short-term gain. This distinction is important
because only after weve agreed on what exactly
constitutes technical debt can we best decide how
to eliminate it.

24 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015

 Its also important to consider the effect of
debt we unintentionally incur in our codebase, but BIT ROT DIFFERS FROM NORMAL
since we did not intentionally take this debt were
unable to plan how to address it ahead of time. In
these cases, we simply must prioritize and address
TECHNICAL DEBT IN THAT ITS
this debt as we discover it, similar to how a team
addresses newly discovered bugs. NOT TAKEN INTENTIONALLY,
We often compare technical debt to financial
debt, but is this a fair analogy? For example,
would a bank actually lend us money without first
SO WE CANT DECIDE AHEAD
establishing when and how it will be repaid? Likely
not. Since we couldnt actually borrow financial OF TIME HOW AND WHEN TO
capital without first agreeing how to repay it, we
shouldnt treat technical capital in this way either.
The financial metaphor is actually a quite
REPAY IT.
powerful one, so lets take it to its full extent.

A repayment plan
Like financial debt, when taking on technical debt, add test coverage to those areas while deferring the
we need to establish how and when it will be repaid. simpler areas for later. Or they may decide that simpler
but lower value types of automated testing such as unit
How well repay it tests can be added immediately while setting aside
Lets take the case of the foregone automated tests more difficult automated tests such as automated
mentioned above. If our team has willingly decided user-acceptance tests for a future sprint. Whatever the
to forego writing automated tests for a tricky piece decision, the team and stakeholders would likely not
of code in order to get a feature into production have arrived at it had the discussion of technical debt
sooner, then we need to establish how well correct not occurred in the first place.
that piece of debt. In this case, we simply need to
state that well return to this piece of code at some When well repay it
point in the future and add the tests then. In addition to howwell repay the debt, well also want
However, simply stating well add tests later specify whenwell repay it. Often, the sooner the debt
doesnt do this problem justice. To help stakeholders is repaid, the better. For this reason, its best to schedule
fully appreciate the weight of our decision to incur
technical debt, well need to specify, to the best of
our abilities, exactly what the impact of waiting to
add automated tests until later will be. For example,
well want to specify the sections of code for which
we will need to add tests. Well also need to point
out that retrofitting automated tests on an already-
existing piece of code is always more difficult and
expensive than simply adding the tests at the time
of creation. This last point is important because it
highlights that in deferring this work to the future,
well actually need to spend more money to do the
work then than if we had we done it today. To put it
another way, our debt accrues interest.
After discussing the options for repayment,
both a team and its stakeholders will likely realize
that this problem goes deeper than simply whether
or not they should write automated tests at the time
the code is written. In fact, they may find that they
have several options between the two extremes
that suit the overall project better. For example, they
may decide that it makes the most sense to identify
the most complex pieces of the new feature with a
metric like cyclomatic complexityand immediately

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 25

the work to repay the debt at the time its incurred
to better convey the impact of taking it on. For
example, if your team is following a sprint-driven
schedule then you may choose to schedule the work
for the following sprint or, in the worst case, a few
sprints in the future.
Often, a team has the best intentions of
repaying debt at the time its incurred but just never
seems to find the time to do so. Get your repayment
deadline on the calendar when you take out your
debt and stick to it.
What happens if we default?
The final piece of our financial metaphor is to
capture the result of defaulting on our debt. In the
financial sense, if I never repay my auto loan then the
bank takes my car. The results of defaulting on our
technical debt should be laid out just as clearly.
Sticking with our example of automated tests, if
our team decides not to repay our technical debt, it
will only become more difficult and more expensive
to build new functionality on top of the existing,
untested functionality. Well likely see more bugs
reported in production, which may diminish the
impression our customers have of the quality of our
product. And well be less able to rapidly respond to
changes in the marketplace because a significant
portion of our product will be either too difficult or
too risky to change quickly.
We need to make each of these points clear to
our stakeholders to help stave off the temptation to
simply default on our technical debt.
Dealing with bit rot
While this discussion so far has
centered on planned technical
debt that teams knowingly incur
as part a normal project, we
would be remiss if we did not
discuss theunplanned technical
debt that also plagues so many
of our projects: bit rot.
Bit rot differs from normal technical debt in that its
not taken intentionally, so we cant decide ahead
of time how and when to repay it. However, not
knowing specifically what form bit rot will take on
our project doesnt mean that we cant still plan for it.
Just as we plan to pay back known technical
debt, we can build into our project plan a buffer with
which to address bit rot during each sprint. Though
the specific tasks that fill this buffer may not be
known at the time, having the buffer there gives us a
dedicated space with which we can pay back those
unplanned issues such as bugs, minor refactorings
that must be handled immediately, or small pieces of
26 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
system maintenance that make themselves known
as our codebase naturally ages and decays.
But what about the larger issues that cant
be handled in a few hours of development time?
Perhaps there are more systemic problems plaguing
our system such as a failing infrastructure or an
aging architecture that no longer fits the shape
of our business. While these issues are too large
to easily address, we can use this buffer to identify
and investigate these issues so we can give them
the attention they truly deserve later in the project.
For example, in the case of failing infrastructure,
perhaps we could identify the most common failing
pieces and add stories to our backlog to replace
those pieces. Well then prioritize and schedule those
stories alongside our normal development. In the
case of the aging architecture, we may spend time
to determine the highest value in-flight changes
that we can make to our architecture and then break
those changes into stories that can be addressed
piecewise over the coming sprints. Regardless of the
problem, having the time to identify and plan for
the issue means that we can address it like any other
technical problem.
A budget
Now that we better understand
the effects of incurring technical
debt, how do we make sure
we pay it back? To get a feel
for this, we can expand our
financial metaphor in yet another
direction: budgeting.
Many of us draw a regular paycheck every few
weeks. This paycheck is a portion of our annual salary,
distributed in even portions throughout the year.
For example, if we draw an annual salary of $52,000
then we may receive that salary in $2,000 increments
every two weeks, or 26 times per year.
However, while we receive $2,000 dollars every
paycheck, its quite unlikely that the full amount
makes into our checking account. Its more likely that
only a portion makes it to our checking account while
we use the rest of it for long-term investments or to
pay down debt. For example, a budget breakdown of
$2,000 may look like this:
$500 invested for the long term, such as
contributions to our retirement account;
$200 used to pay down short-term debt, such as
credit cards;
$300 used to pay down long-term debt, such as
a mortgage or auto loan;
$250 deducted directly to pay local or national
taxes; and
the remaining $750 deposited into our checking
account.
While no one is particularly
thrilled about this arrangement,
few people question it. Its
simply the accepted norm. If
this arrangement is so widely
accepted, why not extend it to our
project planning?
Imagine that were planning
a sprint in story points and weve
allotted 50 points to that sprint.
While wed like to spend all 50
points on new development, it
makes the more sense to budget
some points to pay back our
technical debt. For example, of
our original 50 points we may
decide to budget:
10 points to pay back
technical debt;
5 points to ongoing codebase
maintenance such as fixing
bugs or addressing bit rot;
and Of course, like our personal budgets, this
35 points for new development. budget does have some leeway. For example, if we
Looking at our point budget, we see some obvious pay down our technical debt more quickly than
similarities to the financial budget described above. expected then were left with more points to spend
We cant spend all 50 points on new development. on new feature development. By the same token,
Rather, we must commit 10 points towards paying if we find ourselves taking on a particularly large
back our intentionally incurred technical debt, just amount of technical debt then we may need to slow
as we commit a portion of our paycheck to pay back new feature development a bit until its back to a
long-term and short-term financial debt. In addition, more manageable amount.
we devote 5 points for ongoing maintenance of our
codebase, just as we lose a portion of each paycheck Wrapping up
as taxes that help keep our communities running By thinking of technical debt in terms of financial
smoothly. The remaining points are ours to spend on debt, we can make more informed judgments of
any new development we like, just as the remaining when to incur debt for the betterment of our project.
dollars deposited into our checking account are ours We can also better plan the impact of trying to pay
to spend as we wish. the debt back as our project progresses.
By budgeting our work in this manner, we can And by planning a regular budget for technical
ensure that we move the project forward without debt alongside our regular work, we can better
allowing it to crumble under the weight of our understand when our debt is manageable and when
technical debt. its becoming overwhelming.

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 27

 READ ONLINE ON InfoQ

James Grenning on Technical Excellence

byShane Hastie
James Grenning, founder of Wingman Software, trains, coaches, and consults worldwide.
With more than 30 years of software development experience, both technical and managerial,
James brings a wealth of knowledge, skill, and creativity to software development teams and
their management. As his professional roots are in embedded software, he is leading the way to
introduce agile development practices to that challenging world. See James articles for applying
Agile to embedded software development. Areas of interest are software process improvement,
object-oriented design, programming, embedded systems, project management, extreme
programming, test-driven development, test automation, and agile software development.
James knows his way around Scrum, with ScrumMaster and Product Owner certifications.

James Grenningis the founder ofWingman Software, author ofTest-Driven

Development for Embedded C, signatory of the Agile Manifesto and inventor
of planning poker (which he now advises people not to use). He delivers
training and coaching in technical practices around the world. At the Agile
Singapore2014 conference, he presented two technically focused talks - one
on the importance of technical excellence and the other a hands-on workshop
that taught the skills of test-driven development (TDD). He spoke to InfoQ
about the importance of strong technical practices to enable true agility in
software development.

something that I call debug-later programming:

Youve come to the Agile Singapore conference
and youre talking on technical excellence. Whats
the extent of technical excellence in software
development today?
In my travels, I visit a lot of companies and I find
people programming the way I learned in 1979,
you write some code and you figure out whats wrong
with it later. You usually find some of the problems
but not all of them, and it leads to big problems in
delivery and later. A lot has changed since 1979; in
1999, I discovered extreme programming and it
changed my world from a reactive life of debug-later
programming to a proactive life of TDD where I can

28 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015

prevent defects. I was invited to give this talk here in
Singapore and I had some specific messages for the
attendees. I wanted managers to understand that
defects are the result of the way we work; it causes
the problems they are experiencing defects being
found late and in the field. I wanted developers to
understand why these practices are important.
Theyre not important because theyre written down
in a book. Theyre important because they solve
specific problems. As an engineer Im interested in
solving those problems and helping other people
solve them.
Weve known about these practices since at least
1999 if not before. Why are they not just the way
we do work now?
I dont know the answer to that but Ive got some
suspicions. Work life is very demanding when you
work for a big company and there are a lot of ideas
out there fighting for your attention. Its hard to
know what the good ones are. People know what
they know, and they dont necessarily know what
they dont know. So if you hear about something like
TDD, you form a vision of what that is in your mind.
It sounds strange, people forming opinions with
little information. You dont know what to do with
it so you keep doing what you know. The pressure
is on, and its hard to find time and support for the
change that you might want to do. The organization
makes it hard for you to change, and you dont really
understand what it is and why it would be important.
Most people are doing the best that they know but
they dont know what they dont know.
How come weve done so poorly at getting this
into the programmer education in the university
system, educational system, and organizational
training systems, because these good technical
practices can actually save organizations lots of
money?
Yes. Thats my experience and belief as well, that
the practices of extreme programming save people
money. First off, it appears that they cost more
because people are concerned about the lines of
code that need to be written. When I teach people
how to start doing TDD, the first simple exercise
results in writing 100 lines of code and 150 lines of
test code. We spend less time than it would take
someone to write production code and get that to
Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
work through manual testing, but they dont think
about that. They think about how many lines of code
were writing and it must mean that is going to take
us way longer.
But surely were beyond lines of code as a metric.
Surely the work is the creative output of the
thinking process?
About lines of code people still see it that way, until
they experience it. One thing I cant do for someone
is experience how much better they will be in several
weeks or months if they learn this. I cant make them
experience that because these approaches have to
be voluntary. For someone to get the benefit from
TDD, they need to see that is might solve a problem
they want to solve. If they try it, they are likely to
convince themselves through their own experiences.
Of the experienced people that started
learning this years ago, most of them wouldnt stop
and its not because they want to be slower, less
effective developers. Its because they want to be
more effective. Though youve got to take the time
to learn.That often means picking the right time to
start.
Agile has been around since you and others
created the Agile Manifesto in 2001. One of the
underlying principles is technical excellence. How
effective has the agile community been at getting
that message through?
Its interesting. On the tenth anniversary of the Agile
Manifesto, Alistair Cockburn held another meeting
to which he invited the original people involved
in the manifesto as well as other influencers in the
community. It was in Utah, so I am in. The reason I
was in the manifesto group to start with is that Bob
Martin invited me and it was in Utah and ski season.
This was an easy choice for me. Obviously, Im going
to go to Utah to go skiing. The second meeting was
a retrospective on agile and again it was in the right
place and hanging out with cool people again.
The retrospective on the state of agile resulted
in four bullet points surprise. Unlike the original
meeting, four bullet points was an objective of the
tenth anniversary meeting. The top two bullet points
were very important to me. The first was that we need
to demand technical excellence. The second bullet
point was that we have to help foster change. The
other two I dont remember. The first two surfaced
29
on many fronts in the workshop. It was pretty clear
that the attendees think the industry has adopted
the business practices of agile, but not the more
difficult technical practice of agile.
The genesis of this talk came from an invitation
to do a keynote at the London Scrum gathering a few
years ago. When the organizers invited me, I asked,
Well, Im not really part of Scrum. Why do you want
me to talk there?
Because youre not part of Scrum, they
answered. I asked who would be the audience.
ScrumMasters mostly.
It has been a concern of mine that Scrum
seems to be practiced by the book. The continuous
improvement intended by the creators of Scrum was
not really happening across the industry. I asked, Can
I talk about this things that the Scrum community is
not doing? They said that would be great, so began
this talk. I probably should write something about
this, too. Ive been talking about it now at a few
conferences; its a fun story for me to tell with about
a million sides.
So whats wrong with the Scrum and other agile
methods that were just not getting? Whats
missing?
I think theres something going in. People go to the
two-day ScrumMaster class. Now, theyre certified
and they go and practice just what was taught. When
theyre challenged, they say, Well, the books says to
do it like this. People get used to saying, Well, the
book says to do it like this, and they miss the part
which is Now look at your work and decide whats
broken and try to fix it.
I was in the first-ever Scrum training class, given
publicly by Ken Schwaber in 2002 at Object Mentor in
the Chicago suburbs, and the original materials had
the extreme programming practices. I discovered
they were later removed. I think Kens expectations
were that people would go find XP or other technical
solutions as part of the retrospectives of Scrum. We
didnt want to prescribe that as part of Scrum, is what
I remember Ken saying (I could have this wrong).
What I see is people arent doing that part of Scrum.
Scrum, at its code, is intended to be a continuous
improvement cycle.
In the 80s, there was TQM, total quality management,
where we learned the PDCA cycle: plan, do, check,
and act. And what I feel is happening in Scrum in
many implementations is not the whole cycle, just
the act part. Theyre doing the easy part of Scrum
and programming the same old way, debug-later
30 Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015
programming. (See a comparison of debug-later
programming and TDDhere.)
If one looks at the Scrum framework, the
retrospective is an absolutely imperative part.
I will say in my experience its horrifying the
number of teams for whom the retrospective is
Groundhog Day. They say the same thing again
and again but nothing changes.
Right. If there are numerous things that are wrong
and they all seem out of the teams control, its
hard to make any progress. Fortunately, there are
solutions to many of the problems that the Scrum
teams continue to seek for instance, not being able
to deliver software every iteration. (I dont call them
sprints; I think its the wrong metaphor.)
Failure to be able to deliver every iteration
is failure of defect prevention. If you dont have
automated tests, the cost of retesting will be high,
making releasable product increments very risky.
The cost of retest must be low to be able to do
effective releases every two weeks. The cost of retest
needs to be close to zero. TDD and acceptance-test-
driven development are solutions to that problem.
It turns out theyre hard to learn, which is very nice
to me because its a fun business. But theyre hard
to learn and it requires discipline and there will be
mistakes until you figure it out and get addicted to
this improved way to program.
Why is it so hard to learn? The people were talking
about here are technical, theyre programmers,
theyre natural problem solvers. They want to do
this.
Im no cognition expert or anything, but the way that
people learn to program is a unique thing. I know
for me it was: heres how you set a variable; heres an
if statement; heres a for loop. Now go figure out
how to write an operating system or how to simulate
Newtons methods for calculating the area of a curve.
Go figure it out.
No one was really taught to program. Everyones
programming is a very personal thing, although
most people generally do what I call debug-later
programming. Write the code and figure out whats
wrong with it later. With the entrance of TDD, youre
turning the whole programming model upside
down. You create one behavior at a time, thinking
about what you want the code to do. Express one
small code behavior in a test, one test at a time. Then
you evolve the code to do just that
behavior. Then choose the next
behavior, and express that in a test.
I can work in a tight feedback loop
that catches my mistakes so that
I can prevent many defects. I also
produce a regression test suite as a
side effect, virtually for free.
Bob Martin compares TDD
to double-entry accounting.
Theres always one credit and one
debit. They cancel each other out
when the books are right. This
is a very specific technique for
programming but very foreign
because its not what people
know. People will generally look
with suspicion at things that they
dont know. Oh. Thats too weird.
No, I dont do it that way.
What I try to do to get some
buy-in, though, is before I even
start with saying anything about TDD, I ask the class you could do more of what you like and less of
attendees at my training to tell me what they like what you dont like? Lets reduce boring manual tests
about development, what they dont like about and trade them for something fun: problem solving.
development, and why theyre at the training class. I The problem to solve is the challenge of writing the
get some interesting feedback. I started to put these test so that I dont have to do boring manual tests
on my website. afterwards. Ive found this to help to open minds to
The activities that engineers usually put in the the possibility that there is a better way.
like category are I like problem solving, I like to I find that more people try to learn TDD when
code, I like to clean code, I like to design, I like they see the possibility that their lives could be
to solve a problem for a customer, I like to see my better. I had this weird idea in the beginning in 1999
work used to solve a problem in the real world. This about people adopting the engineering practices of
is what engineering is all about. I can confirm that I extreme programming. The people I worked with at
have the right people in this room for my training. Bob Martins company were convinced XP was loaded
If engineers tell me they dont like testing, I say, with good techniques and ideas. We thought these
Now, wait a second. Remember, the class is test- ideas were so good that we can just mention them
driven development. Im going to go check to see and people will want to do them. Unfortunately, its
what you answered about why youre here. I bet your not the case.
boss made you come. I mean, the techniques are better but telling
If youre interested to see some of the answers someone about a better idea does not make them
for yourself, you can find recent like and dislike want to do it. For wider adoption, people have to want
replies at Wingman Software.I dont like testing to avoid the problems like debug-later programming
either; traditional testing is boring and repetitive. Its and degraded designs. They have to accept there are
unfortunate TDD has the word test in it because its problems and then see that technical practices of
not the focus. Other things trainees dont like are bad extreme programming may be part of the solution.
code, unrealistic expectations, many of the things Then they have to prove it to themselves.
agile and TDD are supposed to help with.
I use this to get buy-in to try TDD during the
training. Ill ask, What if I by the end of this training

Technical Debt and Software Craftsmanship // eMag Issue 27 - Apr 2015 31

 PREVIOUS ISSUES

25
Next Generation HTML5
and JavaScript

Modern web developers have to juggle more constraints

than ever before; standing still is not an option. We must
drive forward and this eMag is a guide to getting on the
right track. Well hear from developers in the trenches
building some of the most advanced web applications
and how to apply what theyve learned to our own
work.

Mobile - Recently New

24
Technology and Already a
Commodity?

26 QCon London
2015 Report
This eMag discusses some familiar and some not too
familiar development approaches and hopefully will
give you a helping hand while defining the technology
stack for your next mobile application.

23
This eMag provides a round-up of what we and some of our DevOps Toolchain
attendees felt were the most important sessions from QCon For Beginners
London 2015 including Microservices, Containers, Conways
Law, and properly implementing agile practises.

This eMag aims at providing an overview of an example

set of tools that would constitute a typical toolchain.
These are popular tools today, but you should look at
them as illustrations of the kind of tasks and workflows
you might need to perform in your organization as you
move along a DevOps path.