TITLE: Technical Debt as Consumption or Investment
AUTHOR: Eugene Wallingford
DATE: May 09, 2010 11:53 AM
DESC: 
-----
BODY:
A couple of days ago I
<A HREF="http://twitter.com/wallingf/status/13613570669">
   retweeted</A>
a one-liner from
<A HREF="http://twitter.com/unclebobmartin">
   @unclebobmartin</A>:

<BLOCKQUOTE><EM>
All developers know that bad code slows them down;
yet nearly all insist that writing bad code is faster.
</EM></BLOCKQUOTE>

This struck me as one of the themes I'd like for my
agile software developments students to pick up on
this month.  It's tempting to write code quick and
dirty so that you can feel as if you are ready to
move on to the next task.  But I as I
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-04.html#e2010-04-30T10_17_43.htm">
   mentioned here recently</A>,
"dirty remains long after quick has been forgotten".
The feeling of completion is an illusion, one that
we end up paying for later.

A
<A HREF="http://twitter.com/marshmellow1328/status/13615087319">
   recent student</A>
commented that this is the traditional trade-off
between "pay now" versus "pay later":

<BLOCKQUOTE><EM>
I'd compare it to buying a car today using a loan
versus paying outright next year.  It's cheaper if
you're willing to wait, but can you?
</EM></BLOCKQUOTE>

This is an apt analogy, because it allows us to
peel off a layer and consider the decision at a
deeper level.  For example, if I can borrow money
at a lower net interest rate than I can earn
investing my money elsewhere, then it makes sense
for me to borrow.  This is a facet of financial
borrowing that I think we can learn from in the
context of software development.  If we can borrow,
in the form of technical debt, at a lower net cost
than the value of the benefit we can accrue by
putting our efforts elsewhere, then it makes sense
for us to incur the technical debt.

Seth Godin wrote recently that
<A HREF="http://sethgodin.typepad.com/seths_blog/2010/05/consumer-debt-is-not-your-friend.html">
   consumer debt is not your friend</A>.
Thinking in this way about software development,
we can contrast borrowing for <EM>consumption</EM>
and borrowing for <EM>investment</EM>.  Taking on
"consumer" technical debt is a sucker's bet, a
losing proposition.  This is the sort of debt that
agile developers rightly warn us about.  Rushing
through a story with inadequate testing or with
inattention to the shape of the system after we
add our code -- just so that we can make a tick on
the burndown chart and get more stories done --
this is a habit that eventually buries a team in
an avalanche of debt.  Pretty soon, we can barely
keep up with the minimum monthly payment, and we
watch our total debt grow faster than we can add
new value to the system.  The result is inevitable:
bankruptcy.

However, this analogy tells us that there may be a
kind of debt that we should be willing to take on.
As I described my own thinking above, if I can
borrow money at a lower net cost than I can earn
investing elsewhere, then it makes sense for me to
borrow.  Godin writes of borrowing in order to
improve your productivity or to buy things that go
up in value.  In the software development world,
this is what I call <B>investment</B> technical
debt.  If a team makes a thoughtful, conscious
decision to let a part of the system fall out of
compliance with its usual standards for coding,
testing or design <EM>because doing so lets them
create greater value in another way</EM>, then
they will be better off in the future for taking
on the debt.  This is investment, and done well it
can pay.

This is the sort of debt that Kent Beck has written
about in recent months when he dared to say that
it might be okay
<A HREF="http://www.threeriversinstitute.org/blog/?p=187">
   not to write a test</A>.
He has taken a lot of grief from some XP folks,
who seem to fear that talking about not following
agile practices to the letter will give other
developers license to do the wrong thing under the
mantle of Beck's advice.  I feel for those folks.
Investment can be dangerous.  People lose money in
the stock market all the time, and developers drown
in technical debt all the time.  It is important for
beginners to learn solid fiscal habits, and good
development practices, before venturing too far into
the world of investing.

But Kent is speaking truth, the same truth my student
alluded to when raising the pay-now versus pay-later
trade-off.  With experience and expertise, developers
<EM>can</EM> begin to take on technical debt for the
purpose of investment -- and not only survive, but
thrive as a result.

Of course, it is essential that the investor be
as honest as possible with herself about being able
to repay the debt later.  The team must be able to
brings its test coverage back up to safe levels for
the long term, and it must be able to refactor the
system to bring its living design back up to a level
that it supports ongoing development.  Some teams like
to pay down their debt in one or a few large focused
episodes.  This is akin selling a stock to paying off
a note in whole, and I have done this in my own
programming more than once.

When I can, though, I prefer to amortize the work of
paying off technical debt over a more extended set
of development tasks.  I still think of this in terms
of a relatively quick repayment, maybe a few iterations,
because I don't want to the burden of the debt to
affect the rhythm of development any longer than it
must.  (Similarly, I would never take out a 5-year loan
to buy a car.)  But I prefer the amortized approach
because it fits better with how I want to think about
my work: always conscious of the state of the system,
always taking small steps to make my programs better.
As a creature of habit, I like to work within a set of
practices that keep me focused on continuous improvement.

That sort of development is not easy to do, or to learn.
It's one of the challenges that newcomers to agile
software development must overcome.  I think back
to another part of my student's comment: "It's cheaper
if you're willing to wait, but can you?"  I think
this points out another common choice people face
all the time: want versus need.  The consumer debt
situation in the U.S. is founded in large part on
the fact that many consumers confuse wanting
something with needing it.  I imagine that some of
the so-called software crisis has its roots in the
same confusion.  "We <EM>have</EM> to write subpar
code in order to meet our goal..." -- only to find
the team unable to meet its goal in party precisely
because it cut corners earlier.

Godin's article closes with an exhortation to resist
consumer debt in the face of temptation:

<BLOCKQUOTE><EM>
Stuff now is rarely better than stuff later, because
stuff now costs you forever if you go into debt to
purchase it.  ...  It takes discipline to forego
pleasure now to avoid a lifetime of pain and fees. 
</EM></BLOCKQUOTE>

Software developers are wise when they take this
advice to heart, too.  Investment debt is a good
idea in certain circumstances, once you have the
experience and expertise to take it on wisely,
manage it, and pay it off promptly.  Consumer debt
is always a loser.

My summer agile course is less than 24 hours away.
My mind is turning on all cylinders...
-----