Hacker News Reader

Comment by richmarr | Hacker News Reader

> ...lack of transparency about design quality

Totally agree.

Technical debt isn't a problem as long as the team has good communication & low levels of political behaviour.

IMO articles like this that paint Tech Debt as a universally negative thing (without trying to balance the view, or mention the context in which the tech exists) do more harm than good.

Update: Recommend reading "5 Dysfunctions of a Team" for guidance on improving communication and reducing political behaviour in an organisation.

View on HN

Funny I get the opposite take on this article in terms of meaning, yet I still think it is off base.

"Technical Debt" is a dangerous analogy because most of what people call technical debt would best be called "ignorance" or "wishful thinking". Debt is a complex social invention that includes methods of accounting, a repayment schedule, etc.

MBA types will have to negotiate with banks, senior executives, the board, etc. about the debt taken on by a corporation.

Worse yet, ignorance often takes the form of overengineering, so what is done in the name of "saving time now" is often completely wasted.

It's a metaphor and it can definitely be taken too far. One of the abuses I don't care for is the notion that Technical Debt can be quantified and calculated for a code base. That's wrong in a number of different ways.

Agreed. It's another instance of making a tech to finance analogy that just doesn't hold up. It's really nice when you can just put a number on something. And it really sucks when you can't, but that doesn't prevent people from trying.

Why does the sales guy get to go play golf after closing a big deal? And yet the developer still has to show up and sit in his seat after he performs some equivalent wizardry? Because the sales guy's effort has a number attached to it, that's why.

>a complex social invention that includes methods of accounting, a repayment schedule, etc.

Isn't that the point?

There are similar reasons to take on real and technical debt, like expanding into a new market. You also come up with a "repayment schedule" for technical debt, which involves allocating time for checking/updating the documentation, refactoring code, etc.

Some people use "technical debt" to mean "no one knows how this works", but I think the actual debt there is in the documentation or the lousy quality of the code, not the ignorance.

My takeaway is that the crucial component of tech debt is the interest you pay on it, which often gets overlooked. It's not just that it takes longer to do tomorrow what you could do today, but you also face developer unhappiness and attrition.

This is just part of how you communicate about technical debt. It does not address the context, business interests, etc., but it doesn't need to. It doesn't imply anything about the value of debt, and discussing a negative aspect of it does not exclude what value it has.

> ... but you also face developer unhappiness and attrition.

I don't think this should be assumed. The unhappiness and stress around Tech Debt are directly caused by sub-optimal communication, not by the debt itself. The debt is just the stage on which the poor communication is played out.

Reply on news.ycombinator.com