Types Of Technical Debt And How To Manage Them

Technical debt is a useful and sticky idea. Managing tech debt can be very easy if you stay on top of the 'payments', or one of the most difficult problems in software if you don't. So how to manage technical debt is a big topic.

In this episode Dave Farley, author of best selling books "Continuous Delivery" and "Modern Software Engineering" talks about the different types of technical debt, where the analogy with real debt makes sense, and where it breaks down, and how to really solve the problem of avoiding serious, damaging tech debt.

-------------------------------------------------------------------------------------

🔗 LINKS:

-------------------------------------------------------------------------------------

Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧

_____________________________________________________

📚 BOOKS:

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 Dave’s NEW BOOK "Modern Software Engineering" is available here

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[scottfranco]

I have taken some heat before when joining projects that were in bad shape and the prevailing opinion was that they wanted to start over. I say, "you'll just make the same mistakes over again". I read a great story about a professor who took a position in a college for the electrical engineering section. The lab for it was in terrible shape, the instruments were all broken. The administrator asked the new professor to make a list of needed equipment and he would see if he could find the money for it.

The new professor replied "no, not a problem. We will use what we have". The administrator left, stunned. The new professor started his classes and took the new students out to the lab. Over a course of months, they took apart the broken equipment, got schematics for them, and went over what was wrong with each instrument as a group project. Slowly but surely, they got most of it working again. The students that did this because some of the best engineers the school had seen.

The moral of the story is applicable to software rewrites. The team that abandons the software and starts over does not learn anything from the existing software, even if they didn't write it. They create a new big mess to replace the old big mess. Contrast that with a team that is forced to refactor the code. They learn the mistakes of the code, how to fix it, and, perhaps more importantly of all, become experts at refactoring code.

In the last 2 years, I instituted a goal for myself that I would track down even "insignificant" problems in my code, and go after the hardest problems first. In that time I have been amazed at how often a "trivial" problem turned out to illustrate a deep and serious error in the code. Similarly, I have been amazed at how solving hard problems first makes the rest of the code go that much easier.

I have always been a fan of continuous integration without calling it that. I simply always suspected that the longer it took to remerge a branch in the code, the longer it would take to reintegrate it, vs. small changes and improvements taking a day or so. I can't take credit for this realization. Too many times I have been assigned to merge projects that were complete messes because of the long span of branch development. As the old saw goes, the better you perform such tasks the more of it you will get, especially if others show no competence in it.

[ralftaraschewski]

I agree. Problem is you have to lock managers( or customers!) in room and play your videos in an endless loop until they understand. Otherwise you get technical debts by command.

[olvinjanoisin]

My favorite concept is “code viscosity”. That means how easy it is to make changes and implement new features the correct way and it’s by far the most important thing when designing an architecture.

[travisabrahamson]

As an Architect in my company, I've had arguments about how Technical Debt effects our productivity. Sadly since there are some that don't listen to the advice I and others give they tend to prove time and again they are not borrowing from a friend as Knuckles keeps showing up.

[ilovepickles]

Knuckles is a great name for a testing framework.

[nouai]

I'm glad that this video clarifies my subliminal experience as Software Reliability Engineer. Sometimes you just don't have enough time to think about such things.

I remember one product which have had bad design with a lot of bottlenecks with long maintenance time to fix these technical debts... This was pure nightmare.
I was not fired as previous guy just because I consistently noted every bottleneck and reported them to the responsible team (as the result the list was huge and we have migrated to the other service), when the previous guy didn't do that and I believe this was the reason that he stuck in the "swamp" of technical debt of the external service team and was fired.

[michaelpastore]

Technical debt is my life. Paying it down is an art that not many developers can do. Heck, merely not accumulating too much debt is an art that not many developers can do.

[DudeWatIsThis]

Uncle Bob mentioned a project he worked on for a while where his team was developing the same program twice - one was the old, broken mess, and the other one was the refactored, clean version. Feature-wise, the refactored, clean version was 1-2 years behind the main version. They were simply cleaning behind the mess of the previous devs, not adding anything.

They finally catched up _20 years later, _ though this is a lie, and they never really catched up. They told the client that it "sucks to be you", bricked the new/dirty version, and just forced them to use the outdated, refactored version. Nobody was pleased.

[imqqmi]

I think there's also the reverse of technical debt, technical credit or something like that. It's putting a system in place that you know is going to pay dividends later and during the livespan of the solution.

[Larock-wuuu]

Amazing, now I can finally put a name to my struggles of the last weeks! Thanks for bringing this up!

[GamingPalOllieMK]

I didn't know this was a thing or that it even had a name! Thank you! As an illustrator whenever people tell me to take the simpler/easier approach that seems easier to them I tell them that later on I wouldn't be able to implement changes or would need to spend more time fixing things if I do that, most don't get it but I know not to fall for their advice. I've had similar types of advice be given to me the few times I programmed some small games for myself and I am glad I did not take their advice, the one time I did that I regretted it big time.

[snkite]

Another great video Dave, thanks.

Two things you didn't mention that I think are overlooked in technical debt discussions
- Technical debt associated with switching developers (ie replacing the development team)
- Technical debt associated with switching frameworks. (ie, let's rewrite in framework X, it's the latest thing...)

There's a ton of technical debt, when a new developer and a new framework looks at a change in a system they are unfamiliar with, no matter how the original system was written.

[serhiicho]

Best explanation of technical debt on YouTube. Thank you very much

[SaidAlhayek]

As usual ! Fantastic video ! I love your content! And your description of tech debt !!

[MTonik]

When I started watching this I expected banalities along the lines of “managers suck” and “they don’t get the beautiful code”. But it was much more deep than that. Thanks!

[salvatoreshiggerino]

What we need to do is teach accountants how to write technical debt in the books. That way the shareholders would see for themselves what a terrible state the company is in, and the C-suite can make better prioritisation.

[JorgeEscobarMX]

This is his best video yet. I'm going to pirate it for my next Teams meeting.

[dmlled]

This is a superb career advice and orientation video for various experience levels: recognize and discover the potential deficiencies in a prospective employer, and decide for yourself whether you want to be there, or set the stage by proposing to help them move away from harmful ideas.

[viktorjamrich]

Fantastic tutorial... I absolutely agree... I worked with so many teams accumulating tech debt and never taking the time to repay it that the systems became such a garbage that putting out fires became the no 1 problem and priority and release of new features almost guaranteed having new visible bugs thus having to put out fires again... 😊

[PeterPerhac]

This was an awesome episode. A few things "clicked". Thank you