Hacker News Reader

Comment by keithnz | Hacker News Reader

this seems wrong, the examples given aren't examples of technical debt. Starting a monorepo isn't technical debt, changing to something else later isn't technical debt. Technical debt would happen when doing that change you delay a part of the migration, or leave out some testing because its too tricky, or anything you are delaying till some time later that ideally should be done now.

View on HN

There's a difference between deliberate technical debt and accidental debt. More often what I have seen is accidental debt - not a deliberate choice between tradeoffs but accumulation of poor quality code and architecture due to inexperience, poor time planning, and constant changes in business direction that are common to new companies.

Making conscious trade-offs isn’t tech debt.

If business requirements change, that isn’t tech debt.

If you don’t implement new high-level (business) insights or postpone this work, you are accruing technical debt. At least, that’s what Ward Cunningham stated.

Technical debt is the gap between what you think is best and what you actually implement. If you think a test should be added, but you don't write one yet, that's technical debt. If you feel like separate repos would be best in the future, but you choose a monorepo for now, that's technical debt.

It depends. If you knew that you would certainly need a distributed architecture in the future but you still implemented it as a monorepo, then it's technical debt. Obviously it's not if the requirements have changed.

that's not really technical debt, if mono repo makes sense at the moment, and you will change later, it's not technical debt, that's just a choice, there's no debt. While you are using the monorepo, there's nothing to "pay off". If after you make the change, but you don't do it fully, then you start having things to "pay off".

> if mono repo makes sense at the moment

That's the opposite of what I wrote. My scenario was you knew that it didn't make sense for that project but you still did it because of time/budget/resource reasons. You start paying off the day you can't scale it anymore.

time/budget/resource reasons means it DOES make sense. It's like saying you want a Ferrari, but at the moment all you can afford is a bicycle... its a start, it gets you going, and it maybe not what you want long term, and you can't realistically go long distance, but it gets you started. They are just strategic decisions, not technical debt.

That's the definition of technical debt. You "borrow" from your tech budget because of other restrictions, then you pay your debt.

If you make a bad choice with no valid reason then it's just a bad choice, not technical debt.

Distributed architecture and mono repo are really orthogonal issues.

Reply on news.ycombinator.com