Hacker News Reader

Comment by bravura | Hacker News Reader

I'm surprised the author, given the thoughtfulness of much of the post, didn't decide to model tech debt, since then accumulated debt would be quantified frequently (if inaccurately).

Especially since they are optimizing for value-add work versus paying down tech debt, which the author acknowledges is what got the engineering org into a paying down tech hole that they are currently mired in before the author's tenure. For this reason, accumulated tech debt should be modeled in their bar charts too.

This is far preferable to letting tech debt grow and fester for several years. In a way, I find this possibility almost a regression by the author and possibly irresponsible. I.e. they didn't patch the underlying core issue (rest of org not understanding or assessing tech debt as a liability), and instead push a quantitative measure that actively encourages taking on unmeasured tech debt.

View on HN

How do you quantify technical debt?

It doesn't seem possible to track percentage of code as debt. You can't put a comment on code and call this block either debt or good.

One way could be to measure different activities. If you spend time solving a lot of bugs (muda) then where are those bugs?

If they're in the same old code, does that code need rewritten? If they're in new code, is that code being written in a good way? Can better testing catch these?

"Technical debt" seems as hard to measure as developer productivity. It seems you need something you can actually put on a bar chart to measure the effects of having technical debt.

You need a way to assign technical debt to a process or practice, then you can evaluate the cost of that process over time.

Could be something like... Our team spent 500 hours fixing bugs introduced during overtime, and we spent 250 hours of overtime to introduce those bugs in the first place. So an additional hour of overtime will likely introduce 2 hours of technical debt.

Or maybe... Code written using inheritance hierarchies creates 40 minutes of muda per hour, but using composition only creates 20 minutes. Or... every hour spent on throw-away prototypes reduces muda by 2 hours.

And all projects are comparable among each other, standardized for it to be possible to come up with measurements like that?

It feels like nightmare to have to come up with those hours or measure them in some way.

Anything else besides intuitive guesses by engineers won't work, because to have it any accurate at all would require perfect time tracking and understanding of all the nuances or it will just be a biased metric, which can be whatever you want it to be.

Like, the things you are spending your time on are never clear, there are never clear labels or patterns and the things you spend most time in the future can be very unexpected, the more so, the larger the org.

Isn't that the "muda"?

Reply on news.ycombinator.com