
How to Leverage Technical Debt - mortimerwax
https://medium.com/startup-guide-anti-patterns/how-you-can-leverage-technical-debt-why-you-should-4ec48a387751
======
mikekchar
The biggest thing I think people need to know about technical debt is that it
must be used to create growth. Consider the situation where you go to the bank
and ask for a loan. You tell the loan manager that you will spend the money on
pizza parties. Unless you are in the pizza business, you are unlikely to
secure the loan. Loan managers want to know how you are going to use the money
you gain to generate growth and ultimately pay the money back (with interest).

Now consider technical debt. When you go to your architect and say, "I want
you to hack something so that we can get it out the door a month earlier",
your architect should respond with, "What are you going to do with that time I
give you?" If the answer is, "I just think we need to get to market as soon as
possible", then you are doing the technical debt equivalent of spending
borrowed money on pizza parties.

As a reasonable architect, I need assurances that I'm going to be paid
interest on the loan. If I give you a month, I'm going to need a month and a
half back. You need to explain to me how you are going to make that kind of
time. If you can not, then the business plan needs rethinking. No respectable
banker would say, "Oh, there is a 0.1% chance of success if I lend them the
money, but a 0% chance of success if I don't. I'd better lend them the money!"
He says, "Come back when you have a better business plan".

The other annoying issue is that complexity in software can grow
exponentially. So the cost of repaying the debt can quickly outstrip your
ability to pay. Imagine borrowing money and having an interest rate of 1% for
the first month, doubling every month. Seems like a wonderful idea to borrow
the money, but you better pay it back _fast_.

The problem with technical debt is not that you must avoid it at all cost,
it's that you must think very hard about whether or not you can afford it. If
you can't, you should avoid it. If that puts your company out of business,
then you need a better business plan.

~~~
dreamfactory2
I don't disagree with the gist of your comment but time to market is generally
massively undervalued (and particularly by technical folk). It's more often
than not a great reason for taking on tech debt (not to mention that early
releases also constrain scope to smaller chunks).

~~~
lumpypua
I totally agree that time to market is hugely important.

The dynamics of getting to market are complicated and I don't agree that tech
folk undermine them to any special degree. If you're an engineer with a few
years experience, chances are you've been smacked by being too conservative or
too loose with tech debt. Good contextual use of debt is a key part of the
"senior" in any senior engineer. I'm happy to be "sloppy" and fast at the
right moments.

My experience has been that business people value time to market, but only if
they can offload the costs to engineering by taking on tech debt. When asked
to put their money where their mouth is and pay for more engineers or cut
scope, often the business side will balk. It's an annoyance when non-technical
leadership perennially sees tech debt as a way to get a free lunch. Ain't no
free lunches.

------
yanilkr
The best way I learned to deal with technical debt is to package it into
securitized collateral debt obligations and find a product manager who can
structure them into traunches and then find a QA manager who can rate these
traunches and set up a regulatory framework with in which project managers can
provide liquidity necessary to deal with it. If that does not work try to find
an executive who can issue an Asset backed commercial paper that developers
love. Now at this point the debt is handled so well it no longer is an issue.

~~~
chris_wot
The Freddie Mac style of development. Awesome!

------
jondubois
I think technical debt in the right places is fine. You have to know when it's
OK to cut corners and when it's not. Novice software developers will sometimes
think that all technical decisions are equally important, but that's not the
case. Some technical decisions are way more important than others.

For example, I've found that anything related to the general architecture of
your app is very important and you should almost never cut corners in those
areas - This includes decisions related to what framework you will use, the
structure of your URLs/links, how your app will use/reuse components, database
engines, etc... These are fundamental engineering decisions and if you rush
those, you will likely suffer for many years.

On the other hand, I found that it's generally OK to hack together the
contents/features of individual pages within an app - If you mess up one page,
you can always rewrite it fairly quickly.

Software is like a tree - If some of the leaves become diseased and start
falling off - That's OK; so long as the tree's trunk is healthy and sturdy,
the leaves can grow back quickly. If the trunk is rotten and the whole tree
falls down - You will have to start again from scratch... If it doesn't crush
you on the way down.

------
pan69
I don't see technical debt as a problem, I see the lack of refactoring as part
of a software teams culture as a problem.

Technical debt will be incurred, if you like it or not. Even if you spend a
long time on architecture and abstractions, developing software is a process
and the "fantastic" architecture you created a year ago is now hopelessly
outdated. This happens because over time your insight into the problem domain
increases which will give you a better understanding on how to approach the
problem which will lead to better decisions on all sorts of things regarding
the software you're writing.

Having refactoring as part of a software development team culture can help you
manage technical debt. If you assume that the code itself isn't precious but
the experience of the developers writing the code is, then you can move
forward. You can have refactor sessions at regular intervals, e.g. every
Friday afternoon or a whole Friday every fortnight, whatever works for you and
your team.

In a refactor session the whole team can work together to make the software
better; many eyes make all bugs shallow [1]. It also give an opportunity to
create better synergy and banter between team members.

[1]
[https://en.wikipedia.org/wiki/Linus%27s_Law](https://en.wikipedia.org/wiki/Linus%27s_Law)

~~~
tcopeland
> Technical debt will be incurred, if you like it or not.

Right on. I've seen discussions about feature toggles which suggested not
using them because they led to an explosion of code paths. But that won't
happen if you delete the toggle (and the toggled-off code) once the a/b test
ends or the feature is rolled out or whatever. It takes discipline and a
culture that encourages that by being willing to review / deploy those
changes, though.

------
bboreham
The financial equivalent is more like selling an unhedged option than
borrowing - the cost of paying back will increase unpredictably based on what
other people do, not at a steady rate like interest.

------
ColinDabritz
I enjoyed the article, although I disagreed on some minor points, some of the
broad strokes seem solid to me. Very thought provoking.

I think it's interesting to contrast the thrust of the article with Ward
Cunningham's original definition of technical debt:
[https://www.youtube.com/watch?v=pqeJFYwnkjE](https://www.youtube.com/watch?v=pqeJFYwnkjE)

Wards definition is much more about the differences between the current
implementation of the software and your understanding of the problem,
particularly as your understanding changes over time.

He explicitly says that "tehcnical debt" is NOT an excuse to write known-to-
be-poor code, which is why I disagree with the //TOBECLEANED approach.

This change in perspective shifts the point of view quite a bit. In some ways
this problem defines a startup, your biggest problem is that you don't
understand your problem. It's somewhat likely that you won't even have the
same problem you'll successfully solve later. The first points are salient
here, focus your engineering efforts on the things you don't understand yet,
and the minimum support it needs to be viable. Shorten your feedback loop as
you navigate the things you do not yet understand.

In this light, a startup is actively SEEKING technical debt, because it
represents gaining understanding about a problem, and exploring that space
quickly. This doesn't mean you have to "cut corners" and do things you know to
be flawed, but it suggests focusing on small 'forays' into the unknown,
gaining understanding quickly, and being willing to throw away your
exploration for a new one if it isn't working. Then once you find a problem
you start to understand and seems like a viable direction, you have a body of
'technical debt' that is the work you need to do to bring the software to your
new growing understanding.

It seems like being willing to throw away the exploration if the direction
isn't working out is a key advantage of a startup, along with the quick
iteration times and lean support for explorations. This is why I dislike the
suggestions of writing known-bad code. You're slowing your exploration down,
but you aren't gaining understanding of the problem. It's junk debt, not
technical debt. You can carefully minimize the supporting infrastructure your
exploration requires, and avoid writing extra code, but you can't just slap it
together.

It's not enough to flail around building as fast as you can, you have to
deliberately learn and explore problems and understanding as you go, and
evaluate which ones to put more exploration into and which to abandon. To me,
this is the core work of a startup that differentiates it from established
companies who are executing on a reasonably well understood problem. The
(sometimes gradual) transition happens when you stop exploring, and start
focusing on clearing the technical debt from your current exploration.

Thanks for sharing the article, I enjoyed engaging with these ideas!

------
purpled_haze
The development team at a company I worked for stated they had technical debt.
They said they would spend the next year eradicating it. Then didn't even try.

You want to know what technical debt really is? The result of procrastination
in the realm of tech.

It's not even worth giving it a funny name like technical debt that upper
management doesn't really get. They understand what procrastination is.

You can't spin procrastination. It is what it is.

~~~
chatmasta
Is someone who takes a financial loan procrastinating paying their bills? Or
are they solving a short term problem the best way they know how?

Procrastination may lead to technical debt, but it's not the only source. The
biggest source of technical debt is insufficient planning for future product
requirements, leading to old code blocking new features.

That's why the concept is called "debt," because it's as if you took out a
loan on the first iteration of the product, and then many features later,
you're still paying interest on that loan.

So no, technical debt is not purely the result of procrastination. Sure,
procrastination, especially in the planning stage, can create technical debt.
But even the most productive people, those mythical creatures who never
procrastinate, are vulnerable to creating technical debt for themselves. In
fact you might argue they're _more_ likely to create technical debt, if they
choose to skip the planning phase and jump right into coding.

~~~
bpchaps
I don't know if "debt" or "procrastination" are really the correct words. It
seems to be somewhat in the middle of the two, where the problem comes from
"We'll take care of that in the future." where the future never comes.

A good example of that might be in log refactoring. I recently quit a place
for what amounted to a complete lack of interest in correcting bad logs. After
spending 8 hours trying to fix some non-prod issues and being completely
halted by timeout errors, I was told "Those errors are fine, they even happen
in prod (!!!). We talked about fixing it, but agreed to do it way further down
the line." So, not really procrastination or technical debt, but something
similar since it's 'debt' and 'procrastination' are simply symptoms of a
larger problem.

