Hacker News Reader

Comment by trwhite | Hacker News Reader

The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.

View on HN

Never in the history of software has that line done anything but gone up. Software naturally gets more complex as it grows to handle new features, new edge cases, more users, more backwards compatibility, etc.

This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.

Most software has short periods when it goes down. And then go up again.

I think the correct framing is that it should go up only with the logarithm of the code's age or size. If it's going any faster, you have a problem.

That would work really well if it were possible & straightforward to consistently estimate complexity story points, independently of time. Even better if you could (ditch Fibonacci, necessarily, and) objectively match each complexity value in linear scale relative to the others.

In order that you could say 'it's now taking us twice as long per complexity point as it was last year', and know that that was meaningful.

Agreed, and I also think measuring "rework" helps. For a car company, rework could be recalls or warranty claims. For a software company it can be outages or incidents, especially those with major customer impact.

I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.

That's true. So I suppose I would amend to say "if the line is exponential". At the company I work for presently we try to adopt "painful now, pleasurable later".

Reply on news.ycombinator.com