Technical Debt Management for Long-Term Quality (#230)

Update YouTube description to blog post

site/content/resources/videos/youtube/BAwBXYtKj7o/index.md

@@ -1,11 +1,11 @@
 ---
-title: The Power of Automated Testing
+title: Technical Debt Management for Long-Term Quality
+
 description: Discover how automated testing transforms software engineering, reducing errors and speeding up feedback for high-quality, efficient delivery.
 date: 2024-11-21T07:00:11Z
 videoId: BAwBXYtKj7o
 url: /resources/videos/:slug
-slug: the-power-of-automated-testing
-canonicalUrl: https://www.youtube.com/watch?v=BAwBXYtKj7o
+slug: technical-debt-management-for-long-term-quality
 aliases:
 - /resources/videos/BAwBXYtKj7o
 - /resources/videos/the-power-of-automated-testing
@@ -27,46 +27,49 @@ tags:
 - scrum master
 sitemap:
   filename: sitemap.xml
-  priority: 0.4
-source: youtube
+  priority: 0.6
 
 ---
 {{< youtube BAwBXYtKj7o >}} 
- # The Power of Automated Testing in Modern Software Engineering | Martin Hinshelwood  
+ # Technical Debt Management for Long-Term Quality | Martin Hinshelwood  
+
+  📍  📍 Technical debt is a huge problem for, for organizations. I want to quickly define technical debt. Technical debt is
+
+Future costs that you incur when  you or your team prioritize quick short term solutions over more robust long term approaches.  Right? So anytime you, you make a choice to do something fast but wrong, because you need it fast you're, you're introducing known,  you're knowingly introducing technical debt.
+
+You can also unknowingly introduce technical debt, i. e. we made some architectural choices, they were good choices at the time, but now they're no longer good choices. Technical debt can appear over time. I'm  thinking of a transaction system and we supported x number of transactions per second and our platform of choice was  reasonably priced, was able to support Well beyond what we thought we were going to transact, but now we're transacting a lot more than that, and we're reaching the limits of the system that we chose.
+
+A great example. A great example of that is the Azure DevOps team when they originally envisaged Work item tracking fields. So a, a, a, a work item was a row in a database and fields were a column.  And those of you who are software engineers have already figured out what the problem would be with that, in that you can only have 1024 columns in a SQL database.
+
+So they, they, not quickly but they did hit limitations on the number of columns that you could have for custom fields. Because who would have more than a thousand  fields on a work item? But yeah, people do, they do exist and people do that, and it was a thousand  totally within the system.
+
+So they thought we'd never have a thousand fields. Or somebody made that decision just like the two digit date decision back in the day.  So they had a lot of work to go back and refactor, not just refactor the system, but write the capabilities to  refactor the data on upgrade for their customers into a format where each field was a row right in a database rather than a column.
+
+So then you have unlimited capability for fields and data. And those  types of decisions either knowingly made decisions that result in something that's not not quite the way it needs to be or unknown ones are where most it needs to be. Technical debt comes from there are other issues that people call technical debt, which aren't necessarily technical debt But most people lump it all together and say technical debt.
+
+I think I often do as well And that's i've written bad code and shipped it  That's not technical debt, that's incompetence,  right? So, so, within the context of a competent team, there's known technical debt and unknown technical debt. But there's another thing that we call technical debt, which is just chipping bad code making poor choices. 
+
+Knowing that they're poor choices and not doing anything about it, right? Shipping bad code stop shipping stop shipping bad code would be the way you pay that one back but for technical debt, You need to pay it back. You need to prioritize paying back that technical debt Think of it more as an unhedged fund rather than a debt like a credit card most debt is secured against something secured against an asset.
+
+If you stop paying your mortgage then the bank comes and repossesses your house and gets their money back, right? And maybe you get some leftovers because you've paid some of your mortgage. But  who's, who's insuring  Your product quality. Who's insuring your product against your technical debt?
 
-👋 Hi, I’m Martin Hinshelwood from [NKD Agility](https://www.nkdagility.com), and in this video, I dive into the critical role automated testing plays in modern software engineering. From reducing human error to speeding up feedback cycles, automated testing is a game-changer for delivering high-quality software that drives profit and value for your organization. Let’s explore how to automate smarter, not harder, and build a foundation of engineering excellence.
+There's no insurance. It's uninsured  From from from that perspective and nobody can magically come along and pay back all the all the debt. It's not insured at all  Or sell something and pay back. We claim an asset. So  It's something you're going to have to deal with and you can't like get out of control and there's a lot of unknown technical debt.
 
-**📌 Chapters:**  
+I mean, that's, that's  like, I mean, I use the Azure DevOps team a lot as an example, but they'd been a waterfall team for many years shipping once every two years, and then they moved to a more continuous delivery three week model. And they found that they made lots of poor decisions, right, that didn't, weren't necessarily poor decisions within the context of two year, but they couldn't really see the impact of  the technical debt, the choices that they'd made, deliberate and non deliberate, right, on, on their ability to deliver product and their ability to deliver value.
 
-1. 00:00 – Introduction: Why Automated Testing Matters  
-2. 02:00 – Reducing Human Error with Automation  
-3. 05:00 – The Value of Fast Feedback Loops  
-4. 08:15 – Balancing Test Infrastructure and Complexity  
-5. 12:00 – Lessons from Azure DevOps: Transforming Test Strategies  
-6. 16:30 – Automating Everything: Best Practices for Engineers  
-7. 21:00 – Building a Culture of Engineering Excellence  
+But I have a, I have a, I have a graph of, I think it's 2010 through to. 2018 for, for that product team. So eight years of development and they effectively go by moving to continuous delivery, moving to three week sprints, moving to that faster cycle from a two yearly cycle and running into issues with that and every issue they running into.
 
-**🎯 Who This Video is For:**  
+Paying it back, right? Paying back the reason that they made those choices, which were perhaps valid reasons at the time, but you still need to pay it back. It doesn't matter whether it was a valid reason or not.  And, and paying it back and doing the work, they actually  went from 25 features to production each year in 2010 to something like 360 features to production in 2018.
 
-- Developers and engineers looking to improve their testing practices  
-- Engineering leaders striving for faster, more reliable deployments  
-- Organizations seeking to reduce errors and optimize their software delivery pipeline  
+So by, by focusing on paying back their technical debt of enabling their engineers to close the feedback loops, then shorten the feedback loops, Three ways of DevOps, right?  Closing the feedback loops first, then shortening them. And that act of shortening the feedback loops can massively increase the amount of value that you can deliver long term.
 
-**📖 What You’ll Learn:**  
+And that's the value of paying back technical debt, of managing technical debt well, is that you Can go from the removing those limitations to maximizing the value that you deliver in your product with the same number of people. That was the Azure DevOps team literally went from 25 features to production each year in 2010  worked very hard to pay back technical debt and were able to even in the first year of focusing on paying back technical debt to get their product new way of working up and running.
 
-- Why humans struggle with repetitive tasks and how automation solves this  
-- The risks of chasing code coverage and the value of meaningful tests  
-- How fast-running unit tests can replace slow, error-prone end-to-end tests  
-- The importance of lean, discrete tests for better modularity and reliability  
-- Strategies to automate your testing process and reduce manual steps  
-- Real-world insights from Azure DevOps’ journey to three-minute test cycles  
+They went from 25 features to production to 68 features to production within that one year. And they weren't even focused on delivering more features. They were focused on let's deal with our crap and let's figure out how we deal with those problems. And they still delivered more features. That's the benefit of paying back technical debt.
 
-**💡 Key Takeaways:**  
+That's the benefit of having a slick. Easy system to add features to your product and that's what everybody needs don't Manage technical debt pay it back.
 
-- Automation reduces errors, speeds up feedback, and saves time for delivering value.  
-- Testing should be fast, modular, and as automated as possible for maximum efficiency.  
-- The fewer manual steps between code and production, the better your delivery pipeline.  
-- Automated testing isn’t about quality; it’s about creating opportunities to innovate and grow.  
+
 
 At [NKD Agility](https://www.nkdagility.com), we help teams implement modern engineering practices, build robust testing strategies, and achieve engineering excellence. Ready to reduce errors and deliver faster? Visit us today to transform your software delivery pipeline. Let’s automate the future together!