> the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture.

I couldn't have stated it better myself. Most of the time it start from culture, leadership and then experience etc.

I have worked on multiple projects with varied amount of technical debt. But the project with the most amount of debt happened because of poor leadership.

The guy who was managing the project was more interested in currying favor. The end result - everyone's salary was being shared across the company in un-encrypted plain text format.

A manager I worked with previously was like that--no interest in making sure the project could be maintained or actually worked, only promising things to people who didn't even use our platform (me and a coworker checked our logs before I left the company) and getting "wins" so he could talk about them in meetings.

That's organisational debt, which is a prime cause of technical debt.

It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes.

It actually reminds me of regular corporate life in a confused company— and in turn, this: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

> It reliably fascinates me that in spite of more than a century of history, management culture lacks both words and concepts for many common and predictable organisational failure modes.

Does it? The manager in GP, for instance, seems to be a textbook example of a thermocline of truth.

To add. It is hard to get funding for technical debt. Senior management are typically not aware (don't care) that a system is only working because some poor soul wakes up at night to clear caches. Sometimes I feel you might be better off letting the system have a spectacular crash than keeping system on life support. The trouble with letting system crash is may be a career limiting. Technical debt is complicated. Take companies that pay overtime to employees that get called at night to fix the system. They may not exactly be keen to have the calls stop.

the crux of Technical Debt is captured in these 2 points

> the right balance comes with not just engineering experience, but also domain experience, team maturity/talent, market/competitive pressures, leadership, and culture.

>the project with the most amount of debt happened because of poor leadership.

Also, some debts are not even debts, but normal limitations of the code

If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt

It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.

Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.

Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).

Sort of. You could have used better techniques/frameworks/whatever and gotten it right from the get-go. It does help to have the experience to intuit/know what you'll have to make scale and to what degree so that you can spend cycles on avoiding likely pitfalls without wasting too much effort.

I would be a very rich person if I got a dollar for every time the "right framework/solution/technique" broke unexpectedly when pushing it in certain ways.

Or it might not even have existed (or was unstable) when you started work, but it got better later.

I was thinking of things like: thread-per-client vs C10K. Just go C10K all the way. That means write services to be async, async, async. Just do it. It will not be the case that thread-per-client is better than C10K except when you know you'll only have a handful of clients. Write code to be thread-safe / reentrant. Write code to be separable into libraries.

I'd also urge you to use higher-level languages from the get-go. If you can use Rust instead of C, do it. If Haskell is appropriate, use it. These are all choices that are fantastically easier to make early on than later.

Yes. Some things are just obvious easy wins. And still I am surprised how often we choose to do differenT.

Its the same readon why I almost always immediately use vue or react. Because it doesnt cost me much (~0) but if that thing has to scale i’ll be ready

I think that's the point. You choose the best tech at the moment given the requirements with some headroom. Why waste engineering time to make sure it is hardened to support 10x load? Sometimes it is easy (use a different library) but most of the time it is hard.

"10x" is large or small depending on the plausible variance you can expect. A free casual game? 10x spike is quite expected. a $1000/month B2B Saas? 10x comes with a lot of predictable lead time.

Some changes can be extraordinarily difficult, so if you can foresee that you'll need, say, to make some code into a library, or thread-safe, or async, then it's best to make it that way from the get-go.

Obviously there's a bit of YAGNI in tension here.

But if you have the experience to write it correctly from the get-go at low additional cost, then it's worth doing that instead of risking a massive rewrite later.

> to make some code into a library

I have never had any problem with putting some code into a library after the software is done. It is almost always a 1-4 hours exercise, and when it's not, it's a 2 days task at most.

Async code is also something that I have never seen it being a huge problem. Mostly because only a small part of your code needs to be async, most of it can stay synchronous, scheduled by the small async part.

Thread safety is a real problem. One can indeed trade some of it for some development speed, and this can become a huge bottleneck later/soon.

Technical debt is the cost of reworking software not the features or existence of the software.

Are you talking about software engineering, or engineering engineering? Because I don't think building engineers create technical debt.

Buildings can definitely accumulate technical debt when they're put through a series of changes of use over time. It manifests as odd cable routing, inconsistent floor levels, repeatedly moved doorways, obstructed windows, etc.

The UK houses of parliament are a good, if perhaps extreme example of that: https://www.theguardian.com/news/2017/dec/01/a-tale-of-decay...

They have now finally decided to move the MPs out so they can do the refactoring they've needed to do for years...

What do you call the work that needed to be done in order to remove the existing electrical cables in my house and replace them with a wiring layout that was able to add a second outlet in my bedroom? (Or, far better - the unofficial extra wires that the contractor found which had been loosely spliced into the existing system by the previous owner in order to power the new bathroom lights he added, which just stopped working when we removed the old cable because nobody knew that connection existed).

Technical debt is kicking the can down the road. What you're talking about is mostly just a feature overhaul. The modifications the previous tenant made were technical debt.

I don't agree with this. As was pointed out here too, software changes in production all the time. This happens with Buildings too, but on a different time scale. Buildings that were made with forward layouts for HVAC and electrical systems will be easier to upgrade in the future. If you look at old buildings that had networking and such retrofitted in a visible and ugly fashion, I think its fair to say that you're looking at technical debt.

In the sense that the alternative is to demolish and build a new building, your example is technical debt. But your example is really an example of legacy systems.

Sometimes, supporting the legacy system can be technical debt. But sometimes when people try to replace the legacy system, they spend a lot of time and money and end up costing way more than simply maintaining the legacy system. This is part of why some nuclear plants will continue to operate on PDP-11's until the year 2050.

Technical debt isn't really debt if it's actually just a part of the cost of doing business. You design your system for its intended purpose, and if it's accomplishing that purpose well, you don't need a redesign. Don't break what doesn't need fixing.

Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. That flexibility means that the first release need not be the last release. The obvious charitable interpretation is that the parent was talking about software.

> Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production.

I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building.

I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless.

If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering.

(This is not a field I'm familiar with so any errors are mine, not my friend's.)