[louthy]

One thing missing from your statement is that plenty of technical-debt comes from things that were done properly the first time, but since then assumptions have changed, or the business is different, or the customer's expectations have evolved, or a competitor has upped their game, etc. This makes the so called perfect solution then, imperfect now - i.e. technical debt.

There are always trade-offs, and a good partner in any team/business will help those be articulated.

One thing that is important for any engineering team is to have a certain amount of capacity either permanently dealing with technical debt, or regularly dealing with it. Judging the amount of effort that goes into fixing it depends entirely on the amount of 'interest' you're paying. That isn't always easy to measure, but a good senior engineering team will have a sense of when things are getting hairy.

The idea that it's avoidable is unfortunately wishful thinking for any project of a substance.

[TheRealDunkirk]

> since then assumptions have changed, or the business is different, or the customer's expectations have evolved

Hilarious. In the IT department(s) of my Fortune 150, they still do picture-perfect waterfall development, with outsourced teams, writing Java. The application is set in stone when it is signed off in production. Things change? NEW PROJECT. Another 3 YEAR CONTRACT please.

And, yes, as as matter of fact, it IS utterly maddening to be one of the few people who bother to try to say things could be different, and watching nothing change, because so many people's jobs are literally built on their world working this way.

[falcolas]

So build the time of fixing tech debt into your estimates. You're right, you can't avoid creating tech debt, but you can absolutely fix it while you're mucking about in that code anyways.

[paulryanrogers]

This is ideal. At times though there will be pushback by engineers and product teams drunk on the high of delivering fast and often.

It also requires knowing the approximate amount of debt that may be involved in any given work. Or else actual work may far exceed estimates so often they become meaningless.

[falcolas]

Both of these concerns are a part of maturing as a software developer. Managing expectations, leading your team, estimating - these are soft skills required by a senior or above software engineer.

Estimates, as a rule, are never terribly accurate in the first place, often because of tech debt - adding in cleanup won't make them much better or worse. To give any kind of estimate in the first place, you need to be fairly familiar with the code, which includes the crufty bits that count as tech debt.

[taneq]

The other thing is that technical debt is not always bad. It's just another stat to manage along with budgets, ROI, available engineering time, customer engagement, etc. etc.

If you have a product that's nearing end of life and you can boost its value for another year with a quick hack, then do it. If there's a system that really needs refactoring and is getting harder to extend, but still works fine as it is, then you leave it alone. If things have gotten a little curly but are still serviceable, just roll with it. You don't just trash everything, obviously, but a year from now when you retire that codebase, any extra time spent on it now will be wasted.

In your new flagship product that you have no plans to replace for the next 5+ years, you take the extra time to keep everything nice. You re-engineer whatever needs re-engineering to add that feature like it was always meant to be there. You refactor the smelly bits of the code. You push back entropy to keep it shiny because it's likely to be worth it.

[vineyardmike]

> technical-debt comes from things that were done properly the first time

So its not tech debt, its a complex system that takes longer to do things in future. "Bad tech debt" is like credit card debt, short term decisions made at expense of the future to impulsively satisfy immediate needs. "Requirements change over time but it was done right at the time" is like a mortgage and you need to move to a new town. Its entirely reasonable to have a slightly cumbersome payoff process because it was well chosen decisions. Still harder to pay off, and may incur more debt, but as long as its reasonable.

[throwaway6532]

And this is why I call it technical tax. It permanently eats away at a % of your engineering capacity.