Can We Please Stop Talking About Tech Debt? • Emily Rosengren • GOTO 2023

Presenter does NOT provide a better, concrete alternative to labelling or quantifying some practices that can lead to low quality final product.
Mark Heath has a course on Pluralsight that goes into detail about debt. Technical debt is still a GOOD metaphor that can quantify a software team/company "MATURITY" level.
Tech debt is a number of categories
1. Code
2. Architecture
3. Test Suite
4. Overall knowledge about the system (i.e documentation, or what each sub system does)
5. Technology stack

Over time atleast one of the categories/items is bound to lag behind and seriously impact overall product output. Presenter's high level solution is to ignore the "problem"

"What should we do instead?"
Well...ignore the problem (technical debt) long enough...pretend it is not there...sugar coat the problem...dance around it...call it something else
...then one day it will MAGICALLY DISSAPEAR.

Ooh he said the M word.
On a serious note, isn't there technical work that improves ease maintenance? For example. upgrading a framework before it goes obsolete is a must, we left it 3 years too late and struggled with tool support and platforms. Not easy to do, cost 10 man-months, can't hide that from management. In the end, even management had to face the cost. It became a series of sprints but there was value to the end user in the form of better UIX.

Not a good talk. Speaker does not seam to really understand what tech debt is.

Nah, this is gobbledygook. Everything is tech. That "box" is infinite in size and scale. As for the debt aspect, this is also not properly quantified in here. The debt of a thing is the ratio of effort to gain from work expended on an existing codebase. This extends to not just internal effort spent but also to the inevitable issue of aged out technology that has minimal specialists available to do the work. Talk to the COBOL people and get back to me. Or obsessions with using antiquated databases based on Pick. You could also discover that there are things you are keeping alive and you don't actually need to as you could be either leveraging something else in your company or switch to an off the shelf solution.

Fundamentally, the entire ecosystem of your domain should be assessed on a not infrequent basis. Items of concern from both availability of expertise to security concerns and EOSL need to be measured and used as a way to prioritize what aspects of your domain need to be addressed. Waiting too long or being flippant will indeed catch up with you and start or completely paint you into a corner.

Yeah! Absolutely agree, lets talk less about tech debt and throw more money on QA engineers, test environments, do more regression tests because every change can break some functionality on the other end. Let's hire more devs to work with messy projects, lets spend more money on hiring new devs because old ones are burnt out and the new ones burning out before they even figure out how the project is structured.
Stop talking about tech debt! We need to deliver ASAP, ASAP, ASAP! Money is dust.

And don't even try to allocate time on system design, leave it for interviews, it's better to hire a dev who can explain how to design Amazon in 30 minutes.
Agile!

Great talk. I really like your take on the obsolescence of the technical debt concept and the need to move beyond it. Assuming I understood you correctly, I strongly agree with you in that what we call "technical debt" is actually a failure of product management, and that the solution has to include involving engineers much more in product management decisions (which is something Marty Cagan has long been advocating). If you are interested, a few months ago I published an article with input from Michael Feathers that argues along these lines, with a little bit more detail on how to get people to listen.

Summary: "I can't get my tech debt prioritized" --> "I can get my timely, product-strategy-relevant improvement recommendations prioritized"

I want to agree with this, but mostly I cannot. Tech Debt is a fact of life in all serious applications of scale - most, if not all, of it likely a trade-off to get a feature to its intended audience. Yes, tech debt is backward looking, but we take that one step back because it helps us move two steps forward, to make our services generally more resilient, stable, secure, what have you.

On some level, everything we write is tech debt in ~5-10 years time, if you're that lucky, and that might generously be assuming that code is near flawless, which we know is not. So rather than stop talking about it (which I think we should not do), how should we make better design decisions, understand and document trade-offs better, make it easier to implement for the "next engineer", etc.

I would like to see the code and solutions of department she is responsible for.

Technical debt is not only the source code. It's also updating os, databases, frameworks, programming languages to the latest versions. When you cannot absorb those changes in your project, then you are agile in name only. Also any discussion on cyber security is just a lie then. Compare it to a chef in a 3 star restaurant being forced to cook with ingredients that are expired on best before date and use before date.
The customer of that restaurant expects fresh ingredients to be used. The customer of a software package expects up to date components being used.
No customer will sign a contract accepting outdated technology, the state of technology is never mentioned in contracts, which doesn't give you the permission to use outdated components

As she mentioned at the beginning, „Tech Debt“ got introduced to try to explain to non technical people what needs to be done under the surface to keep a product alive.

As an engineer I once got told to calculate a business case for things that need to be done under the surface as soon as possible at least from my point of view. Is this what an engineer should do? Calculating business cases for things that can’t be calculated easily upfront, but that are clear for every technically skilled person? Delivering proof for every step that is not clearly a feature? Is this a healthy and trusting culture? At least in my case I tried to explain the why, but if I can’t explain it in terms of money it simply doesn’t count. So debt might not be the best word, but it’s still the best we have.

Hmm... I don't agree with this.

I usually don't mention fixing tech debt at all. Cleanup is just part of normal workflow, if I touch a certain part of a system I clean up old cruft in that part with it. A restaurant doesn't include "cleanup of the kitchen" as a separate point on the check. If it is a bigger rework and you really need a lot of time just for that, than of course you must convince your customer that the time spent on this is worth it. That means to evaluate and argue with stuff that really matters: money, deadlines or anything that is measurable and the customer cares about. If that doesn't work, either it is not important/worth it for the business or the customer may or may not learns through pain.

So we're now arguing about semantics? Refactoring and continuous improvement should be embedded within the work, not though of something extra that just needs to be done.

I love the presentation and way she gets to the point.
Engineers often use the notion of tech debt to rationalize what they think is important. Since it seems like terrible idea not to pay debt so non engineers are tempted to pay it back while losing opportunity to talk about how important or serious that is.
So in my opinion, it's just arrogant or lazy not trying to explain why; Every decision should be backed with reasons and those reasons must be understandable in easy words. If it's not, then you're making bad decision and using tech debt as excuse.

The analogy presented fell flat for me because she didn't seem to understand that debt, without interest, is literally free money. Why you care about paying back debt is the interest. She didn't bring this up at all and I really got the feeling she didn't even consider that part of the analogy.

With technology, interest is paid when working with something and it's more difficult, slow, or worse, than what it could be. This slowness or badness is the cost of otherwise free money.

I think the amount of time and energy that went into this presentation could have been better spent cleaning up the tech debt at her company than looking for new metaphors to describe it.

So does it happen that often that people complain about tech debt not being prioritized when said debt is irrelevant?