

Escaping the Cycle of Technical Debt - KyleBrandt
http://blog.serverfault.com/2012/02/07/escaping-the-cycle-of-technical-debt/

======
csomar
The title is misleading. It starts with the topic of technical debt, to
conquer another issue which is performance. Now, I know that performance is
important, but I'm looking for articles in technical debt. Give me the right
title.

Technical debt may seem strange. It's not obvious at first, when you are young
and adventurous. This is especially pronounced when you are selling products
per license and guaranteeing free bugs fixing and some (even limited) support.

When I started, I didn't know it. I built the product and made the math of
hours spent building, and hours to be spent on maintenance. It worked until I
figured that my product was full of bugs, and I can't fix them but need to
build it from top to bottom.

This is a technical debt. Because when your time is money, spending time on
these issues (that ought to be fixed before selling) is like spending money.
And it can get expensive to the point of shutting down the whole thing. Yes,
you sell, you are profitable, you have zero costs (it's downloaded software)
but you go bankrupt.

~~~
InclinedPlane
One quibble, spending time isn't "like" spending money, it _is_ spending
money. It costs money to make software because developers spend time working
on software. Time = money = budget.

~~~
otakucode
This seems straightforward and true, but in specific cases you should look
deeper. A surprising number of software developers work unpaid overtime, and
give their time to their employers for free. As well, the amount of
producitivity that computers enable an individual to produce, when compared to
how much the individual is paid for that, reduces time to being almost free.

If you only have to pay someone $20/hr, but every 400 hours or so they pop out
some tiny bit of work that ends up being worth $500k in savings, you've only
paid $8k for $500k profit. The 'cost' in terms of developer time is so
stupendously cheap that worrying about wasting it is really a waste of effort.

Now, if developers realized the amount of money they save/made their company
and they expected to be paid on the basis of THAT value, instead of simply
settling for 'market rate' wages (which never take into account the actual
value the position creates at any point), then it would make sense to worry
about such things. But, developers, like most employees, are kept very
ignorant of their impact to the company. Those who actually get to see their
fiscal impact and who can't be lied to (top level managers, sales people)
don't make market rate wages. It is their time you should be worrying about.

------
CodeMage
This is an excellent post: short, to the point and helpful. However, I find
the title slightly misleading. Performance is not the only form of technical
debt. Arguably, there are forms that are even worse than performance. If
you're looking for the generic recipe for breaking out of the typical
technical debt nightmare, the solution isn't in this post. Doesn't mean you
shouldn't read it, though ;)

~~~
yread
I agree. I always considered maintainability to be the main part of technical
debt. You do it quickly, but only you understand how it works. Then you
refactor it (preferably against [unit] tests). Nobody wants unmaintainable
code in their codebase yet it sometimes appears...

The only aspect of performance I would consider technical debt is how your
software scales. When you have 2x as many users will the load be 2+epsilon
times higher or 10 times. Or what if 10% of your users performed some action
at the same time.

------
jobu
"Broken gets fixed, but shitty lasts forever"

------
InclinedPlane
Bad code is a time sink.

Think about it. Good code doesn't have many bugs, it's easy to maintain,
extend, and improve, and it's easy to review manually to look for defects.
Thus, modifying good code or interfacing with good code takes very little time
and very few attempts to get right.

So where does our time get spent? Working with and using bad code of course.
Bad code is hard to modify and extend, but almost all code needs modification
in its life. Modifying bad code takes a lot of time and effort because it's
crufty and broken so it tends to at best maintain or lower the overall code
quality while adding features. Bad code spawns bad code. Poor APIs lead to
clumsy workarounds and hacks in client code, which trickles down as technical
debt elsewhere. Bad code tends to be awkward and difficult to follow so in
order to ensure quality it needs to be tested thoroughly, which takes a lot of
effort.

Technical debt has interest, and it's typically a pretty high rate. Pretty
soon you find your development velocity is slowed because all your time is
absorbed by dealing with bad code.

My advice: identify bad code and be ruthless about setting aside dedicated
time to eradicate it. Have a policy or culture of constant refactoring when
anyone makes a code change. Keep track of your major pain points and strive to
solve them. Sometimes that's not possible if you are in a giant company but
sometimes you can get a lot more done than you'd imagine. The best teams are
the ones who spend their time writing more good code to go with existing good
code, they tend to be exponentially more productive than teams who get bogged
down in firefighting as a way of life.

