Controversial idea:

Technical debt is something that 'business users' don't need to or want to care about.

If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so.

You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.

Almost no one has a job of 'go do this really slowly and carefully'.

They will always pick fast, and it's your problem later.

So... don't do that. Instead, say: this is how long it will take to do.

Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'?

Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.

Then, do enough of a good job so you can continue to deliver value in the future.

That's literally your job.

Doing a rubbish job as quickly as you can is not your job. Not ever.

You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it".

That's YOU choosing to do a rubbish job.

...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.

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.

> 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.

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.

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.

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.

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.

> 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.

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

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc.

I don't know about you but that is typically not at all how things go at my job.

I can present a 3 week estimate to manager, he will say why 3, seems like it should be easy??, Bob says it would take 2, can you provide a breakdown of the estimate, why does estimate have 3 days for "unforeseen obstacles"?, let's cut that out. We only have 2 weeks but we can't cut scope. 1 year later everything takes twice as long as it would in a cleaner design, management is wondering why dev productivity is low and won't allocate time to maintenance (we can't spend even MORE time on some refactor thingamajig, our productivity is already low!!). Meanwhile im trying to figure out some monstrosity of a codebase written by an engineer who left last year, and also neglected to document their code (unfortunately their manager felt 1 day for documentation was unnecessary). I think this is closer to the scenario most devs operate in. In all but the best high trust scenarios, every estimate is a negotiation.

In reality technical debt is 10% a communication problem (as this and many blogs like to frame it) and 90% a "do you trust your mechanic to have your best interests at heart" problem.

In your scenario your manager appears to be your adversary and not your manager. Those comments are what I would expect from a stakeholder, but not a manager. Your manager should provide a unified front to business and senior management. You two should agree on the correct approach. If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave.

Your entire scenario would be moot if you practised scrum and estimated the work effort as a team. Your manager might get a vote, but that's it.

> If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave.

If you or your manager believe that there is only one "correct" option and that technical debt should always be minimized (vs being balanced against other factors), then odds are you're bother either terrible or very naive. In almost every moderately sized piece of work, there are multiple options and there's a choice of which one to take based on various priorities (ie, the best option varies depending on multiple factors).

While true, this doesn't change the premise. Both parties should agree on the "correct" approach in the context of this discussion: minimising technical debt.

Your manager is always potentially your adversary: after all, they can fire you if they are unhappy with what they are seeing.

Not to mention that some managers simply are adversarial, period. When you apply to a company, you can rarely choose your manager, and sometimes cannot work under a different manager without leaving the company entirely.

I've had adversarial managers in the past. Unsurprisingly, the team underperformed and the culture was terrible, so I left. I don't agree that one's manager should be one's adversary. I've worked with many managers who work with me instead of against me. This is a crucial difference.

The real issue in a situation like this is the use of the Agile Story point BS to create competition between developers in order to have leverage exactly this to push back against the Engineering team with. You need to have a Dev-only meeting so Bob doesn't feel specifically called out and talk about how you all want to negotiate the interests of Product/Business with the dwindling engineering situation, i.e. Tech Debt.

Bob, and others like Bob who live to impress management with their personal 'agility', will implicitly feel more pressure to not go against the whole engineering team if you're able to reach even near-unanimity about what that strategy will look like, in this case, perhaps coming to agreement about how certain tasks will be pointed univocally, amongst other possible strategies. Your only obstacle at this point is a head of Engineering whose interested in their own career over and above his team.

Agile SCRUM exists, largely and for the most part in my experience, as an abuse to prevent this kind of 'collective bartering' on the part of Engineering.

Sorry to tell you this, but it sounds like you have a bad manager. Your story is like not how healthy teams operate, which in my experience actually are much more like the post you're replying to.

Thank you, really. It is nice to hear someone else acknowledge it. I'm going to start looking for a better job.

> Bob says it would take 2

Tell Bob I wish him the best of luck in this endeavor, he's clearly a better programmer than I am.

Bob can remain lucky for longer than you can keep your credibility intact (aka "markets can stay irrational for longer than you can remain solvent"). Ultimately, that stance gambles on Bob's luck running out and his lack of skill being exposed in time for you to profit from it.

Or realistically, bob looking good racking up tech debt and quitting before anyone needs to pay it off

I think the concept here is similar to the behaviour a lot of people exhibit when trying to say 'no' to something. Generally the 'no' is non-negotiable, but a layer of reasoning is added on top that invites the other person to negotiate.

Person A: "Sorry, I can't do this because of X, Y and Z."

Person B: "Well, can't you do X, Y and Z another time instead? This is important."

You never really wanted X, Y and Z to be part of the conversation, but now they're in it and you've been placed on the defensive. If X, Y and Z were never mentioned in the first place, they wouldn't be on the table and you wouldn't have to justify them.

Same as it is with stuff like tech debt and non-functional requirements. You want to do them, you most likely have to do them, so bake them in. Keep the tech debt and NFRs off the table but leave the features open to negotiation.

Obviously has to be within reason if you want to maintain credibility, so you've got to figure out how to prioritise your tech debt too. And sometimes that means you don't do any of this and you accept a bit of interest on that debt.

Tradeoffs all the way down.

Yeah I can see why that is controversial.

The assumption seems to be that a single developer has agency and is aware of and solely responsible for everything that's going on in the codebase that they may or may not have written.

I've been in a situation where I joined a new company and the code base wasn't looking good but my job as a new hire wasn't to redesigh and rewrite the guts of it. My job was to implement new features, one after another, usually without enough specification to even begin to estimate how long it's going to take when everything they eventually turn out to want is accounted for. The project was already very late. I tried to spend time fixing the foundation and pointing out its problems (including complete lack of tests) but I was told to stop because the customer wasn't paying for that time. The problems I pointed out went ignored.. until they messed things up in production a couple years later.

I'm gonna say they chose rubbish against my advice, and they eventually got what they wanted. Rubbish on top of rubbish, with lots of bugs and slow development.

"We build our computer (systems) the way we build our cities: over time, without a plan, on top of ruins." - Ellen Ullman

I disagree pretty strongly with what you've said here. Specifically, part of my job is to make sure my customer is aware of the options and the costs of each of those options. Doing things the faster/less robust way now will have a cost later (re-implementation of some part, etc). And then I do my best to convince them of the approach that I think is best. But only telling them about the option I think is best and _not_ discussing the viable/reasonable options... is definitely not my job.

Implementing a faster solution that will have costs later isn't me choosing to do a rubbish job. It's me helping my client make the best use of the available time/money.

When I hire a company to install a new heating system, they present me with various options; better/worse hardware, single/multiple zones, brand new hot air lines vs rewrapping existing vs using existing unchanged, etc. The person from the company may have a strong opinion on what is best, but listening to them and then making the decision I think is best is expected.

When you get a new heating system are any of the options "fake it til you make it?"

Would you pay for any of the options known to be unstable and will have to be replaced in a year?

What about the options that require HVAC staff to carry 24 hour pagers? When's the last time you got a whoopsie email from that manufacturer because of an outage?

I've had to choose between

- Installing a 3 port hot water line that has an extra, unused port for later (when we furnish the basement) and a cheaper, 2 port line. If we chose the 2 port line, it would have cost less now, but incurred additional cost (replacing it) when we furnished the basement.

- Using the old hot air lines (much lower cost, but less efficient), rewrapping the part of the current hot air lines that can be reached (middle cost, middle efficiency), and replacing the lines completely (higher cost, higher efficiency)

- Installing a reserve hot water tank (more expensive, but better able to handle load) or not (less cost, but could result in not enough hot water under load). If we went without the reserve tank and it turned out we were short on hot water on a regular basis, it would cost to add one in (overall, more than just including it at first).

None of those things are choosing between "doing a bad job" and "doing a good job". They are all a choice of how much we want to pay now vs debt we may/will need to pay off later. Ie, a parallel to technical debt. Technical debt doesn't always mean you did a shitty job, it could mean you took certain shortcuts because they accomplished what was needed _today_, but will incur additional cost _tomorrow_.

> Technical debt is something that 'business users' don't need to or want to care about.

Sometimes it's hard to tell your manager: Yes I know you want to track every single coding task in Jira, and you don't see any immediate value to this one, and I'm not going to dispute that, but I am going to do it and you "don't need to or want to care about it".

Sucks not to have that autonomy but it's real. That's when you have to justify the refactor, and not with potentially offensive statements like above.

It's also important that they know, so no one is surprised when the next release goes out with those changes and it turns out that an edge case wasn't tested. You don't want to have to explain that something broke because you made a decision on your own to clean up the code.

When you're getting permission to do something like that, management is deciding if the risk/reward tradeoff is worth it, and I think it's only fair to give them the opportunity to make that analysis.

That's why you sneak it in piecemeal as you go, and leverage the critical path of urgent things that aren't finished yet to get it done.

I had a boss once who had a Math PhD and could throw together spaghetti code to implement his ideas.

He would give me a task to do and would basically say "don't waste time making the code clean and nice" because he knew I had a software engineering background and didn't want me over engineering anything.

I would nod, implement it "the right way" anyway, and get it done in the same amount of time.

Because doing it the spaghetti code way always takes longer in the medium to long run, and often even the short run, anyway.

Not sure I agree with the theme of this take. Technical debt can be significant and take months to address on a large codebase. This take also places a lot of blame on the devs who have to work on tech debt, where in reality, it's often another dev who wrote the original code(usually several years ago, and no longer at the company). Things are more complicated than "just deal with it and hide it under a rug".

> Technical debt can be significant and take months to address on a large codebase.

I think the premise is that if you've got months of technical debt built up, you've already screwed up. If you (and everyone else on your team) refuse to ever take shortcuts, you'll end up debt free.

If you're already in a situation where you have mounds of debt, yes, you can't just increase your estimate for current tasks.

"If only everyone" is a version of the Prisoner's Dilemma. I don't think we've got that one figured out yet.

Besides, if your working style overly focuses on proper engineering while other things are on fire, the company could die.

The problem with me is many times I'm not aware that I'm introducing a debt while developing, only until it's reused or revisited that it's clear enough. Yes, even with code review process.

So even business users need to understand that there must be "maintenance phase" even for software, to pay tech debt, updating packages, patching / improving securities, etc.

Sometimes you just need to deliver quickly and cutting scope isn't an option.

Sure you can say that it's not possible. Then you get replaced by someone who's willing to take the necessary shortcuts.

What's important is to make it clear that you're taking shortcuts and that you will need time allocated to clean it up later. That's basically what technical debt is.

Lots of people have fought with technical debt for a long time, and if it was as easy as just being like, 'oh hey, we just do it next sprint' it wouldn't be a thing.

...it's not that easy. It's not easy.

I'm not saying it's easy.

I'm saying: If you do the easy thing, which is always choosing to leave technical debt behind, and waiting for someone to come and tell you its ok to deal with it... you're going to have bad long term outcomes in your project.

Part of your job, as an engineer / developer / whatever to spend a portion of your time not just doing work, but ensuring you can continue to deliver value in the future.

Here's a metaphor for you:

Some people like 'release based' branching; because you can push all your changes into develop (however messed up they are), and then some poor soul has to someone pull out a release candidate and then slave away over it to make sure it works...

You release seldom... but, most developers don't have to worry about it (just the release manager), and its fine.

Some people prefer trunk based development; it's harder.

Every merge to master you have to make sure your code actually works, because hey, it might go live in the next 2 hours.

A lot of people really hate this, because it means they have to do a lot of work and they cannot push the hard work onto someone else.

...do you see the metaphor?

I think it's pretty relevant.

Address technical debt slowly and continuously, not rarely and massively, and you will, in my opinion and experience, have better outcomes.

This is still making a spectacular number of assumptions about other people's work environments. The technical debt they're dealing with may not even have been theirs in the first place, it could be an external codebase. It could be a dependency that's long since abandoned and is now a security risk. It could be that the project is deployed against a really old DB and the feature requested needs that upgrading. It could be any one of an almost infinite number of things that none of your scenarios seem to be aware of.

> Instead, say: this is how long it will take to do.

You'd better have Nostradamus-level prediction accuracy if you're going to play chicken like that with every estimate you're pressured to give.

> Doing a rubbish job as quickly as you can is not your job. Not ever.

Unfortunately someone else IS willing to do a rubbish job as quickly as they can, look absolutely golden to their managers and clients for a while, then slingshot their career on to the next big pay raise, leaving the next poor chump to take the fall for their malfeasance.

> You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.

That sounds a little crazy. If you applied this same argument to money, you'd conclude that their job is to spend money as fast as possible in order to deliver value, and the debt that builds up is accounting's problem, not theirs. No successful business works like this, so clearly the logic does work if it's presented correctly.

The Agile process that companies insist on using includes technical debt as part of the deal. It's impossible to write software with constantly changing requirements, that you have no idea about more than 2 weeks ahead, and not incur technical debt. I would guess that nearly all technical debt is due to this, and not due to developers rushing.

Unfortunately it does not work in reality. There will be another guy who is ready to do "fast and dirty", and he will be give the responsibility and probably will lead the team in future.

Guess it depends on your management.

I've often told my boss the feature would be easy, but I would also like to take the time to clean up the code in the affected area since it's making it harder than it should be to implement changes. And I've gotten some time extra to do just that.

Other times I say doing it fast and cheap is possible, but I see an opportunity here to do something more clever and involved which will very likely open up further possibilities down the line. For example, I might predict other clients will need a similar feature, so by making my code a bit more general it should be easier to implement if they come asking for their variant.

Sometimes I get a green light on that, sometimes I do not.

I guess it helps that the owners are playing the long game, so my boss can afford to see beyond the next quarter.

even if you were to be "slow and careful" that doesn't garuntee you'll be on schedule, it could turn out later part of your architecture is not suitable for an area maybe due to requirements changing.

maybe you'll say, "requirements cant change!" on top of the earlier "deadlines should be reasonable!". IMHO that's fantasy, I've never worked on something where both these were true for 100% of a project

Controversial or not I agree 100%. You are a steward of the system. The hard part is to define “system” broadly enough to include an outlook that is at least medium term (relative to individual features) but not so broad that you kid yourself that you should be second-guessing things beyond your competence. Somewhere in that range is a sweet spot where a healthy negotiation could go either way, depending on circumstance and opportunity.

This is the "just don't have technical debt" argument. Which entirely misses the point.

I think permanency and maintainability are features too. I would be fine with telling corporate that we can build something, but it will collapse in 3 months and need a total rebuild.

If their budget allows for that, then okay we go ahead.

While I agree with this idealistic view, all it takes is one delusional, misinformed or ambitious EM to break rank and start cutting corners for short term wins with the management and before you know it all teams are now expected to do the same.

Any organization where management does not readily acknowledge their reliance on technology and its associated upkeep costs is doomed to eventually sink waist deep in a tech mud pool of their own making.

"Cheap, Fast, Good - pick any two"

If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for.

If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work.

When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are renegotiated.

Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has 'technical debt' too.

It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn't there because 'its not the customers's problem'

About houses, we watch one of the "Love it or List it" TV show variants. The way it's shown, very often, when the old house is being renovated, the renovators find something that's against code and has to be fixed. Or they find something damaged. And it's always shown how the owners are disappointed and angry. Why didn't they investigate and find it out in the first place when buying the house? Why didn't they do maintenance?

Then a new house is also shown, but we are only shown mainly interiors and views, never an iota about how the foundation or technology of the house works. That bit you the last time. And the owners want to get rid of the old house because it left a bad taste in their mouth by having these "surprises". Yet they waltz right into the next one with no concern whatsoever. (The shows also never talk about costs of living.... it's just the buying price of the house.)

These things all have direct analogies in the software world. It very often feels like a lot of people in the business are interior decorators and if I try to converse them as a structural expert - it just doesn't work.

It’s worth recalling the recent hacker news discussion about engineers pulling and shipping unvetted code without any sense of responsibility at all.

Modern SW practices don’t accidentally end up with technical debt, they’ve gotten to the point where they don’t even give limiting it a thought and will happily pull in mountains of other cider’s technical debt on top of their own.

I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word.

- If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...

- If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

- If the lawyer who was originally part of the team that helped draft the old law...

etc.

I must not understand technical debt...all of the scenarios you're mentioning seem like they could easily map to a technical debt scenario

- a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just means you know you're incurring it)

- developers often incur technical debt without explaining to stakeholders about it because a) they don't care b) they don't think the stakeholders care c) they want to get the work done and not get dinged

- developers who have to pay for technical debt may be the creators of that debt to begin with...(of course, I'd wager that most technical debt is handled by someone else who comes later because I'm rarely given the chance to fix problems I created, project managers can be judgmental like that - and project managers have to be convinced that we can just apply some more duct tape)

See my other answer below: trying to convince the payers that there are extra costs due to "technical debt" accumulated somehow during the lifetime of a sw project would sound "unconvincing" because from the point of view of the business that would be part of the job of the same people that are now asking more money/time/resources to fix it.

This reads like it's in a vacume and assumes the business requirements were comunicated, they were clear, and and static. None of which is reality. Additionally things get updadated and need con rant maintenance. Gone are the days of writing code and letting it run untouched for years.

Tech debt usually occurs when the people implementing it aren't aligned with the with the stakeholders.

> - If the contractor finds asbestos which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...

Obviously someone* put that there. It didn't just install itself. Regardless of whether the contractor installed it themselves or not, the reality is it's there now and needs to be removed.

In other words, the analogy still holds regardless of "oh they put it there"

> - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

That is exactly what every car dealership does with their "powertrain" warranties and service packages.

> - If the lawyer who was originally part of the team that helped draft the old law...

AAAAAAAHHHAHAHAHHHAHAAAA New to the legal system?

It was a way to illustrate the metaphor: I am just as "new to the legal system" as I am at asbestos removal or car repairing... but I have enough experience with software development to understand why "tech debt" is a pretty hard concept to sell to business.

In any case my point is not "there is no tech debt if you created it yourself" it is more about "from the point of view of business tech debt is not something they care about: it is sonething they expect to just be sorted out transparently or that should not even happen". After all, Microsoft never bills them for "tech debt", it just ask them to reboot to update their laptops, no?

I am not saying this is fair, or right. I am just trying to explain why mentioning "tech debt" falls on deaf ears.

I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

Totally on point, but if I may offer a twist:

Say you run a large plumbing company, and you discover your plumbers took shortcuts on a particular job that resulted in an abundance of leaks for a given project.

The plumbing company cannot ask the plumbers for their pay back. They will have to eat the cost and fix the plumbing.

So, it's the business's problem either way. They can additionally choose to fire those plumbers if they want, which is line with your point of not believing the plumbers had no idea.

But it's still the company's debt to pay. They made the mistake of hiring people that were not capable of surfacing risks.

"They made the mistake of hiring people that were not capable of surfacing risks."

Exactly the problem we always deal with: Business tends to distrust Tech because we always seem unable to stay on top of things we build ourselves

There are two types of tech debt in my experience, things get out of date because they weren't maintained and it's harder to do now years later than absorbing some of that work a little at a time throughout the years. And the other kind is because of poorly written code which is often caused by poor business practices and changing requirements.

I don't now what your experience is regarding sw development (especially corporate): - in my experience technical debt is often due to:

"There is never enough time to do it right, there is always time to do it twice"

Idiot maybe not but if any of those people cited some sort of debt and then I had to pull “it’ll take longer because parts/law change/asbestos” out of them rather than just coming out the gate with it then at best I’m going to be slightly confused about why they communicated it like that. At worst I’m going to think they’re trying to play me.

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences.

Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired?

I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull request because he had control.

Just because YOU have never been in a situation where YOU didn't have control over the creation of technical debt doesn't mean its just some magical thing you can fix and change by saying the right words, don't be naive.

It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

> It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly."

Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.

Yeah, and that's when the complementary skill of knowing when to repay tech debt comes into the picture. I'm not sure what else you would be suggesting: that we should all build every experimental finger-in-the-air MVP as if it were core business-critical functionality, just so we don't have to be disciplined in judging when to repay tech debt?

For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors.

I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!

Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.

Exactly. Consistently refusing to take on technical debt may work if you are drowning in demand for your skills and can easily switch. I don't think that's the case in most places outside the Silicon Valley.

> The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market.

Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be.

Time to market is also absolutely impacted by technical debt, for the same reasons.

Describing this to company leaders in ways they understand is pretty straight forward.

"If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward."

Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.

> Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward."

I’d argue that technical debt that can be resolved in a week is not real technical debt.

And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without lying through your teeth. “It will probably take us a month to two months to fix this problem and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.

> and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.

Which indicates there really isn't much quantifiable value in the refactoring, and it's probably a poor use of developer time.

I think the metaphor for technical debt is leaky, but I don't think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to "rushing things", but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I've seen technical debt addressed successfully in a fairly long (~18 years) career:

1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.

2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

I had a conversation that stuck with me a few years ago at a very large company about making proposals for future projects. I had a habit of making very detailed proposals, doing a great job making projections and being accurate about those projections.

A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”

I guess I had never considered that a lot of my peers were just inventing numbers to justify things they wanted and that there’s a careful balance that needs to be struck between “making shit up” and “detailed unbiased analysis”

That's when you suggest that the historical accuracy of the proposals should be weighed to determine the degree of certainty in future proposals from various sources, right?

Let's say person A gives longer estimates but is accurate within 10% more than 95% of the time. Let's say person B gives estimates half as long, but the team runs over by 75% a quarter of the time and by 150% about half the time. Whose proposals should the stakeholders choose?

If your company is making decisions based on estimates, the accuracy trend on those estimates is a far more important metric than lines of code, number of commits, story points, or nearly any other metric they're keeping.

You'd need to be very strategic in how you point that stuff out. Because straight up saying that numbers from those people have been consistently wrong throws the people bringing them forth under the bus and it will make the people who you're giving the proposals to feel like you're telling them that they are doing a bad job at evaluating proposals given that they did give the final approval on all of them.

You're probably better off just playing the game and making up good sounding numbers. You're less likely to have half the company resenting you and making your life difficult.

ah the famous "give us dev estimates, but yours are too long, lets go with shorter anyway" makes people afraid to estimate high

If after the 3rd time that happens the boss doesn't notice, that's their fault.

>“None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”

Oh wow. Boy have I been bitten by that before :(

It's what product is doing anyway, numbers are so often just made up to support a narrative.

It's extremely hard to quantify the impact of any changes to a system so "inventing numbers to get what you want" is required whenever stakeholders are obsessed with predictability and quantification.

I get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that).

Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the future of the project. If you want to compel someone in charge to make changes, you need to make them feel things are bad as well.

This is to be used responsibly, though. If it turns out you've convinced someone into acting in a way that is against their interest or a big waste of time, there will probably be blowback later.

Fear of project failure is the signal that the company (= your employment prospects) will be damaged. Frustration with how difficult the work is, is a signal that the current path is unsustainable, and that burnout will set in, thereby damaging your ability to work (= your employment prospects).

It's perfectly rational to be concerned about these things. We are not machines - or rather, we are machines that have mental/psychological/monetary needs that have to be met in the course of our daily employment.

There is no purely logical reason to ever actually do anything. It all starts with what you want and what you don't want. You may of course derive logically sound paths to get what you want or avoid what you don't want, but that's something else.

If you explain these logical steps to someone else, what you're doing is showing them that they too will likely be affected by what you're suffering, that is, showing them they have a reason to fear too.

We are getting into the weeds here. Unless you are trying to tell me that there is no logical reason to trying to meet the bottom few tiers of Maslow's Hierarchy of Needs, in which case, while you may be right in a very strict sense ("nothing and nobody matters"), it's an extremely nit-picking position.

That is actually exactly what I'm saying.

A message's ability to provoke some form of action is entirely dependent on its ability to create some form of emotion, be it fear and indignation or hope and optimism. The most effective rhetoricians are exactly those that are very good at producing those feelings. From Hitler on one side as the archetypal rabble-rouser; to MLK on the other end of the spectrum, who created profound optimism and hope. It isn't because of their syllogisms that they were convincing rhetoricians.

Merely knowing a fact is rarely sufficient to provoke action, unless that knowledge itself creates an emotion (an idea can have aesthetic value, for example).

In my experience this isn't an issue if there is good leadership in place.

I find I have to head check myself from having negative thoughts about approaches that I wouldn't have taken. Like seeing old java, or bootstrap :P. It still works, fixing it may make things neater, but does that really pay down debt?

Yeah, this feeling is ubiquitous among programmers (or 'developers' perhaps), and I suspect it's a large reason why businesspeople are suspicious of "we need to invest time paying down tech debt".

There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".

Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money.

Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It's relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn't learned about financial instruments.

King: We need to raise an army.

Duke: Okay, but we're out of money. We'd have to borrow more.

King: Are we able to borrow money for it?

Duke: Yes, but our debts are racking up, and there could be future consequences.

King: Sounds like we can borrow money, do it.

A better term might be "technical mass". Having lots of it makes it harder to quickly implement changes and features.

It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it.

Though if business folks didn't take physics classes it might not resonate well with them.

I like that. More mass slows everything down and makes changing direction harder.

Technical calories then?

That's exactly how startups think, though. The king raises an army to conquer rich lands and pay off debt. The founder makes hacky products, to get users, then raises money to hire engineers.

It has to be moderated by comprehension. If a leader doesn't understand what interest rates are, they'll borrow money every time it's available. A startup needs to borrow enough to succeed, but not so much to be bankrupted by debt payments. Same for technical debt; enough to move fast, but not so much the software (or staff) collapses before revenue.

Maintenance also has a second aspect: Bitrot.

Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem.

The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: "We won't be able to ship/develop after day X because big OSS project Y deprecated our version" (think CentOS repository deletion).

It is our job to keep an eye on this and report it in the terms management understands: "We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities."

This is a really excellent constructive way of framing it. Thanks for posting this!

Usually, the discussion goes the other way around.

Product is pissed because delivery is stagnated and that's because of technical debt.

Product: We need that change for Big Co.

Techie: Okay, that takes two weeks.

Product: Two weeks? For such a small change??

Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence.

Also, usually techies don't care.

Why? Because it's always good to have an excuse to work slower.

Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.

Exactly this. The author's dev-blaming perspective is that Tech Debt costs are not accounted for systematically nor communicated clearly to the business folks.

Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.

> Why? Because it's always good to have an excuse to work slower.

Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.

Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not interesting.

I don't think I've ever worked in an environment where the tech team would have resisted the opportunity to take some time to refactor or update some systems that needed attention. In fact, they'd most likely be overjoyed and would much rather do this than implement features. YMMV from team to team, though.

I agree. I think people on HN generally underestimate the extent to which developers themselves push to work on new features instead of maintenance. It's often a different kind of feature though. I can't count how many times in my career devs (including me!) instantly jumped to "we need to rewrite X using new framework Y" in response to technical debt in X.

I only saw that behavior in younger devs.

The average dev just does their job. Same as with the average person in every industry.

Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.

I _love_ maintenance and fixing technical debt, much more than working on features.

And it's easier though if you have different skillset than feature development.

Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.

Speculation ahead:

One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).

Absolutely agree. I moved on from a very high level engineering position last August for exactly these reasons. A mountain of technical debt the size and breadth of the Rockies that was not being addressed was dragging everyone down. I'd had enough. Leadership at my current position understands what technical debt means, they understand the technical reasons given for calling it such, and the impact not only on business but also development time and DX.

If dealing with technical debt has a toll on one’s mental health then maybe they should transition to a different profession. Dealing with technical debt is part of your job description. Most people don’t have the luxury of ignoring the hard parts of their job.

It’s not about luxury, it’s about increasing output efficiency through (human) resource management. I asked if there was any available research that measures the effect of tech debt on mental health and therefore output efficiency. TBH, I’m not really sure which part of my original comment you are addressing.

Edit: clarification.

I’m addressing the premise of your question. If someone’s mental health is affected by technical, then that role is not well suited for them. No one should have to work a job where their mental health is constantly in jeopardy.

> No one should have to work a job where their mental health is constantly in jeopardy.

Agreed. But you’re using the term mental health as mutually exclusive to mental unhealth (unhealthiness?). I’m asking what the effect size is (assuming that there is an effect) and whether it can be modeled on a curve.

Edit: (addendum). It should go without saying that many people work in environments that are to some degree unhealthy for them and don’t have the luxury of switching.

I have anecdotal support with a sample size of 1: This happened to me. I genuinely wanted to care, and wanted to improve the situation, but found I was slowing down (1), introducing bugs with every merge (2) and finally I just left (3).

Business began with a certain idea, then over time pivoted into into better and better, mostly related niches for users. What that meant in terms of the code base is we started with one thing then tried to back-port it in several new directions and ended up with a gigantic ball of spaghetti.

Great job, great coworkers, great technical management. Code base just became so rotted and so overextended, it became untenable.

One of the things I struggle with in the perennial conversations about technical debt at startups is how to account for the fact that the future in not known with certainty: i.e. circumstances can change that render very good and 'worth-it' (but expensive) technical decisions obsolete in future.

My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to 'do it right' vs 'do it fast', since they believe that EVEN IF it's 'right' today, it probably won't be 'right' tomorrow and we'll have to rewrite/re-do/refactor to accommodate the new paradigm/circumstances.

Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. "prepaying" the cost of fixing the future problem.

IMO: software engineers have a professional responsibility to mitigate technical debt (among other things).

Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit.

Software engineers should not _ask permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there's no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them.

There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don't just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.

Part of the problem is that the job of an accountant, lawyer, electrician (and presumably a mechanic) has that responsibility and duty of care imposed by law. If a client is pushing you to cut corners that are illegal to cut, you point them at the law book and tell them to piss off with their meddling. And because it's illegal, everyone in your jurisdiction will have to do the same thing, thereby assuring that the outcome of this particular Prisoner's Dilemma is rigged in advance except for the most foolish/risk tolerant who are willing to break the law.

The software profession has no such thing, for the most part. So clients will keep probing and meddling, just like toddlers who want to know how much they can get away with before their parents punish the misbehaviour. And if some people die, or suffer from algorithms gone wrong, or are just generally pissed off left and right because of bad software - who cares. Profits are king, right?

Without legally imposed duty of care, the only thing that can be done to draw a line in the sand is to commit (collectively) to maintaining a reasonable level of professional practice.

Simply do not entertain probing and meddling. "It's going to take a little longer because the software is complex and it takes some time to untangle it" is all you need to say. Whether you refactor/test/document it in the process of understanding it is irrelevant.

That won't work. As I said, for developers, this is a Prisoner's Dilemma scenario. It simply takes enough defectors to fill jobs at companies that don't care about quality, and you lose any collective power you had as a group.

A "culture of approvals" is one root cause of this situation. Something needs to be done, but instead of doing it an engineer asks someone else for approval and doesn't receive it. Healthy teams don't work that way.

In a healthy team, engineers are responsible for the health of the system.

In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the relative priority of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.

This isn’t that complicated.

Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former.

But financial debt is authorized by corporate finance, which is empowered to do so by the C-suite and implicitly by shareholders. Whereas technical debt is created at ones own risk by the Individual Contributor, who didn’t ask the shareholders if they liked the trade off.

We sound like idiots because we treat businesspeople like idiots. We parrot a definition of tech debt we got from a blog post. The whole analogy to debt is a hand-wavy joke of a definition anyway. It's not debt, it's a liability that's depreciating the assets of the company intellectual property.

The only reason it looks like debt is because it compounds, which is ironically something people don't really focus on when discussing it with management. People don't want to look incompetent so they say "Feature X took 3x as long as it should have, because we had some tech debt". It's implied that the tech debt is resolved. But in most cases the reality is, the time was spent just working around the tech debt, and the tech debt is not resolved. And now you've entrenched even more workarounds and hacks that will make things worse. Compound interest baby.

Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater.

The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain.

Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc.

What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.

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.

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".

Perhaps technical debt is the wrong term to use with nontechnical people, who tend to startle that they aren't even meant to understand so soon as the "tech" part comes out of someone's mouth.

If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we've taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.

> perhaps we should call technical debt what it really is to the business: temporal debt

If they startle at the mention of "tech", how are they not going to be startled with "temporal"?

Then just say "time". Honestly, if your director, CIO, and CEO don't have a decent vocabulary then perhaps explaining this issue isn't your firm's biggest problem.

Stop talking to business about technical debt.

Stop creating technical debt.

No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests.

Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written?

If you accept technical debt it's the development teams fault.

And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.

Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation."

"Ah sry I can't work longer today I already have a reservation"

"On the weekend? Mh I booked a hotel already"

"How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update."

"I can prioritize your new request but I will talk to x to tell him that his task will be delayed."

"Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"

There's (at least) three causes of technical debt that aren't due to engineering negligence (but I agree in general that many sources of "technical debt" are self-inflicted):

1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled.

2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it.

3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.

The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched].

When the latter is validated and becomes the former, that's when - and why - you repay your tech debt.

A team that builds everything as though it were a business-critical feature, which needs to be architected as safely as the control loop on a rocket, is a business which is pathologically unable to experiment and iterate.

The issue is with non-technical people who see that the hacked together mess of a proof of concept "works" and insist that you can just build straight on top of that without any work to make it into an actual working codebase.

Yeah, that's where the engineer/s need/s to be able to explain things clearly to non-technical stakeholders - which is vital for many other things besides this.

I think our hypothetical company would likely founder on any of a hundred other issues before this one if none of the engineers had this skill.

I'm not writing prototype Software.

Everything will find its way back to you.

Bugs are very costly.

I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time.

I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.

Well, that seems like a wasteful amount of time to spend on prototype products or functionality. It's up to you if you want to do that, but other people will likely out-manoeuvre you by being agile enough to iterate quickly.

I did not say that I'm slow due to this or not agile.

But I will not build a sync feature and not having alerting if it fails.

I will not write nee Features and will not think about a proper index.

If you do it right and actually learn those things from an early point those things become obvious.

And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing.

Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.

No one is saying you have to needlessly screw things up. If you're writing things in an equally laborious but worse way, that's just being a bad programmer – nothing to do with tech debt.

Tech debt is more, say, "let's build this new bookmarking functionality by saving bookmarks locally" and then, later on, "let's make it more extensible by syncing them with the server, so we can build on it by e.g. using this information in our new recommendation algorithm".

It's about implementing things in a less complex but less extensible way, and perhaps a less feature-rich way, so as to more quickly validate user demand and thus iterate more quickly.

And yes, it's trivially true that you'll be slower than you could be otherwise by not doing this. You might think you're still faster than other people will be. I wouldn't bet my own money on that, but it's your prerogative to bet yours.

Agreed. But what is "Mh"?

It's a written sound like hmmm humming

Ok, thanks. FWIW, I'm 47yo, a former TEFL teacher, I pay attention to language, and I've literally never encountered "Mh" before. Hmm...

This reads to me as an incredibly reductive take on a real-world problem, offloading blame/responsibility to engineers to properly frame something which very few engineers fully comprehend or can intelligently convey. I understand the author is trying to teach how to frame it, but it still requires experience and skill that I've seen very little of during my career in all but the most experienced or talented engineers.

Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they'll understand.

"We" the engineers don't sound like idiots - "we're" being literal, which is all "our" job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.

What's really frustrating is that technical debt leads to real problems. It's just that these problems have been so pervasive for so long that everybody just accepts them like a bad smell that you don't really notice. Technical debt is the underlying root of:

    - you said you fixed this problem but I'm still seeing it
    - you fixed this problem but you created a new one
    - we can't deploy a fix for this problem right away because we have to certify the whole monolithic mess first
    - testing this fix takes an hour to coordinate

These are problems that business owners should care about, but they've just come to accept that this is the reality of software development.

I use a couple pretty simple measures to get the technical debt idea across, with the numbers variable:

"if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%"

Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.

You have to tie it to something they want or need.

They “need” to be on the latest version -> upgrading versions takes a long time and is prone to error -> the process would be infinitely easier with a robust test suite -> we never prioritized automated testing which is a tech debt which we are now paying interest on in the form of being on extremely old versions of a product.

If you have a car, and drive it 100 miles every day, and keep driving it for years, it will seem like everything is fine. Until one day the engine seizes up and it unexpectedly costs you $5,000 to fix, because you never changed the oil or did any other maintenance. There was never any apparent, obvious reason that maintenance was required. But no regular maintenance does lead to unexpected high costs.

It is critical that technical people have data to back up their claims that maintenance is needed. We need to identify exactly what each piece of tech debt is, how much work is needed to remediate it, and what the business cost of not remediating it is. Otherwise the business has literally zero idea what it will cost them not to do maintenance. This is an expected part of professional software engineering in a business. If you are not gathering this data and presenting it to leadership, do not expect them to take you seriously. It is up to you to prove your case.

Hah :) I've also had a recent blog-post length thought about this entitled:

"Technical Debt is really Software Debt. And it’s a AAA-rated CDO." https://www.evalapply.org/posts/software-debt

Context:

> I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.

> One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge.

(More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :)

Edit: add some context from the blog post.

If Big Corp co is paying per man-hour doing a thing in a week that could be done in a day is actually huge win from the point of view of a business person.

Everything should be done as slow as possible as long as client isn't annoyed enough to change providers.

Business people both at your company and at Big Corp co customer benefit from keeping things as they are for as long as possible. They keep getting paid for as long as the project lasts. But when the project finishes, a lot can go wrong. It might turn out that it was completely unnecessary or that it doesn't solve the problem it was supposed to solve or that any given business person no longer has any utility for the respective companies. Basically a lot of trouble. So technical debt might be something business people actually silently treasure.

I get the using "debt" is an attempt to make it understandable to financial-oriented people, but I think it is a double-edged sword. You have to pay off financial debt, you don't have to pay off technical debt. I think using "technical friction" is a better approach. You are increasing the cost of future projects. "Cutting corners on that will increase the cost of all future efforts by 10%". That is more impactful and conveys the situation better. Likewise, "well, we cut corners here last year to get the demo made, so now this project takes 25% more time."

Even if we SWAG the percentages (which, guess what, financial-oriented people do all the time!), it lets Product Owners and Managers make better decisions.

I'm with you, I agree we gotta drop the "D" word. There's no bank to go to to extend the loan. The "interest" isn't necessarily low or negotiable or even predictable. Way too misleading.

But I'm wondering if we shouldn't be saying "preventative maintenance" and sometimes just "repair" (for example if there's already an error rate, as in the article's last example.)

Of course, then ya gotta answer the question "to prevent what?" To which the answer is "SNAFUs" or "gremlins" (pardon the WWII terms) such as ones that will make all coding work more expensive later on or will horrify customers by their effects. Or just kill the business outright. I've seen that happen, after having been firmly refused permission to do preventive maintainance on my code. (I'm a worse coder but a better salesman now, so that probably wouldn't happen, now.)

Does this stretch the word repair? No, I think if you're replacing disc brake pads on an old car after X amount of miles, that's repair even if you can still stop the car.

In other words, maybe this has been solved in other ordinary economic contexts, and we should just be brave enough to use them thar words.

Great post. One of the major problems is that software engineering is saturated with green devs who recently transitioned from hobbyist coding and don’t fully understand the responsibilities of being a professional. Hobbyist projects are rarely held to external constraints. Usually when the hobbyist dislikes the code he has thus far written, he will rewrite it instead of iterating on it because he has that luxury since nothing depends on his project. Unfortunately in the real world, we have to consider other factors aside from what the author prefers to work on.

This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.

Tech debt is a thought terminating cliche. Progress is possible more easily if we talk in a Markov fashion: under present circumstances, to get X, we need to do Y.

The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision.

Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”

Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits of dealing with technical debt before it is too late.

That reminds me of a hidden cost of technical debt: Who wants to work for you. Technical debt is not just unpleasant, it's a signal of desperation or shortsightedness.

Part of the problem is the twisted naming we are using for development related things. Tech debt, ceremonies, sprints, masters, squads, etc.

Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.

One trick we use is to just bake it in as part of a new medium to large size feature. Or if product is swamped with stakeholder management related stuff, we leave a gap sprint for all these tech debt related things. Another thing we do is have a dedicated platform team whose main charter is to work on general improvements inclusive of tech debt reduction.

I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.

It is essentially the same as financial debt, too much debt and you go bankrupt, but if you refuse to take some debt, you may lose opportunities.

The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don't know exactly how much it will cost repaying it and how much "interest" it will save you when you address it.

It is not the same. Financial debt has to be on the balance sheet; technical debt is not. My point is the a finance/business guy will think in the totally wrong direction with what you actually mean. Also to whom do you repay technical debt?

It really should be on some form of balance sheet, in the form of "costs to implement new feature" (debt gets repaid in part by the next customer) or "costs to maintain" (ongoing interest payments that come out of overhead). The big issue with throwing around terms relating to complexity without assigning projected value or probability distribution for that value is that it makes any discussion asymmetric. As someone who knows something about the processes involved but does not have deep knowledge of the code base, it is impossible for me to accurately predict the tradeoffs in discussions. So when we do have to build project plans and discuss tradeoffs, I have to either rely on the people doing the work to build one-off projections or otherwise make things up the best I can based on general patterns.

I like the term because it is like financial debt, and is a good way of communicating the problem to a business person. The debt will need to be paid off at some point, the longer you leave it the more that is going to cost, and it costs you even if you just keep paying the interest. Framed this way, it also helps us explain why many business people don't care. Many will only care about the projects they are currently responsible for and not about next weeks or the ongoing health of the company. With luck, paying the debt will be somebody else's problem. If you called it 'cutting corners', you get a pat on the back for keeping costs down and expected to do it more often. You might even get a bonus if your boss doesn't take the credit.

Well, if too many corners are cut, people understand it as well 'for this feature we have to fix the architecture, we have been cutting too many corners, so otherwise the whole thing will crumble' makes it pretty clear. Also it term makes it clear why the state is as it is (since cutting corners also 'solves' problems). How do you explain why engineers would have been allowed to take on debt on the company?

Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."

Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off"

of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"

Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.

Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.

You cannot reduce the perceived value of the codebase in most cases since the value is already communicated with the customer, there might even be contracts, and SLAs.

> compared to the imagined/perceived value

I guess the word you are looking for is "necessary".

Techie: We are drowning in technical debt!

Business person: Oh really! What is it costing us?

Correct response:

Techie: Every new release is taking longer and longer to complete. When we don't give ourselves the time, we have more bugs that are driving away customers.

Time is money, business people understand that. Address that aspect of the issue.

This article seemed pretty incoherent:

> Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value.

And then literally two sentences later:

> They care about time to market.

The first is in regards medium/long term maintenance. Whereas time to market usually refers to the first version of a product.

Techincal debt is a typicall long term problem without a short term solution. Product managers are biased towards delivering short term value incrementally, and don't like anything that slows down the value delivery pipeline.

Agree with the headline. I've always preferred to use code as mass as the analogy, because inertia, friction, etc... are more applicable to the situation than money and debt, imo.

Maybe supply chain is a better analogy than debt.

Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.

My experience dealing with product managers is you have to phrase it one of 2 ways.

If you know your taking technical debt, explain to them that its like a credit card, but instead of money its time, and we can go ahead and swipe it, but you will eventually have to pay it with interest, and the cost you are paying is every future story is gonna be a little bit slower until things that should be able to get done in a week take a month. ( I have seen this happen personally with a project and the whole thing had to get completely rewritten)

If its unforeseen technical debt, dont call it that. Call it foundational work. Tell them the foundations were not set in a way to support X or Y feature so we need to change/update the foundations to get them the feature they want. This seems to work best. Don't even tell them there is a hack or duct tape solution, bring up the foundational piece first. If business needs has a requirement that it gets out faster, then transition to the credit card analogy and explain they are now swiping the credit card and whenever they complain about velocity use this an example.

The biggest problem is that product managers typically move on or get promoted by the time the technical debt they incurred causes bankruptcy. And fixing that usually tends to involve a rewrite which will have new flavors of technical debt (especially when its in new language), with a new product manager selling their "V2 solution" as so much better. (and successful delivery of that seems to involve them getting promoted or moving to another place soon after)