That's hilarious! Does that make Management "Technical Debt CDO Traders"? :)

"Loan Shark" nicely anchors the business consequence of piling debt on top of debt. The interest rate ain't gonna be your safe little bond interest rate, it's gonna be whatever the situation says it is.

I also don’t think tech debt is a problem in and of itself. And I’ve worked a number of startups with serious tech debt that was holding back velocity.

I really enjoy the challenge of plotting a course out of a hole like that. However in my experience without management buy-in it just won’t happen. Even if you as an engineer do the planning work to make it as easy as possible to pick off low hanging fruit, you’ll typically be seen as “off task”. You’ll get lip service about how code quality matters, because without that they’ll scare away the other devs. But they’ll be hoping you give up and just focus on delivering what the management team is asking for each quarter.

It takes a ton of patience and management hand-holding, on the scale of 2+ years to shift the culture. And you have to be willing to forgo any chance at personal advancement for that time. Because you’re “off task”.

I think you could take that approach and eventually get an advancement bump around the 3-4 year timeframe but it’s not the fastest way to advance by any means.

And the total failure rate for an endeavor like that is pretty high. Maybe more than half.

Still, it is fascinating work.

> has garnered some of the funniest cold opens from recruiters over the years.

Please elaborate.

Yes, and I think that is what makes risk assessment hard.

All debt packages risk. However, the kind of debt/risk perception we are personally conditioned around in daily life does not translate to software. Managing software debt requires investment banker-like thinking, rather than the mindset of a credit card or mortgage holder.

I do a lot of technical due diligence for companies in a bunch of different contexts (private equity pre-acquisition, post acquisition, management change over, etc). I have found that tech debt is highly correlated to the business goals and tech organization structure, and has to be evaluated in those contexts.

Startups you want to see with fairly high tech debt. Tech debt there is a very often a sign of shipped code that is meeting some customer need. You do need to watch out for insane tech debt that may be hard to undo later on (running everything in an ancient proprietary language for example).

Startups with low tech debt often are devs navel gazing without a lot of revenue coming in. This is surprisingly true almost all the time.

Very large companies will tend to have a mashup of all kinds of technology that is never fully untangled. A very large Corp with little tech debt is exceptionally rare. If it ain’t broke don’t fix it is the rule.

Mid sized corps and late stage startups seem to be the sweet spot. Fairly low tech debt systems that is providing high value is still possible. This is where you have enough maturity to know what “good” looks like, and enough developers, momentum and budget to implement the vision.

One small anecdote of a project at work. The oldest current project. All our projects are fairly simple and similar. They all use libraries and templates. This one is the last of the early projects before those templates and libraries. It's the easiest to manage. Things rarely go wrong. No forced upgrades because of a library vulnerability or template update. Bugs have been always been straightforward to find and fix because everything is procedural and clear. No abstraction 7 layers deep. Just clean, simple code.

Code doesn’t have to be perfectly maintainable and „elegant“. It just has to be useful i.e. good enough. If it solves your user‘s problem, that’s good enough. If your development speed can keep up as you add new requirements, that’s good enough.

Doesn’t mean you should ship untested code because that would decrease both the value to the user and your development speed. There are projects out there that go into the other extreme, entering the realm of premature abstraction and accidental complexity. In my experience that’s even worse because in that case it’s hard to convince stakeholders that there even is a problem.

It‘s a tough pill to swallow for devs with perfectionist inclinations like me, but at the end what matters is providing value to the user. In fact, I think technical debt will always be present as long as requirements change, and as the saying goes, change is the only constant in software engineering. It‘s not something to be completely avoided as that’s impossible. It just needs to be managed in a pragmatic way to keep up velocity.

Every engineering team I've worked with virtually every engineer complains about technical debt - regardless of how much time is allocated to manage it. I'm not suggesting it isn't important to take care of it, just that sometimes it comes across as the boy who cried wolf.

I have micro-services that haven't been touched in years because they do one thing, and the requirements of that one thing never change.

It is possible but only in your own projects as tech debt is the result of:

Programmers who aren't you, and those damn MBAs ruining your flowstate

Technical debt is entered into deliberately, as a trade-off for time that must be paid back, with interest.

The implication here is that if only you had enough time you wouldn't have any tech debt. I don't think that's true.

Some of the tech debt is due to not having enough knowledge about the future of your system; what it needs to do, how it'll be used, etc. You have to make a decision about the tech now and sometimes that decision turns out to be wrong, or at least incomplete, which leaves you with some debt that will need paid off some time.

I also believe some tech debt is unavoidable due to churn from outside of the system. Best practises for a given part of an app aren't fixed (eg React class components shifting to functional components), so sometimes something that was once good can turn into debt over time with no input from you.

Publicly self-admitted, in this case. Apart from that: if I inherit the code base of a bad programmer on my job, with a lot of technical debt, which part of it is a deliberate trade-off? It's still "time that must be paid back, with interest", but how it came to be is not part of the definition. The term is merely meant to help confer the problem to non-technical people, who _then_ can make a conscious decision to accrue technical debt. If they do so out of incompetence, it's still technical debt.

Yes, I do think it's a geniune term. Just like real debt, it's a very useful tool and many things wouldn't be possible without it.

Technical debt isn't inherently bad. Otherwise it would be called "techinical loss".

Not always. Technologies get old and have to be replaced over time. Tech debt is now mostly treated as a part of a product and developers do not decide what to do about it, but bussines through roles like product owners.

in my experience no one doubts that the debt exists, rather people just don't see the same value in addressing it, and aren't easily convinced by arguments they've already been ignoring for years or decades

i'm one of two feature devs on a team of four. over three years the team wrote a few hundred tickets for debt. when the client was acquired and we finally got space to address debt, non-technical stakeholders asked us to nuke the list and write a much shorter one that we can prioritize by complexity and customer impact. the debt is now being addressed in the same way as new build, because that's how we treated it; much like new build, it won't be completed to our satisfaction

in my experience the only thing that works, short of a major incident that devs forecasted and offered to prevent, is buying time--either to just write better code up front, or to use on _undirected_ remediation

Does this change anything in the long run?

Never heard the term Gemba walk before. So I've looked it up:

https://en.wikipedia.org/wiki/Gemba

Gemba means "the actual place" (where value is created).

The core idea behind the Gemba walk is a follows:

> Gemba (aka Walkie Lookie) walks denote the action of going to see the actual process, understand the work, ask questions, and learn. It is also known as one fundamental part of Lean management philosophy.

> Taiichi Ohno, an executive at Toyota, led the development of the concept of the Gemba Walk. The Gemba Walk is an opportunity for staff to stand back from their day-to-day tasks to walk the floor of their workplace to identify wasteful activities. The objective of Gemba Walk is to understand the value stream and its problems rather than review results or make superficial comments.

Despite their name, i think TODOs should not be treated like tasks to complete, you should not let them make you feel bad. Instead, they are kind of a shorthand documentation of what's going on in an implementors mind, what extensions did they think of? Where did they feel improvements could be made? When changing or rewriting the code, these thoughts can be considered.

Oh, this smells…

If you have mostly "fine" and "good enough" code I fully understand why people want to put TODOs and FIXMEs everywhere; as the code is likely a technical debt catastrophe all over the place. (Because that's the usually meaning behind wording like "good enough".)

If nothing of this got ever fixed this means the devs never got time to do that. Just the next red flag…

If a manager would tell me I shouldn't put TODOs / FIXMEs into the code I would be on my way out pretty quickly. As this means they constantly produce tech dept but actually want to hide this fact.

A TODO means you have identified a way to make the code better. Since not everything needs to be at the highest quality, it is helpful to say what will benefit from being improved for future programmers.

If the TODO is not really "to do" before release, I change the name to: PERF (performance), MAYDO (nice to have) or FUTURE. If it doesn't break the user's story then it's not a real "to do".

I also leave comments for obvious good ideas that don't work, in case someone has the same idea later.

The implication that a TODO is a bad thing is wrong. A TODO is an opportunity for refactor. Yeah the code 'works' today, but it could be improved. A TODO means there was a blocker (in my experience: time).