The problem is a lack of trust, same as a contractor. If you go to a new mechanic and he says you need a $1,000 repair—do you? Or is he trying to sell you replacement blinker fluid?

A lot of managers feel the same way when engineers talk about tech debt, refactoring, etc. Maybe they've never read code, or aren't familiar with the specific codebase. Projects seem to be getting completed—what's the problem? Maybe velocity is going down, but are the engineers right about why? Or are they just being anal about something that's simply less than ideal?

A good contractor walks you through why the repair is needed, what your options are (cheap temporary fix, long-term repair, total replacement), the consequences of those choices, and how much each will cost.

Unfortunately in software we don't really know how to answer any of those questions. A lot of refactorings and rewrites just shuffle irreducible complexity around ("it makes so much more sense now!" says the developer who just spent a week studying the code and rearranging it to their personal preferences). Not to mention that we suck at giving estimates.

One reason why your CEO needs to be technical. I run my own small software shop, and I can sit with my developers and actually see that the code needs refactoring. Indeed, it is often me (the CEO) that actually forces a refactoring sprint on the team. They usually want to move on to the next beautiful feature. But long term, our feature velocity and product quality suffers when the internals are bad.

> A good contractor walks you through why the repair is needed, what your options are (cheap temporary fix, long-term repair, total replacement), the consequences of those choices, and how much each will cost.

This 100%. Technical debt is placeholder term for engineers who want to do stuff but don't want to spend time explaining the people paying their salaries why they are doing it. Technical debt is meaningless. Be more specific. Present options. Be a professional?

> Unfortunately in software we don't really know how to answer any of those questions.

Good senior engineers can absolutely answer these questions. Is this not what you've seen in Enterprise software dev? I'd say if you're a senior engineer in this context it's more than half of your job.

I disagree with the analogy. Need for repairs arises because of the natural decay. Tech debt is a consequence of the decisions made at implementation or even planning stage. It's more like forgetting to order a plumbing connector and using duct tape instead. Except in software there often isn't any forgetting involved and the actual connector is never ordered.

A lot of tech debt is self-inflicted, but not all. Decay is induced by external forces and the same thing can happen in software, e.g. when underlying platforms change.

Mobile apps are pretty high maintenance because you often have to change something with new OS releases and want to roll out an update. You can abstract over the platform but that is in itself costly, so there is a tradeoff.

Bad analogy. Whether I 'own' the company (equity/etc), if I'm a full time employee, the maintenance/debt needs of the company still affect me. They possibly affect me more than someone who merely has 'equity' in the company (people may own shares in multiple companies). A 10% drop in the company's revenue might mean I lose my job.

If the painters/electricians also lived in the house, and it was their only/primary shelter, the 'owner' isn't the only one 'best qualified' to make maintenance decisions.

“Might lose your job” isn’t the same as having equity or even having 50-100% of your salary based on revenue.

Traditional workers have the job market as backup.

The incentives do not align.