
Embrace technical debt - nreece
http://startuplessonslearned.blogspot.com/2009/07/embrace-technical-debt.html
======
apinstein
Technical Debt is a broken metaphor. It's _almost_ right, which is why it
resonates, but it's a bad mental model for the problem it tries to describe.

There are real negative consequence of applying a "broken mental model" -- you
end up doing the wrong thing when you live by the model!

Why is technical debt a broken concept? Real Debt is incurred proportionally
to the asset bought with it. In technical debt the debt is proportional to the
trouble it causes, not the value delivered. Also, it implies that the only way
to get rid of the debt is to make a big investment. In reality, you can just
throw away code and the debt disappears. Not analogous with real debt!

It should've been called _technical drag_. Properties of drag that are
appropriate to the metaphor: \- You get value based on the amount of input
work, but it places a drag on the overall progress towards the goal (support
load, architectural coupling). \- You can reduce the drag of an existing
component by investing to refine it. \- New components typically add more drag
than existing ones. \- Little bits of drag here and there add up to a big
problem \- Removing unused functionality reduces associated drag without major
investment

Thoughts?

~~~
tome
_In reality, you can just throw away code and the debt disappears._

Technical debt is closer to this than you might think. This would be "going
bankrupt" on that code. It's like having a loan secured on the value of some
object. If you want to default on the loan, you lose the object, nothing more.
(Although you don't lose your good credit rating as you would with real debt!)

~~~
apinstein
Um, what? No! This is exactly the type of logic-wrangling that happens with
bad mental models.

It is _not_ going bankrupt on that code, When you go bankrupt, there is a huge
penalty to your credit! If you stop maintaining code that no one uses, the
drag goes away and there is no downside!

Deleting code is fun. Going bankrupt, not so much.

~~~
nostrademons
When you "go bankrupt" with code, there's often a huge penalty to your user
experience. Presumably that code existed so you could _do something_ and make
things better for your users. If you take it away, or even stop maintaining
it, you're doing less for your users.

This is why I like the "technical debt" metaphor more than the "technical
drag" metaphor. Technical debt acknowledges that there's an outside user who's
presumably paying you for the project. You can choose to satisfy them better
_now_ , but it's at the cost of satisfying them less _later_ , or even
regressing and making things _more_ painful for them as you take away debt-
ridden features. Just as how financial debt lets you invest _now_ and satisfy
the immediate customer better at the price of paying it off later.

"Technical drag" implies that forward motion is inexorable, and the only
variable is the rate. This is not a given in software; I often try to use old
versions because I know that new ones will be slower, more cluttered, and
buggier.

~~~
swombat
_When you "go bankrupt" with code, there's often a huge penalty to your user
experience. Presumably that code existed so you could do something and make
things better for your users. If you take it away, or even stop maintaining
it, you're doing less for your users._

Did you read the article? Eric Ries gave a good example of a piece of code
that they had built, with technical debt, and which they threw away because it
had little or no customer value.

In practice, I see it happen all the time. There's functionality in most
applications that could probably be removed with little impact to user
experience. Even on Woobius there are some chunks of functionality that are
not much used at the moment and that we could remove without much impact on
the users.

~~~
nostrademons
Of course, but I was responding to the comment, which was about calling it
"technical debt" vs. "technical drag".

We could just call it "technical venture capital". You make a large number of
investments, the majority of which have absolutely no value to consumers. You
abandon the losers, sometimes after much handwringing. It is usually
impossible to tell a priori which features will be winners and which will be
losers, though experience and good technical judgment can improve your odds.
You can invest more in promising features to bring them to market quickly.
Doing so usually introduces lots of warts into the codebase which will have to
be fixed later - but then, you'll have lots of money later to fix them. But
you have to be careful to avoid investing too much too early, before you've
seen how the feature will actually play out, because then you build a giant
monstrosity that collapses under its own weight before it can ever get to
market.

Or we could accept that all metaphors are imperfect. I'm going to continue
calling it "technical debt", because most people - even if they haven't heard
of the term - have some idea what I'm talking about when I mention it.

------
jimbokun
"As in many scalability decisions, we’d have been much better off investing in
agility, so that we could change the architecture in response to actual
customer demand, rather than trying to predict the future."

With a poor design, it can be more difficult to make changes to improve
scalability. If you do not have abstractions and information hiding that allow
you to switch out algorithms, libraries or systems for ones that scale better,
you will need to rewrite a lot more code in order to to scale.

"Yet other agile principles suggest the opposite, as in YAGNI and
DoTheSimplestThingThatCouldPossiblyWork."

My concern with the premise of this article is that some might use it as a
license for sloppy code. YAGNI and DoTheSimplestThingThatCouldPossiblyWork can
be accomplished with code that is concise and clearly expresses intent. In
fact, you could argue that these principles demand such code. I've seen a lot
of code with many lines that accomplish very little, and that kind of
"technical debt" never pays off, in my experience.

------
jon_dahl
I tell my clients that cutting corners is "an hour of savings today, 5 hours
of cost tomorrow". I've worked on too many projects that raced to cram in
features by a deadline, and ended up with a sloppy app that took forever to
maintain and made developers miserable. Far better to take a measured pace and
ensure that rapid development can happen in months 12-24, not just months 1-3.
Especially in startups - startups are a marathon, not a sprint.

Of course, cutting corners isn't the only kind of code debt, and the author
makes some good points. If you're spiking something or prototyping it, and
intend to rewrite or throw away, technical debt might be a good tradeoff.

I also take issue with this:

 _Early on at IMVU, we incorporated in tons of open source projects. This was
a huge win... The downside was that we had to combine dozens of projects whose
internal architectures, coding styles, and general quality varied widely. It
took us a long time to pay off all the debt that incurred – but it was worth
it._

The more you can offload to open source libraries or third party APIs, the
less your application has to do, and the less you have to maintain. If the
library or API sucks, then sure - you're incurring technical debt. But if the
library/API is good, or you can contribute to make it good, then it's a win
all around.

~~~
nostrademons
Sometimes it makes sense to take that hour of savings today at the cost of 5
hours later, though. I've been on projects where we knew a competitor was
coming to market soon, and sacrificed a bit on code quality to beat them. We
ended up launching 2 weeks before they did, which meant that when they finally
did launch, the press was all like "But can they compete with Company X, who
launched a similar feature two weeks ago?" Doing things the right way would've
added about another month and a half - if we'd paid that cost up-front, the
press reaction may've been "But their relevance may be fading, because Company
Y launched similar features a month ago."

~~~
jon_dahl
I agree. You really have to be disciplined to do this, though, because there
is always something in a startup that needs to be done _right now_. Rushing
for a month and then taking two weeks to refactor/improve code is fine. But
doing the same for 12 months is a big gamble.

------
wynand
This post makes a good companion to a post of a couple of days ago: "Why Do We
Keep Building Tightly Coupled Software"
(<http://news.ycombinator.com/item?id=705863>).

A common theme in the comments to that story was that there are costs
associated with loose coupling. Not making loose coupling a first priority
means that one will incur some technical debt; but given that one gets
something that will work sooner, this is often a good call.

Does anyone know of any software teams that explicitly talk about their
technical debts and that have plans for "downpayments"?

~~~
sokoloff
We do. Our [internal] wiki article on technical debt explicitly covers
examples, guidance on when to intentionally take on debt, how to document and
measure it, different "grades" of it, and how to plan to retire it.

There are then per-application technical debt pages for specific details on
our "portfolio" of debt. (We're also a fair bit larger than most startup dev
teams, so having this level of formalism is more appropriate in our case than
say just a whiteboard somewhere...)

~~~
darkxanthos
I would love to know your formal approach (or as close to it as possible). I
personally see technical debt as debt to be leverage but I lack the means to
track it so that we are always aware of how much debt we have.

~~~
sokoloff
We (or at least I) also think of it as leverage. We also have a very strong
80/20 ethic, so we don't have particular qualms about using the leverage that
this debt can provide.

We don't do anything magical; there is no secret sauce, noe no spreadsheets
with formulae or anything fancy; it's literally just a series of wiki articles
and Jira tickets with issue type "Debt" so we can easily find the documented
debt and make plans when/whether to retire it.

So the concrete formal mechanism is "use your bug tracking system and flag
them somehow so you can filter/search for them."

I will add some additional links that our top-level debt page references as
useful:

[http://chrissterling.gettingagile.com/2008/10/20/managing-
so...](http://chrissterling.gettingagile.com/2008/10/20/managing-software-
debt-article/)

[http://enterprisearchitect.typepad.com/ea/2008/10/watch-
your...](http://enterprisearchitect.typepad.com/ea/2008/10/watch-your-
amou.html)

<http://www.youtube.com/watch?v=pqeJFYwnkjE> (Video: Ward Cunningham on
technical debt)

------
jasongullickson
Weird, I was just trying to explain this to a manager yesterday, I need to go
look for hidden microphones...

...I've tried in the past to explain this to others using retail "shrink" as
an analogy. For those unfamiliar with the term, as I know it, the idea is that
you assume a certain percentage of loss (in my experience, as shoplifting in a
music store) and by writing that off, it allows you to focus your energies
where they have more impact on profit. For example, placing the lowest-margin
items in the most vulnerable parts of the store to deter theft of items where
you really make money.

I'm glad someone took the time to write up a better explanation that I can now
refer to.

~~~
lallysingh
LiveScribe pens.

------
wglb
This is a good article and it resonates with one of pg's essays in which he
says that sometimes in building a project you worry about security later. I
think it is also related to the early optimization error. You don't know what
you are ultimately going to build until you get feedback from customers/users.
So don't overengineer/optimize something that you aren't going to use/doesn't
need it.

------
kreem
I think this is a good article, but most times companies do not even know they
are incurring technical debt, and that is the first step before you can start
working with technical debt in an intelligent way.

