

Technical Debt – What it is and what to do about it - genehughson
http://genehughson.wordpress.com/2013/11/04/technical-debt-what-it-is-and-what-to-do-about-it/

======
ChikkaChiChi
Instead of trying to quantify your technical debt, the first step should be to
determine who your technical spenders are.

I work in a company with a toxic environment where nepotism allows for
projects to absolutely derail entire projects and teams for months on end.
Ideas hit the fan like loose stool and suddenly everyone is sent scrambling to
accomplish a thing that has barely any focus other than it's a pet project.

If you can locate your spenders, then you can determine the best way to
control or excise them from the technical budget.

------
memracom
Money debt is always recorded in the books and included in a regular (monthly)
assessment of the business's value. So why do we not do this with technical
debt? Instead it gets swept under the carpet until its impact is so
overwhelming that only rigid processes and tight sprint deadlines allow new
features and bugfixes to get done.

~~~
dragonwriter
> Money debt is always recorded in the books and included in a regular
> (monthly) assessment of the business's value. So why do we not do this with
> technical debt?

Because money debt is unambiguously quantifiable, while technical debt is not.
If we had even remotely good methods of quantifying technical debt, we'd
probably be much better at avoiding creating it -- as it is, the immediate
cost of not having the desired features _today_ is readily apparent, the
deferred cost in the form of technical debt of doing it in a slipshod manner
rather than taking extra effort to do it right is far less clear.

~~~
genehughson
Pricing risk is difficult, but that shouldn't hold you back. It's an estimate,
just like the estimate of effort to mitigate. Precision re: potential
liability is less important than awareness that the debt exists.

