
Of Debt and Decisions - spooneybarger
http://www.monkeysnatchbanana.com/2015/04/19/of-debt-and-decisions/
======
jewel
This article addresses one problem with technical debt, the idea that one day
the debt will "come due" and you'll have to fix some latent problem in a hurry
and very painfully. While that can happen, a lot of the time you can carry the
debt forward, as the article illustrates well.

The bigger problem with technical debt is that it limits or slows your ability
to do things. With real debt you have to make monthly payments and that
reduces the total amount of cash you have to spend, which reduces your
flexibility. With technical debt you "make a payment" whenever the speed you
can make changes is reduced due to bad technical decisions of the past.

For example, if you don't have tests then you can still change the code, but
you have to spend a great deal longer doing manual testing. When the
inevitable bug slips though, you have to spend the time to fix it. Since it's
often not catastrophic, non-technical management will be willing to pay a
known ongoing cost instead of an large, unknown one-time cost to remove the
problem altogether.

At my last job we were so mired in technical debt that progress had slowed to
a near standstill. It was a 20-year-old codebase running on an IBM AS/400,
mostly written in RPG (which is sort of like assembly language but for
databases.) Field and table names were limited to 11 characters. When they
migrated the product to the web, they kept the RPG code but added in a bunch
of perl. When DB2 couldn't keep up, they started adding new data to MySQL.

In all, there were 500 thousand lines of code in the system. Adding a field to
the most important table was a 20 hour process, including a late night or two
to issue some commands while the system was doing its nightly maintenance.
There were five programmers while I was there, and the majority of our time
was spend keeping the system going. There was never time allocated for
cleaning up the existing system, so instead we'd just try and add features
without making any schema changes (or adding fields in MySQL instead, as I
mentioned before).

~~~
ajtaylor
You beat me to it. While you can "avoid" the debt by working around it, you're
still paying by having to implement the workarounds rather than being able to
do it in a more straightforward manner. All you're doing is swapping interest
costs with opportunity costs. The piper has to be paid, one way or the other.

------
lisa_henderson
I love this story. It offers an important reminder about how our industry
really works.

Whenever a practice becomes established as a "best practice", such as
automated testing, then the next question that arises is "Why isn't everyone
doing this to the max?" And folks that don't follow best practice generally
feel guilty and keep quiet. But those who follow fashions in tech tend to
underestimate the opportunity costs of doing so.

This is the moral of the above story, and it is a good one:

"Hopefully you are horrified by all things we didn't do that are now
considered best practices. No reproducible builds, lack of automated testing,
creating and then repeatedly sidestepping technical debt. For a long time,
that is how I told these stories: as horror stories that came complete with
hand gesticulations to emphasize the "can you believe I had to do that?"
nature of it all. Here's the thing though: we were making money. We were
growing and supporting ourselves."

I spent this winter working for a startup that had the opposite problem of
most startups. The CTO was a serious Pythonista, and he wanted to ensure that
all the code was written was of high quality. He wanted to avoid the build up
of technical debt. There were 9 programmers on the team, using Python on the
backend and AngularJS on the frontend. And he felt they could invent a new way
forward, in terms of combining Python and Angular. And so the team was
reinventing the whole Python stack: they had their own serialization
libraries, their own database libraries, their own web server, their own
authentication system. Adding each new feature lead to very long meetings in
which people were encouraged to be thoughtful -- everyone was suppose to think
about the long term consequences of whatever design was chosen. In some ways,
it was a careful style, but it had a cost: the 9 developers spent more than
50% of their time on infrastructure questions that had already been solved
elsewhere. In terms of meeting the real needs of this small startup, the
startup might has well have had a team of 4 developers -- the money paid to 5
of the developers was, in a sense, an act of charity being offered to the
Python community.

We've all ready endless stories about startups that cut corners, ran up
technical debt, and eventually succeeded. We read much less often about
startups that doing everything perfectly and then become successful. And that
suggests that, for startups, cutting corners is the more adaptive path.

~~~
fsk
I've seen that a couple of times, startups that insisted on rolling their own
code for everything instead of using standard tools.

I worked one place that wrote their own build tool (instead of using Make or
Visual Studio). They wrote their own templating engine, instead of using PHP
or ASP. They had their own version of MFC and String library, with everything
implemented slightly weird, so I had look at the source whenever I needed to
know how it actually worked. It was nuts. They spent a year writing their own
tools for everything, which was a year they didn't spend working on the
product.

~~~
kyllo
I know of a non-software industry company that for a brief time seriously
considered implementing its own proprietary relational database engine. Thank
god that project got killed.

------
Illniyar
"Technical debt only hurts if you have to pay it back"

To continue the "debt" metaphor, when your product dies, it debt dies with it
(or if you switch technologies, you might get a 'debt relief').

So for the thousands of startups and products that disappear or get pivoted
before they can mature - it might be worth it to bet on not paying technical
debt.

~~~
gwern
Perhaps you could call that 'technical bankruptcy', as in, "we're declaring
technical bankruptcy and writing an entirely new version".

~~~
decwakeboarder
"technical write off" is probably a better term.

~~~
TheOtherHobbes
I don't think the debt metaphor works, because there's no real or implied
creditor. (Except maybe time or entropy?)

Technical mass might be better. The code keeps accreting, developer efforts
orbit around it in ever-decreasing circles, and at some point it becomes
impossible to escape from it.

But is this really a technical problem, or a documentation and specification
problem? If there's no separate formal model for the project, the code _is_
the documentation, and that's never a good place to be.

------
zby
For me the moral from that story is that in a mature market there is a lot of
accreted wisdom and best practices - but in the early stages you don't have
that and you need to trudge along with whatever you have. And judging those
early projects through the lenses of the learned wisdom is silly.

------
aioprisan
This "Yeah we had a lot of technical debt but we kept finding inventive ways
to sidestep having to pay it. The debt metaphor that we’ve adopted is
misleading. You don’t always have pay off the debt you created; you can work
around it and avoid ever having to pay it off. Technical debt only hurts if
you have to pay it back."

~~~
afarrell
[http://www.higherorderlogic.com/2010/07/bad-code-isnt-
techni...](http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-
debt-its-an-unhedged-call-option/)

------
ExpiredLink
tl;dr?

~~~
bobbles
Technical debt is only worth caring about if you have to 'pay' for it one day

