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

I agree with the notion to categorize and prioritize tech debt as a function of product/business objectives, and that not all tech debt (crust) is worth removing (who does that though). I disagree that we should stop thinking about it. In what is engineering reality trade offs need to be made. Some of these trade offs are good for now but bad for later. That's technical debt. You either fix it or you keep paying interest in the form of more expensive maintenance, future development, support cost or even customer satisfaction.

I would find the argument more persuasive if the speaker gave specific examples of what can go wrong when conventional attitudes to technical debt are manifested in a team. What is the problem that will be solved by stopping talking about tech debt?

same as president Biden, if he can’t increase GPD, redefine the GDP, then make it increase 😂 that makes Biden as president.
If she can’t pay the technical debt, redefine what debt is😂 and that makes her as senior director

Tech debt is just an outdated system’s model in front of a new meaning of the system from technical or business standpoint accessible to the system’s solution builders.

The funding is the problem. If paying down tech debt is represented as an expense, then we end up with businesses that become more expensive and less predictable to run over time.

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

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.

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

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

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.

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

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

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.

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

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!

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.

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

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.

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

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"

I do agree that the word "Tech Debt" does get thrown around as a catch all term for something that doesn't related to technology or debt. In my organisation when we mention it, I do think we all agree that it's an actual debt against the product spec, design or implementation that specifically the engineers didn't meet. Eventually for the sake of the business that debt needs to be paid with interest of extra work to resolve.

So from this perspective if Emily worked in and with perfect engineering teams who completed their features to the fullest extent and never had to circle back to fix something that is missing (and I'm talking specifically the stuff that really does need to be fixed) then I agree that the use of the word "Tech Debt" doesn't really apply, because at this point you are either dealing with legacy code (old, does not serve a purpose anymore - remove it or replace it) or business needs to rethink what they want to focus on.

Eventually you just pile up "tech debt" until it becomes a blocker for the next hot feature that everyone in proudct management wants to edge to.

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.