Search a title or topic

Over 20 million podcasts, powered by 

Player FM logo
Artwork

Content provided by Elevano. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Elevano or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Why Tech Debt Isn’t the Enemy

26:05
 
Share
 

Manage episode 481742274 series 2833920
Content provided by Elevano. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Elevano or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.

In this episode, Amir sits down with Brent Keator, an expert advisor at Primary Venture Partners, to unpack one of the most debated engineering challenges: tech debt versus reengineering. They explore how to define tech debt, when to refactor versus rebuild, the ROI of revisiting old code, and how AI is (and isn't) changing the equation. This is a must-listen for engineering leaders navigating complex technical decisions in fast-moving environments.

🔑 Key Takeaways:

Tech debt isn't always bad—just misunderstood. Brent reframes it as part of the software evolution, often misjudged in hindsight with unrealistic expectations.

Refactoring isn't an all-or-nothing decision. Brent recommends carving out 30–40% of engineering time for tech debt if possible, and viewing it as iterative maintenance tied to business value.

Reengineering has a cost—evaluate wisely. Use the “better, faster, cheaper” test before replacing tools or platforms, and always account for hidden transition costs.

AI can help but won’t eliminate tech debt. While AI improves productivity, Brent argues it doesn’t change the underlying truth: software is disposable, and architecture still needs discipline.

⏱️ Timestamped Highlights:

00:00 – Intro to Brent Keator and the episode focus: tech debt vs reengineering

01:01 – Defining tech debt across code, products, and organizational habits

02:53 – When reengineering tools goes too far or solves the wrong problem

04:35 – The stigma of tech debt and how to rethink it

08:55 – The cost of revisiting old code and the ROI on fixing the past

11:12 – Why tech debt in engineering is fundamentally different than other domains

12:44 – When to rebuild, how to evaluate tool replacements, and the abstraction advantage

16:23 – Vetting open-source solutions: cost, support, and security risks

18:36 – The emerging role of AI in engineering and why trust and testing still matter

23:20 – Will AI help solve tech debt? Brent’s take on the future of disposable code

24:46 – How to connect with Brent and final thoughts

💬 Quote of the Episode:

“What we write today is going to be gone tomorrow. Whether AI helps or not, we need to get comfortable with that.” – Brent Keator

  continue reading

455 episodes

Artwork
iconShare
 
Manage episode 481742274 series 2833920
Content provided by Elevano. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Elevano or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.

In this episode, Amir sits down with Brent Keator, an expert advisor at Primary Venture Partners, to unpack one of the most debated engineering challenges: tech debt versus reengineering. They explore how to define tech debt, when to refactor versus rebuild, the ROI of revisiting old code, and how AI is (and isn't) changing the equation. This is a must-listen for engineering leaders navigating complex technical decisions in fast-moving environments.

🔑 Key Takeaways:

Tech debt isn't always bad—just misunderstood. Brent reframes it as part of the software evolution, often misjudged in hindsight with unrealistic expectations.

Refactoring isn't an all-or-nothing decision. Brent recommends carving out 30–40% of engineering time for tech debt if possible, and viewing it as iterative maintenance tied to business value.

Reengineering has a cost—evaluate wisely. Use the “better, faster, cheaper” test before replacing tools or platforms, and always account for hidden transition costs.

AI can help but won’t eliminate tech debt. While AI improves productivity, Brent argues it doesn’t change the underlying truth: software is disposable, and architecture still needs discipline.

⏱️ Timestamped Highlights:

00:00 – Intro to Brent Keator and the episode focus: tech debt vs reengineering

01:01 – Defining tech debt across code, products, and organizational habits

02:53 – When reengineering tools goes too far or solves the wrong problem

04:35 – The stigma of tech debt and how to rethink it

08:55 – The cost of revisiting old code and the ROI on fixing the past

11:12 – Why tech debt in engineering is fundamentally different than other domains

12:44 – When to rebuild, how to evaluate tool replacements, and the abstraction advantage

16:23 – Vetting open-source solutions: cost, support, and security risks

18:36 – The emerging role of AI in engineering and why trust and testing still matter

23:20 – Will AI help solve tech debt? Brent’s take on the future of disposable code

24:46 – How to connect with Brent and final thoughts

💬 Quote of the Episode:

“What we write today is going to be gone tomorrow. Whether AI helps or not, we need to get comfortable with that.” – Brent Keator

  continue reading

455 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Listen to this show while you explore
Play