Vox

Leitura de 73 min

#239 - Taming Your Technical Debt: Mastering the Trade-Off Problem - Andrew Brown

Summary

This episode of Tech Lead Journal features Dr. Andrew Richard Brown, author of ‘Taming Your Dragon: Addressing Your Technical Debt’. The conversation challenges the conventional view of technical debt as purely a technical problem, reframing it as a complex trade-off issue involving human psychology, organizational dynamics, and economic principles.

Andrew introduces his ‘technical debt onion model’ with five layers: technical, trade-off, systems, economics, and wicked problems. He explains that while the technical layer is what engineers typically focus on, the more significant challenges lie in understanding how emotional decision-making (using the affect heuristic) causes technical debt to fare poorly in trade-offs against immediate, concrete features. The discussion explores why logical arguments about future technical debt costs often fail, while emotional appeals and storytelling can be more effective.

The conversation delves into how organizational systems create misaligned incentives (principal-agent problems) and externalities where decision-makers aren’t the ones who pay the debt. Andrew draws parallels with historical policy failures like alcohol prohibition to illustrate systems thinking concepts. He also discusses how software development’s ‘wicked problem’ nature—where the problem isn’t fully understood until you develop solutions—complicates technical debt management.

Throughout the episode, Andrew emphasizes that managing technical debt effectively requires starting early to avoid unnecessary debt creation rather than trying to ‘burn it down’ later. He provides practical advice including using Ulysses contracts, painting emotional pictures of consequences, and maintaining sustainable development pace. The episode concludes with Andrew’s three wisdom points for technical leaders: read more deeply in published works, read more widely outside your domain, and deliberately allocate time for this learning.

Recommendations

Books

  • Taming Your Dragon: Addressing Your Technical Debt — Andrew’s own book that explores the multi-layered nature of technical debt beyond just technical aspects, covering trade-offs, systems thinking, economics, and wicked problems.
  • Programming Pearls — Mentioned as an example of a wonderful book with great ideas that developers should read more of, rather than just consuming social media content.
  • Lessons Learned in Software Testing — Cited as another example of a book containing really great ideas that represents deep thinking worth investing time in.

Educational-Resources

  • MIT online courses — Andrew mentions that institutions like MIT offer loads of free online courses, providing high-quality education without cost barriers for skill development.

Topic Timeline

  • 00:00:00 — Introduction to technical debt as a trade-off problem — Andrew Brown introduces the core thesis that technical debt is not really a technical problem but a problem about trade-offs. He explains that people take on technical debt to achieve something they couldn’t otherwise do, like delivering features faster or meeting project deadlines. The emotional aspect of decision-making is highlighted as a key factor in why technical debt often gets prioritized poorly.
  • 00:02:20 — Andrew’s career journey and lessons learned — Andrew shares three career turning points: his PhD in semiconductors during an industry recession taught him flexibility; working globally with scientific instruments exposed him to different cultures; and transitioning from hardware to software despite initial reluctance. He emphasizes the importance of keeping skills updated and being adaptable in a changing technological landscape, especially relevant with current AI disruptions.
  • 00:09:12 — Defining technical debt and the financial debt analogy — Andrew provides a conventional definition of technical debt as additional future work resulting from choosing expedient short-term solutions. He discusses the benefits and limitations of the financial debt analogy—while it helps people understand the concept quickly, technical debt differs crucially in having unknown interest rates, uncertain repayment timelines, and potential for others to incur debt on your behalf.
  • 00:18:21 — The technical debt onion model introduction — Andrew introduces his five-layer onion model for understanding technical debt: technical, trade-off, systems, economics, and wicked problems. He explains that the technical layer is just the surface, with deeper layers involving how humans make emotional trade-offs, how organizational systems create misaligned incentives, how economic principles like externalities apply, and how software development’s ‘wicked problem’ nature complicates solutions.
  • 00:25:12 — Deep dive into the trade-off layer and emotional decision-making — Andrew explains how the affect heuristic drives emotional decision-making, often subconsciously. He uses the smoking analogy to show how health warnings (logical, future-focused) failed until replaced with emotional imagery of damaged body parts. For technical debt, he suggests similar approaches: telling stories, painting pictures of consequences, and using Ulysses contracts to commit future resources to debt repayment.
  • 00:36:35 — Systems thinking layer and organizational dynamics — The discussion explores how social systems within organizations create sub-goals that conflict with overall objectives. Andrew uses the historical example of alcohol prohibition in the US to illustrate how well-intentioned policies can create unintended consequences (organized crime growth) when system dynamics aren’t considered. He relates this to software projects where different teams (development, testing, business) have conflicting incentives.
  • 00:41:54 — Economics layer: Principal-agent problems and externalities — Andrew explains two key economic concepts relevant to technical debt: principal-agent problems (where agents’ goals don’t align with principals’) and externalities (where decision-makers impose costs on others without consequence). He shares personal experiences from HMV where project managers would create technical debt saying ‘that’s not my problem,’ illustrating how organizational structures enable destructive externalities.
  • 00:48:12 — Wicked problems layer and political landscapes — The conversation examines how software development constitutes a ‘wicked problem’ where different parties have different beliefs about what the problem and best solutions are. Andrew notes that technical people often struggle with the political dimensions of these problems, while business stakeholders better understand the political landscape. This creates communication gaps where technical and business teams argue in ‘different languages.’
  • 00:52:20 — Practical advice for managing technical debt — Andrew emphasizes that organizations should focus on avoiding unnecessary technical debt creation rather than trying to manage it after accumulation. He compares it to maintaining sustainable development pace—you can’t sprint then slow down when exhausted. Key strategies include pushing back on ‘essential’ features, making trade-offs explicit, and preventing the mindset that debt can always be paid down later.
  • 00:56:21 — AI’s impact on technical debt creation — The discussion turns to how AI, particularly via ‘vibe coding’ by non-technical people, may dramatically increase technical debt. While AI could help reduce some types of debt (like documentation or test generation), the ease of generating code creates risks of building on flawed foundations. Andrew shares anecdotes of developers using AI for research but manually coding solutions, though acknowledges people may underreport AI-driven development.
  • 01:00:52 — Three technical leadership wisdom points — Andrew concludes with three advice points: 1) Read more deeply in published books where authors have invested hundreds of hours of thought; 2) Read more widely outside your domain to gain different perspectives, including views you disagree with; 3) Allocate dedicated time in your calendar for this deep, wide reading rather than relying on social media snippets or blog posts.

Episode Info

  • Podcast: Tech Lead Journal
  • Author: Henry Suryawirawan
  • Category: Technology
  • Published: 2025-11-17T12:00:00Z
  • Duration: 01:06:29

References

Podcast Info

Transcript

[00:00:00] Technical debt is not really a technical problem.

[00:00:02] It sounds as if it is,

[00:00:03] because it’s got the word technical in there

[00:00:05] and it’s got this debt,

[00:00:05] but really what it is,

[00:00:06] is it’s a problem about trade-offs.

[00:00:09] Today’s guest is Andrew Richard Brown,

[00:00:11] the author of Taming Your Dragon,

[00:00:12] Addressing Your Technical Debt.

[00:00:14] He has spent over two decades

[00:00:15] uncovering the hidden human factors

[00:00:17] behind technical problems

[00:00:18] that challenge how we think about technical debt,

[00:00:20] risk, and project estimation.

[00:00:21] I always find it quite fascinating

[00:00:23] because we all hate technical debt,

[00:00:24] but every time, either consciously or unconsciously,

[00:00:26] we are also creating technical debt ourselves.

[00:00:28] The way we make any decisions is we use our emotions.

[00:00:31] We may think we use logic,

[00:00:32] but actually we use our emotions.

[00:00:34] If you look at the technical debt,

[00:00:36] potentially you’re going to have to repay some debt

[00:00:39] in the future.

[00:00:40] Something that is in the future

[00:00:42] is going to appeal to your logic.

[00:00:44] That’s principally why the technical debt does badly.

[00:00:46] From all these layers,

[00:00:47] technical aspect is just a small part of the technical debt.

[00:00:50] There are so many other things like organizational system,

[00:00:52] the biased thinking, the emotion.

[00:00:54] How can an organization start managing

[00:00:56] their technical debt better?

[00:00:57] What you really need to be,

[00:00:58] what you’re doing is avoiding creating the technical debt

[00:01:00] that you can avoid creating.

[00:01:02] You can’t do development really, really fast,

[00:01:04] and then when you become completely tired,

[00:01:06] now we will slow down to a sustainable rate.

[00:01:08] It’s a bit too late.

[00:01:09] You need to make arguments

[00:01:10] that are appealing to people’s emotions,

[00:01:12] not to their logic.

[00:01:13] You can sort of paint a picture.

[00:01:14] You can tell a story.

[00:01:15] If you’re coming at it from the viewpoint

[00:01:17] of we need to manage this technical debt or burn it down,

[00:01:20] you’re almost starting too late.

[00:01:21] Once you do that,

[00:01:22] it’s almost as if you’ve given the business permission

[00:01:24] to create this technical debt

[00:01:25] because you can just pay it down later.

[00:01:28] Hello, guys.

[00:01:44] Welcome back to another new episode

[00:01:45] of the Tech Lead Journal podcast.

[00:01:46] Today, I’m very excited to have Dr. Andrew Richard Brown.

[00:01:50] I’ll call him Andrew Brown in this episode.

[00:01:53] So Andrew is the author of a book titled Taming Your Dragon.

[00:01:57] So it’s a book about the technical debt.

[00:01:58] It’s a book about tackling or managing technical debt,

[00:02:01] which I’m sure all the engineers here know about technical debt.

[00:02:05] We hate technical debt,

[00:02:07] but also at the same time,

[00:02:08] sometimes we create technical debt ourselves.

[00:02:10] So today we are going to learn

[00:02:12] what is actually technical debt

[00:02:13] and how can we manage it much, much better from Dr. Andrew.

[00:02:17] So Andrew, looking forward for this conversation.

[00:02:20] Thank you so much for this opportunity.

[00:02:22] Thank you for inviting me on.

[00:02:24] Right.

[00:02:25] Andrew, in the very beginning,

[00:02:27] I’d always love to…

[00:02:28] invite my guests to share a little bit more about yourself, right?

[00:02:31] Maybe you can use like career turning points

[00:02:33] that you can share so that we can learn from you.

[00:02:36] Yeah, sure.

[00:02:36] So, yeah, so I think that there was perhaps

[00:02:39] about three career turning points for myself, really.

[00:02:42] So the first one was I did a PhD in semiconductors

[00:02:45] and so I had a plan

[00:02:47] and my plan was to have a career in semiconductors

[00:02:50] because I could see that as a bright future

[00:02:53] and there was going to be a big future in semiconductors there.

[00:02:56] But when I graduated,

[00:02:58] the semiconductor industry was in recession

[00:03:00] and it remained in recession for about two years or so.

[00:03:05] And so I think then that basically that taught me

[00:03:09] an important lesson right at the start of my career,

[00:03:11] which was that actually,

[00:03:13] although you may have flat plans,

[00:03:14] you are going to have to be flexible about those plans.

[00:03:17] And so I looked around

[00:03:20] and eventually I got another job in a different industry,

[00:03:24] which was in scientific instruments.

[00:03:26] And I travelled around the world,

[00:03:28] actually, as an engineer installing these machines.

[00:03:32] So they were pretty big machines.

[00:03:33] They were called mass spectrometers.

[00:03:35] They were about the size of a car,

[00:03:37] weighed a couple of tonnes

[00:03:38] and they cost about half a million pounds

[00:03:40] and they took about three months to install.

[00:03:42] So you’re spending a lot of time in foreign countries there.

[00:03:46] So I saw a lot of different countries,

[00:03:49] a lot of different cultures

[00:03:50] and that sort of woke you up as well

[00:03:52] to things could be different, equally valid there.

[00:03:55] And actually, that’s where I met my wife,

[00:03:57] my wife,

[00:03:58] my late wife.

[00:03:59] I was working in Japan

[00:04:01] and I then met her whilst I was working out there.

[00:04:05] And again, that came to another big career decision

[00:04:08] and I decided to move to Japan so that we could be together.

[00:04:12] And so I moved to Japan.

[00:04:13] We had a nice time.

[00:04:14] And then eventually we came back

[00:04:16] and we lived and settled down in England there.

[00:04:19] The other big change or the big career turning point

[00:04:22] was that when I started,

[00:04:23] I was in a lot of hardware there

[00:04:25] and I resisted.

[00:04:27] I could see that.

[00:04:28] Software was increasing,

[00:04:30] but I resisted going into it.

[00:04:32] And part of the reason was that I could see that I knew some friends

[00:04:35] and they’d been in software development,

[00:04:38] but the technology had moved on.

[00:04:40] The languages they were using had gone out of fashion

[00:04:43] and they were out of a job

[00:04:44] and they found it very difficult.

[00:04:47] And so I was very reluctant to get into an industry

[00:04:49] where they just threw people out of work like that.

[00:04:52] But actually, eventually I went in there

[00:04:55] and I’m glad I did

[00:04:56] because although,

[00:04:57] and I have been thrown out of work a couple of times,

[00:05:01] actually, so long as you’re keeping your skills up to date,

[00:05:04] and that’s a really important thing in software,

[00:05:06] if you keep your skills up to date

[00:05:08] so you’ve got something marketable,

[00:05:10] you may lose one job,

[00:05:11] but there will be another job there somewhere

[00:05:13] that you can get into.

[00:05:15] And so I would say that that was an important lesson there,

[00:05:19] really, of making sure that you always stay up to date

[00:05:23] and current or you’re learning something new.

[00:05:25] Always, always be learning something new.

[00:05:27] Yeah.

[00:05:28] Thank you for sharing your story.

[00:05:29] I think it’s very insightful and very timely as well

[00:05:32] in this kind of a time, right, where people,

[00:05:34] maybe some of us are feeling a little bit concerned about our jobs,

[00:05:37] our career, maybe because of the AI disruption,

[00:05:39] maybe because of the economical situations

[00:05:42] and so many changes happening globally.

[00:05:44] So I think I really love the first point as well,

[00:05:47] where you should be flexible.

[00:05:48] I think many people’s career, right,

[00:05:51] doesn’t go as planned in the very beginning, right?

[00:05:53] We always love to plan, oh, I want to do this.

[00:05:55] I want to stay on this career track,

[00:05:57] climb the ladder or something like that.

[00:05:58] But most of the people that I’ve talked to actually said

[00:06:01] that their career plan actually are different

[00:06:04] than what they used to think about in the very beginning.

[00:06:07] Before we continue, I want to tell you about our sponsor,

[00:06:10] Jellyfish, who helps engineering teams

[00:06:12] measure the real impact of AI adoption.

[00:06:15] Let’s hear what they have to say.

[00:06:17] 90% of engineering teams use AI,

[00:06:20] but few can measure its actual impact.

[00:06:25] It doesn’t have to be.

[00:06:27] It doesn’t have to be a guessing game.

[00:06:29] Jellyfish gives you a comprehensive view

[00:06:31] across your AI development activity.

[00:06:34] Know where AI hurts, where it helps,

[00:06:38] and how to guide your team with confidence.

[00:06:42] Learn more at jellyfish.co.ai

[00:06:44] And now let’s get back to our episode.

[00:06:49] So I think maybe let’s touch on a little bit on this.

[00:06:51] So for people who are maybe in lots of concerns these days

[00:06:55] or whatever situation that they are in,

[00:06:57] so maybe looking back,

[00:06:59] what kind of confidence that made you, you know,

[00:07:03] brave enough to take those kind of risky moves,

[00:07:06] maybe back then, right?

[00:07:07] Because you just said your friends, you know,

[00:07:09] got out of a job because programming language changed

[00:07:11] and things like that.

[00:07:11] So maybe people can get some inspiration

[00:07:13] from your journey as well.

[00:07:15] Yes, I would say that in terms of making risky moves,

[00:07:21] yeah, it’s something that actually people talk about afterwards,

[00:07:24] but at the time, they’re not actually,

[00:07:27] as risky or you make it as un-risky as least risky as possible.

[00:07:32] So for example, if AI is coming along,

[00:07:36] it would be madness to leave your job and start learning AI

[00:07:40] or something like that.

[00:07:41] You should be continuing in what you are seeing what is happening.

[00:07:44] And most of us can read fairly clearly that big things are happening in AI.

[00:07:51] And you can actually then start to learn about AI and get some skills there.

[00:07:57] That are marketable in the environment and in the industry.

[00:08:00] Because one of the terrific things about the internet is

[00:08:04] that’s so much knowledge, so much information.

[00:08:08] Firstly, it’s available.

[00:08:10] And secondly, so much of it is available for free.

[00:08:13] You don’t have to be paying lots and lots of money for these things.

[00:08:17] You can do it.

[00:08:18] And there’s people out there that are happy to take your money off you.

[00:08:21] But there’s enormous amounts that is free.

[00:08:25] And a lot of it is from very, very good people.

[00:08:27] And institutions like the MIT, Massachusetts Institute of Technology,

[00:08:31] is giving away loads and loads of these online courses for free there.

[00:08:35] So look for education that’s free and get yourself skilled up

[00:08:41] before you need to be skilled up.

[00:08:43] Yeah, I think it’s always very useful to always keep yourself kind of

[00:08:47] like hungry for knowledge, right?

[00:08:49] Keep learning as and when new technology coming in.

[00:08:51] Definitely we have fears.

[00:08:52] I also have fear about, you know, how AI is going to disrupt my role.

[00:08:57] But I guess depending on your passion, depending on your interests as well,

[00:09:00] you can always keep that hunger to always learn, upskill yourself and make yourself

[00:09:05] marketable, that which is something that is very important as well.

[00:09:08] So Andrew, today we are going to talk about your book, Taming Your Dragon,

[00:09:12] Addressing Technical Debt.

[00:09:14] So in the first place, maybe let’s go to the definition of technical debt,

[00:09:18] because many people in the engineering, software engineering industry would

[00:09:21] have used technical debt as a term, maybe quite loosely, so maybe in the first place,

[00:09:27] what do you mean by technical debt?

[00:09:29] So I think that I would be fairly conventional with what I mean by technical debt.

[00:09:35] I would take technical debt to be the additional work, which you will, or someone

[00:09:40] will need to do in the future as a result of choosing to a solution, which is expedient

[00:09:48] in the short term, but is going to cause you longer term issues there.

[00:09:53] So I would say it’s no more than that really.

[00:09:57] Well, this is a quite a very interesting definition because yeah, you can see that

[00:10:02] there’s kind of like a trade off here, right?

[00:10:04] So long-term kind of a problems, but a very, maybe short, fast delivery, right?

[00:10:10] It’s kind of like taking shortcut in a sense.

[00:10:12] So I think I like that definition, right?

[00:10:13] So because many people associate technical debt in software engineering, especially

[00:10:18] with financial debt, so, you know, thinking about, okay, we take some debt here, maybe

[00:10:22] for our loans, mortgage, whatever that is, right, and we’ll kind of like repay them back some

[00:10:27] time.

[00:10:27] So I know in your book, you mentioned about this kind of analogy, maybe it’s broken in

[00:10:32] some ways.

[00:10:33] So maybe tell us why financial debt may be not a good association with technical debt.

[00:10:38] Yeah.

[00:10:38] So certainly I think that, well, the first thing to say about the analogy to financial

[00:10:42] debt is that it’s given us tremendous benefits there.

[00:10:46] And because first and foremost, everybody understands financial debt.

[00:10:52] So everybody has taken out a loan or owed money in some way.

[00:10:57] And so they understand that they understand the benefits and they understand the consequences.

[00:11:01] So they understand that perhaps if they take on some debt, they can do things that they

[00:11:05] couldn’t otherwise do.

[00:11:06] And that’s the benefits of it.

[00:11:08] So, you know, you, if you, you want a job in the next city, but you need a car to get

[00:11:13] there, then you take out a car loan.

[00:11:15] And so that’s a good debt to take out.

[00:11:18] And you also understand that you’re going to have to continue paying that after you’ve

[00:11:22] received the benefits.

[00:11:24] It’s very useful in that way because it gets people.

[00:11:27] It gets people to understand it very, very well.

[00:11:29] So it allows people very quickly to understand the essence of it.

[00:11:34] The problem with the analogy of technical debt is that it isn’t an exact analogy.

[00:11:40] And so technical debt is, it would be like you took out a car loan in order to get this

[00:11:47] job, but you don’t know what your interest rate is and you don’t know when you’re going

[00:11:52] to have to repay it.

[00:11:54] And maybe you’re never going to have to repay it.

[00:11:56] Maybe somebody else is going to have to repay it.

[00:11:57] You know, in which case we’ll take out some more and you don’t know exactly all these

[00:12:04] details of it and you don’t know what the interest rate is and you don’t know the repayments

[00:12:09] or anything like that.

[00:12:10] And also perhaps the most scary thing is that at the same time you’re taking out this technical

[00:12:15] debt, perhaps someone is handing out lots and lots of credit cards to that account there

[00:12:20] and all these other people, including your daughter, spendthrift daughter, she can then

[00:12:25] go out and.

[00:12:27] Rack up lots and lots of debt on this there to get benefits for herself, which you’re going

[00:12:31] to have to pay out.

[00:12:32] So that’s perhaps a closer analogy to what the technical debt really is.

[00:12:37] It’s a very scary, very strange kind of financial debt there.

[00:12:41] Right.

[00:12:42] So I love that you mentioned that we don’t know the interest rate that is going to be

[00:12:46] accumulated if you don’t pay, repay the debt, so to speak.

[00:12:49] Right.

[00:12:50] And you cannot also don’t know when you should repay the debt fully.

[00:12:53] Right.

[00:12:53] So I think that’s a very good reminder, right?

[00:12:57] When we talk about financial debt, usually it comes up with all these commitments, you

[00:13:00] know, contract, whatever that is, right?

[00:13:02] Upfront.

[00:13:03] But when we incur technical debt, probably we don’t know how to answer some of those.

[00:13:07] So you mentioned about, for example, people take technical debt for shortcut.

[00:13:12] Some of these are really not just technical kind of decision, right?

[00:13:15] But in your book, you mentioned it could be organizational issue or some kind of human

[00:13:19] bias.

[00:13:20] So tell us these two elements.

[00:13:22] Why is it also important to actually put in place when you want to understand technical

[00:13:26] debt?

[00:13:27] So I think the first thing to understand about technical debt is that it’s not really

[00:13:32] a technical problem.

[00:13:33] It sounds as if it is because it’s got the word technical in there and it’s got this

[00:13:37] debt.

[00:13:38] But really what it is, is it’s a problem about trade-offs.

[00:13:42] So nobody takes on technical debt just for the fun of it.

[00:13:46] We take on technical debt for a reason.

[00:13:49] And usually we take on the technical debt because we want to be able to do something

[00:13:55] that we couldn’t otherwise do.

[00:13:57] If we didn’t take on that debt.

[00:13:59] So it’s usually, it’s going to be something like we want additional features there.

[00:14:04] So for example, the product manager might, they know that they, that this technical debt

[00:14:10] is going to be bad for the product long-term, but they need to squeeze this extra feature

[00:14:14] in.

[00:14:15] Or perhaps it is for a project manager.

[00:14:17] It is, they know that piling up technical debt is going to be a problem, but they need

[00:14:23] to get this project in and they are being measured by that.

[00:14:26] So it’s,

[00:14:27] technical debt is just a consequence of a trade-off that people have made.

[00:14:31] So they’ve made it there.

[00:14:33] That then leads to an interesting point because practically every company you go into, they

[00:14:38] will say, we’ve got too much technical debt.

[00:14:41] So then you’ve really got to ask, well, what does that mean?

[00:14:44] You know, it must mean that you’ve made trade-offs that now you’re regretting.

[00:14:49] In which case, then you have to ask, well, what has caused you to make trade-offs that

[00:14:54] you now regret that?

[00:14:55] And then that gets in.

[00:14:57] And then that gets into the technical debt, the trade-off there.

[00:15:01] So really, if you want to understand why you’ve got too much technical debt, you’ve really

[00:15:05] got to understand how your mind makes trade-offs and how you trade one thing for another, and

[00:15:12] why it is that technical debt comes off so badly in that trade-off really.

[00:15:17] Henry Suryawirawan 1 Yeah.

[00:15:17] So I always find it quite fascinating because I personally also have this kind of thinking,

[00:15:22] right?

[00:15:22] So we all hate technical debt.

[00:15:24] Every time we go to organizations, seeing any kind of code base.

[00:15:26] We thought really, really fast that, okay, this is not good.

[00:15:29] This design probably doesn’t scale well.

[00:15:31] It’s a technical debt here and there.

[00:15:33] But every time we create, for example, new code, develop something new, either consciously or

[00:15:39] unconsciously, we are also creating technical debt ourselves.

[00:15:42] I think also maybe because this is the nature of software development where you can’t always, you know, create a perfect

[00:15:47] design since the very beginning, right?

[00:15:49] So maybe tell us this kind of, I would say it’s a paradox, right?

[00:15:52] Sometimes you hate technical debt, but you’re always incurring it no matter what.

[00:15:56] What do you think?

[00:15:56] What do you think would be a good mindset for software engineers out there to have a healthier relationship with technical debt?

[00:16:03] David Elikwu Smyth I think that really, to have a healthier relationship with technical debt, what they need to be doing is the engineers need to be moving beyond thinking of technical debt as this technical problem there.

[00:16:17] It’s actually, because it’s a trade-off problem, almost certainly they are only going to be partially involved in making that trade-off.

[00:16:26] David Elikwu Smyth Very often, it’s going to be the stakeholders.

[00:16:29] And so the stakeholders, they’re going to want this project in, or they’re going to want these features.

[00:16:35] And they are prepared to put up with, either put up with this technical debt or they are unaware of the long-term consequences of it.

[00:16:43] David Elikwu Smyth So it’s really, it’s having that conversation and uncovering and surfacing these contradictions there and basically between the technical debt.

[00:16:56] balancing technical debt and balancing whatever those business needs are because if you built

[00:17:04] software so there was no technical debt it would be delivered so late that it had no business purpose

[00:17:09] there so that there has to be some kind of trade-off and it’s probably it’s going to have to

[00:17:15] be made by the business but the business aren’t sufficiently well informed about the technical

[00:17:21] consequences of this that they can make a fully informed decision so it’s having those

[00:17:27] conversations there with the business around it so they can do a better balancing act there

[00:17:32] right i think it’s a very good reminder because sometimes technical people software engineers we

[00:17:38] love to make decisions solely purely from technical point of view right but i think you you just put

[00:17:43] up a good reminder because you need to communicate you need to unsurface uncover this kind of a

[00:17:49] potential issues if

[00:17:51] let’s say you take a certain decisions i would say it’s more like an informed trade-off rather than

[00:17:55] you know purely just technical basis kind of like a trade-off and sometimes also when we develop we

[00:18:01] know that it’s going to go into certain direction and we just assume many assumptions in our head

[00:18:07] that okay this will go this way but actually if you talk about it maybe with your team maybe with

[00:18:11] the stakeholders i mean it could turn out to a different direction maybe different trade-off

[00:18:15] will be taken altogether right so maybe speaking of which for putting a healthier

[00:18:21] decision i would say it’s more like an informed trade-off rather than you know purely just technical

[00:18:21] relationship i know that you also come up with this technical debt onion model which is kind of

[00:18:25] like framework or maybe perspectives how we we should i don’t know like uncover different layers

[00:18:31] of technical debt so tell me uh first of all the idea of this onion model so the idea about the

[00:18:38] onion was that well the first part was i had this realization that technical debt is not a technical

[00:18:44] problem it’s this trade-off problem and then understanding that but then i gradually i

[00:18:50] realized that i had this realization that technical debt is not a technical problem

[00:18:51] even if you address the trade-off problem there so in other words if you understood how we make

[00:19:01] trade-offs there and the way that we make trade-offs is or in fact the way we make any

[00:19:06] decisions is we use our emotions we may think we use logic but actually we use our emotions

[00:19:12] and what we use in our logic is it’s just post-decision rationalization we use we use

[00:19:17] logic to rationalize the decision that our emotions made

[00:19:21] in which case then you’ve got to understand well why in that emotional decision does technical debt

[00:19:26] fare so badly i look at that in the book there and talk about that but then what i realized was

[00:19:32] that even if you address those problems there and you know that this technical debt is bad and you

[00:19:38] know and you understand emotionally what happens is that actually you’re not making your decision

[00:19:45] as an isolated individual you’re making your decision as a role in an organization

[00:19:51] and in that role you’ve got some responsibilities some demands that are made upon you so

[00:19:56] if as the project manager you are making that trade-off decision about technical debt

[00:20:01] you may know that it’s really bad for the company to take this on but also you are being measured by

[00:20:08] getting this project in and you’ve got to getting it in on time and that’s what you’re being measured

[00:20:14] by not by the technical debt so you are acting in your own best interests and you’re

[00:20:21] acting actually as the company is pointing you with its its incentives and its rewards and its

[00:20:28] punishments there so you are you are doing what is appropriate for that role there so you need to

[00:20:34] understand how decisions in systems are made so you really need to understand systems thinking as

[00:20:41] well for two two reasons the first is that these decisions in a system will be made differently

[00:20:47] from individuals but secondly you need to also

[00:20:51] understand how things work when you have them in a system there and how for example

[00:20:57] by piling up technical debt you can get a runaway effect there of suddenly too much technical debt

[00:21:04] causes the development to really slow down from which you cannot recover so you really need to

[00:21:10] understand these systems as well and then what i realized from there was actually if you’re talking

[00:21:16] about individuals making decisions within a system

[00:21:21] essentially that’s economics that’s what economics is and so then i looked at well

[00:21:27] what can economists teach us and economists have been looking at problems similar to this

[00:21:33] for hundreds of years so they’ve got a whole series of problems that they have highlighted

[00:21:39] and addressed and the really good thing about looking at it from the economist point of view

[00:21:45] is that firstly that they they’ve studied it already so you don’t need to reinvent the wheel

[00:21:51] but secondly they are talking the language of business very often so very often we find it

[00:21:57] difficult to engage with the business and we may talk about technical debt and we may talk about

[00:22:01] these risks and this that but all the business people here is yeah yeah yeah and it doesn’t

[00:22:06] really go in whereas if you start talking about externalities or the principal agent problem there

[00:22:13] it’s likely that it’s something that they met at business school and so stradio you are talking

[00:22:19] their language so you’re talking about the language of business and you’re talking about

[00:22:21] that’s an advantage of this looking at the economics layer and then underneath that i put

[00:22:27] a final layer which was around wicked problems and so really technical debt in fact all every

[00:22:35] practically everything that we do in software development is a wicked problem and so i talk

[00:22:41] about wicked problems and tame problems and so a tame problem is it’s a problem like chess

[00:22:47] or a game of some sort that has some rules

[00:22:51] and there is a single solution or there’s a solution which everyone will agree is better

[00:22:56] than another solution there whereas in a wicked problem it’s got several characteristics

[00:23:02] one of which is that different people may have different opinions about what is the best solution

[00:23:09] there so for example on that other road i live on perhaps there’s a bit of noise and my best

[00:23:16] solution is that there’s no noise at night whereas for the young people that are coming back from the

[00:23:20] pub they’re not going to have any noise at night so they’re going to have no noise at night so

[00:23:21] there’s a better solution which is that there’s a bit of noise as they come back from the pub and

[00:23:25] but it’s all quiet by three o’clock and so you can see that’s one thing that you could have there is

[00:23:30] that there’s different people may have different opinions about what the solution is but another

[00:23:34] thing as well which is very highly relevant for software development more so than any most other

[00:23:41] types of engineering problems is that a wicked problem very often you will not know the um you

[00:23:47] will not know the solution until you find the solution and so that’s one of the things that’s

[00:23:51] so you won’t understand the problem until you develop the solution and very often for us

[00:23:56] we don’t know what the software is going to be because it’s part of the exploration

[00:24:00] we think we’re building one thing and it ends up we tell people we’re building something else

[00:24:06] and in the end it ends up as something entirely different whereas if you looked at say civil

[00:24:12] engineering say constructing a bridge you’re pretty sure what you’re going to end up with

[00:24:17] before you even start but that’s not true in software development

[00:24:21] so very often we we don’t understand the problem until we got to a solution so that

[00:24:25] that’s sort of a part of this wicked wickedness of the world that we live in there

[00:24:30] oh thanks for kind of like walk through of all the layers just to recap right so you have kind

[00:24:35] of like five layers it’s kind of like an onion model right layers by layers the inside maybe

[00:24:40] the core maybe it’s technical layer and then you have the trade-off layer you have the systems layer

[00:24:45] kind of like the systems thinking aspect that you mentioned then you have the economics of game

[00:24:51] and the last one is the wicked problems layer so maybe let’s try to peel it slightly um smaller

[00:24:57] layer right so maybe i won’t go deep into technical layer because i think for software engineers it’s

[00:25:02] kind of like assume we know what kind of technical problems maybe design skill you know a lack of

[00:25:07] tests and all that we’ll just skip it all together but let’s go to the trade-off layer because i

[00:25:12] think this is quite important as an individual right whenever we make decisions we sometimes

[00:25:16] make a lot of trade-off either knowingly or unknowingly

[00:25:21] interesting aspects of the trade-off layer that you want to remind us or you want to

[00:25:25] kind of like advise us today so essentially so the trade-off layer when you’re making trade-offs

[00:25:32] it’s important to fully understand how you make trade-offs which i i said is we use our emotions

[00:25:39] and although we might talk about logic and rationality most of the time the rationality

[00:25:48] comes in afterwards and we just use it to justify the

[00:25:51] decision that we’ve made and so you’ve really got to understand what it is how you make decisions

[00:25:58] using emotions and essentially use something called the effect heuristic which is it’s like

[00:26:07] you’re a sort of it’s like you’re an emotional sort of a gauge there and what that does is

[00:26:15] it guides you in the decisions that you make and there’s several important things to

[00:26:21] realize one of which is that this process is entirely subconscious so you don’t understand

[00:26:29] why you make these um decisions although you will be able to justify it you’ll be able to

[00:26:36] give a good reason but that reason will be uh somewhat spurious and so they’ve done quite a

[00:26:42] lot of experiments on people making decisions or having preferences so one of which was um

[00:26:48] they took some i would call them

[00:26:51] strategy characters but that’s because i’m coming from a japanese background there but

[00:26:55] it would be the chinese characters and they would flash this cut they’d have this chinese

[00:26:59] character up on the screen this is to western people who don’t you cannot read the chinese

[00:27:05] characters and they would ask them to make a preference which one do you prefer now what

[00:27:10] they didn’t know was that although they were looking at a screen there it was a special

[00:27:15] screen and it had a very fast refresh rate and so what they were doing was they were

[00:27:20] putting up

[00:27:21] onto the screen every so often they were putting up a picture of a happy face or an angry face

[00:27:26] and what people did was they had a preference for this character and they would they would

[00:27:32] give a reason why because it was a you know it had smooth curves or it did this or do that

[00:27:38] but what she was was that behind there flickering too fast for them to see there was a happy face

[00:27:43] and they didn’t like the other one because it had an angry face but they never realized this

[00:27:49] because it was it was so fast and they didn’t like the other one because it had an angry face

[00:27:51] and they didn’t like the other one because it was so fast so our emotions or our decision

[00:27:53] making it happens so fast that it’s outside of our consciousness which makes it very difficult

[00:27:59] then to control really but we do need to be able to control it and and we can control

[00:28:04] it and an example here would be so there’s a there’s an analogy which is quite close

[00:28:10] to technical debt so technical debt it’s you’re trading off between a feature and taking

[00:28:17] the debt on so the characteristics of the t the feature are

[00:28:21] it’s going to be immediate you’re going to get the feature as soon as it’s it’s coded

[00:28:24] it’s going to be concrete you get the feature or you don’t

[00:28:28] so it’s going to be those things there immediate is going to be

[00:28:31] concrete there whereas if you look at the technical debt it’s you know potentially you’ll

[00:28:36] have to be pay some debt in the future but you don’t know when you don’t know how much you don’t

[00:28:43] even know what what it’s going to be in there it’s very indefinite it’s very abstract there

[00:28:50] and so you can see that something that’s concrete and immediate is going to appeal to your emotions

[00:28:54] something that is in the future and in definite and in abstract it’s going to appeal to your

[00:29:01] logic but not your emotions and so that’s that’s principally why the technical debt does badly

[00:29:07] and then a useful analogy is to smoking so in smoking most of our governments they realized

[00:29:15] several many decades ago that smoking is bad for the population so they wanted to stop it

[00:29:20] and so one of the things they did was they decided to put health warnings on the cigarette packets

[00:29:25] and the tobacco manufacturers they fiercely resisted this and they fought it through the

[00:29:30] cause but eventually they had to put the warnings on there but they didn’t need to worry because

[00:29:35] what happened was if you look and you read that warning it appeals to your logic it’s talking

[00:29:40] about a potential future hazard to your health which may or may not happen

[00:29:45] you

[00:29:45] in the future and that appeals to your logic whereas if you looked at the cigarette packets

[00:29:50] you had packets of pictures of sexy cowboys and things like that so as a teenager that was

[00:29:57] appealing to your emotions and so they put these warnings on that and it had very little effect

[00:30:02] whereas if you look now at in certainly in our country i’m not sure about yours you cannot get

[00:30:08] packets of cigarette like that they’re all plain branded so the manufacturers cannot affect your

[00:30:15] emotions

[00:30:15] but what they’ve done in our country is they’ve put horrific photographs of damaged body parts

[00:30:22] damaged by smoking which of course appeals very strongly to your emotions there

[00:30:27] and so now it’s been switched over that the health authorities they are controlling the message

[00:30:33] through the emotions and it’s not the only reason but it’s part of the reason that smoking rates have

[00:30:39] gone down in many countries there so that’s like a clue of what you need to be doing with

[00:30:45] technical debt if you’ve got too much or you want to change the the level of that technical debt

[00:30:51] you need to make arguments that are appealing to people’s emotions not to their logic i talk a bit

[00:30:58] about this in the book where i say there’s several ways you can do it so so one is you can sort of

[00:31:02] paint a picture you can tell a story and you could put together a scenario of you wanted to do some

[00:31:09] development but you’ll prevent you from doing so by this technical debt there so that’d be one thing

[00:31:15] there there’s other things as well you can do to affect the way that you make decisions so one is

[00:31:21] something called a ulysses contract and a ulysses contract that’s where you commit to something

[00:31:28] that you cannot later reverse that commitment they use quite a lot in um they’re like living

[00:31:35] wills so if you come to the end of your life and you’re losing your faculties you can put in this

[00:31:42] contract so that at a certain

[00:31:44] stage you won’t be able to reverse those decisions there and somebody else will be making those

[00:31:50] decisions so you can put in a ulysses contract for say technical debt where a project agrees to

[00:31:58] take on this technical debt but if they do that then they have to apportion part of the project

[00:32:05] funding to addressing that debt at a later stage so there’s a few things that you can do like that

[00:32:13] yeah yeah so i think it’s very um interesting the way you explain about this kind of a trade-off

[00:32:19] analysis right because sometimes we think it’s very kind of like simplistic mindset right like

[00:32:24] we think oh we take this debt simply because we want to go faster but sometimes it’s it’s

[00:32:28] more beyond that right so you mentioned about emotions right it could be maybe also that day

[00:32:33] when you make the decision you’re kind of like not in a good mood and sometimes you take a shortcut

[00:32:38] simply because i don’t know like you just want to finish things faster could also be

[00:32:43] the trade-off that we mentioned in the very beginning right with business right business

[00:32:46] always wants you know things to get delivered faster many features project deadline that gets

[00:32:51] set without you know being asked from the engineers right so those kind of things definitely

[00:32:56] make trade-offs um kind of like more complex than what we think about when we take technical debt

[00:33:02] and another thing you also mentioned about kind of a few solutions right that we can do

[00:33:07] maybe painting the pictures uh trying to kind of like put the kind of like the story if

[00:33:13] let’s say we take too much technical debt what would happen maybe in the business terms could

[00:33:16] be we couldn’t scale beyond x number of users or we couldn’t process transactions you know beyond

[00:33:23] whatever number of rps and things like that and ulysses contract i think is very interesting i’m

[00:33:29] not sure like how many people have that in their day-to-day team uh kind of like contract right

[00:33:34] so maybe in not so many yeah in your life experience have you seen this ulysses contract

[00:33:39] kind of like implemented i’ve advocated for it

[00:33:43] but at the organizations where i’ve advocated and put it forwards it hasn’t been taken on there

[00:33:50] but yeah so i think yeah i think like most of the time when i’ve been advocating i’ve probably been

[00:33:58] a bit too late we’ve already starting to hit crisis point at which point it really doesn’t

[00:34:03] matter what you suggest it’s it’s just gonna have to try and get out the door and worry about

[00:34:08] everything later yeah so maybe one one implementation or

[00:34:13] contract that i can think some teams actually implement so maybe it’s for example three sprints

[00:34:18] of you know business technical features more and then you spend one sprint just to focus on

[00:34:23] technical improvements technical debt that could be a simple contract that any teams i believe could

[00:34:27] actually implement in their day-to-day yes that that yep that’s a way of looking at a ulysses

[00:34:33] contract but in some ways you’d need to be a little you’d also could be a bit more granular

[00:34:38] in that if you get two solutions right we can and i can think here of

[00:34:43] when i used to work at hmv there we had a particular problem in that we want to display

[00:34:49] a product in two places at the same time which is understandable and basically in order to do that

[00:34:56] to do it properly was a big big rewrite of the database and we couldn’t possibly do it before

[00:35:03] christmas and christmas was really important for hmv because about a quarter of all of their

[00:35:08] fails are just at christmas time so you’re never allowed to do anything

[00:35:13] that messes up christmas for hmv and so what we worked out was there was a quick and dirty

[00:35:20] solution which was we could create a duplicate of the database so you could put this product in two

[00:35:25] places at once but then you have a lot of maintenance so anything that needed to be

[00:35:30] updated or you had any feeds in it all had to be duplicated the company the business agreed yes

[00:35:37] we’ll do the quick and dirty we get it in before christmas and the first project that we will do

[00:35:41] after christmas

[00:35:43] is we will undo this and we’ll do it properly i’d like to say that’s what happened but it isn’t

[00:35:49] the first project is when we came to it actually we realized that so many code fixes had gone in

[00:35:55] during the christmas period there that all of a sudden it was much much more difficult to actually

[00:36:01] go back and redo it properly so they decided not to do it and they were doing any future project

[00:36:07] and they kept on putting it back until eventually i left the company and they did all got it had all

[00:36:12] gone on yeah

[00:36:13] right yeah i was about to say sometimes yeah we we got this i don’t know like promise right in the

[00:36:19] very beginning yeah we will let you do you know like repay your technical debt and all that but

[00:36:23] sometimes because of whatever business situations we may never get it fully repaid after all right

[00:36:29] thanks for sharing that personal story so let’s move on to the next layer which is uh you call

[00:36:35] this systems layer so you kind of like associate this with systems thinking a little bit so what

[00:36:40] interesting thing that you want to share about systems thinking is that you have a lot of

[00:36:43] thinking or maybe systems layer that could actually affect technical debt i would say so

[00:36:48] yeah i mean so in terms of systems in software development and it we’re actually starting from

[00:36:55] an advantage because we already have a fairly good understanding of systems because practically

[00:37:01] every project that we work on is within a system and if we’re putting in a big project say like an

[00:37:07] erp system or something that’s really big almost certainly there’ll be one or several

[00:37:13] people looking at the problem and looking at it from a systems point of view so we’ve got that

[00:37:19] understanding there of systems so we have an intuitive or it’s more than the intuitive we

[00:37:25] have a specific and a concrete understanding of systems but really that’s it systems and that’s

[00:37:33] like physical systems there as well as the physical system which is important there’s also

[00:37:40] the social system that we’re working with the system that we’re working with the system that

[00:37:43] we’re working within and that’s where these decisions are made and so what you’ll see an

[00:37:49] important thing about social systems or living systems not just social systems is that different

[00:37:57] parts of the subsystem they can develop their own sub goals and they can pursue their own sub goals

[00:38:04] which may be in conflict with the goals of the whole organization there and that’s something you

[00:38:10] don’t normally get that in physical systems

[00:38:13] because the designers will have you won’t get in a well-designed physical system and mostly you

[00:38:19] won’t get it because it’s been thought about whereas when we’re putting in or we’re working

[00:38:26] in software development the testers they can have their goals the software developments they may

[00:38:32] have their goals and of course business will have very different goals there and they can be clashing

[00:38:36] there and so this can lead to unexpected developments there and so

[00:38:43] i mean that one of the the most famous ones is you’ve probably heard of prohibition in the united

[00:38:48] states the banning of alcohol was about the about 100 back it was about 100 years ago beginning of

[00:38:55] the 19th 20th century a lot of countries had a lot of problems around increasing rates of alcohol

[00:39:02] consumption there’s various reasons for that people were getting a lot more money they’re

[00:39:06] working in factories they were getting better paid and they’re going out and drinking that’s

[00:39:10] but this was causing lots and lots of

[00:39:13] social problems and so different governments tried to deal with it in different ways

[00:39:18] and the united states they decided they were going to use prohibition which was just ban all alcohol

[00:39:24] but what they hadn’t realized was that or they hadn’t considered the system inside which the

[00:39:30] alcohol is sold and consumed there and so they banned alcohol and so all the bars closed down

[00:39:37] all those breweries distilleries they all closed down everything everything like that

[00:39:43] but you still had people that they used to be drinking and they want to continue drinking

[00:39:48] and so anybody who’s done economics economics 101 is going to tell you if you have a demand for

[00:39:55] something you suddenly cut off the supply there’s going to be a substitute supply from somewhere

[00:40:01] and this substitute supply came from criminal organizations it actually came from criminals

[00:40:08] who actually then became organized because they weren’t particularly well organized and they were

[00:40:13] organized before that so then this led to lots and lots of problems in prohibition so you know

[00:40:19] a rising crime a lot of violence you had enormous wealth being generated for these criminals

[00:40:24] who then they would then use it to bribe the police bribe the courts a whole series of things

[00:40:30] like this and they built up these very very strong organizations there and so one of the

[00:40:37] the longest lasting effect of prohibition in the united states was something that was

[00:40:43] highly unexpected or unanticipated and highly undesirable which was the growth of organized crime

[00:40:48] in the united states in our country we tackled it in a different way we didn’t get those

[00:40:53] gangs building up because of that well quite fascinating story right so i think many of us

[00:40:59] could relate with this kind of like social system aspect especially if we work in a bigger

[00:41:04] organization right so things could be also like political reasons hierarchies right or silo teams

[00:41:11] that work you know quite independently

[00:41:13] without talking to each other it could be so many other things like incentive system reward system

[00:41:18] punishment system right so those kind of things maybe from one small perspective point of view

[00:41:24] it seems could solve a particular problem right but unconsciously you can create unprecedented

[00:41:30] effect in some other parts of the system right so i think this is where systems thinking kind

[00:41:35] of a mindset is very very important especially for us who are working in software engineering

[00:41:39] so never kind of like focus or invest too much on why we’re doing this kind of thing right so i think

[00:41:43] one particular solution but thinking holistically how it could affect the other parts of the systems

[00:41:48] as well i think is very important so yeah let’s move on yeah to the next layer like economics

[00:41:54] game theory you mentioned about using this model so that we can communicate with the business much

[00:41:59] better maybe some of examples of economics or system or game theory layer here that you could

[00:42:06] advocate for us to use next time we talk to our stakeholders i would say in it right in terms of

[00:42:13] something we could be doing we have two solutions one is just to create a model where there’s very

[00:42:20] far more complex idea if i were to say that there’s there’s lots of very fascinating things in there

[00:42:25] and it’s very tempting and very easy to to to become completely embroiled in it and and and

[00:42:31] and look at some fascinating aspect of it but i’d say perhaps the two if there were if i was to choose

[00:42:37] two things it would be firstly you don’t need to communicate this to the bosses but actually it

[00:42:42] wouldn’t hurt to communicate it but it’s the principle agent problem which is that it’s a problem

[00:42:42] where an employee is able to use the technology to do both things so i think one of the things that’s

[00:42:43] the issue is you have to change that program and there’s lots of potential answers to get them to do something

[00:42:43] there so really it’s a practical question is whether you’re going to change that program and it’s a practical question

[00:42:43] where basically the principal so that the boss or whoever has the money you are paying or rewarding

[00:42:50] somebody else to do something of your bidding there and that’s essentially when we’re working

[00:42:56] in the company we are the agents and then the organization itself is the principal and so if

[00:43:03] you look at the principal agent problem what you will have is that they may have different goals

[00:43:08] and they may have different motivations there and so what you should always be aware of and

[00:43:15] thinking about is how do their goals line up and you’re going to be most successful if the principal

[00:43:21] and the agent’s goals line up or coincide there if and you should also understand that you will

[00:43:29] be unsuccessful to the extent that those goals don’t line up there and of course it’s not just

[00:43:35] the employees but you’ve got an added complication

[00:43:38] in most organizations in that they will often they will bring in external help to manage large

[00:43:45] projects and what you have to realize is that perhaps the goals of those outside organizations

[00:43:51] the consultancies may not be very well aligned with the organization that they’re working for

[00:43:59] and certainly i’ve been on a lot of projects i imagine you have as well and you will have seen

[00:44:05] some of the antics and the activities

[00:44:08] that some of these consultants will get up to which are not necessarily helpful for the the

[00:44:14] client there and here i’m thinking of things like perhaps rivalry between organizations there

[00:44:19] another one might be that actually one of the things that perhaps some of the less ethical

[00:44:26] consultancies might do is as soon as they go in is to try and remove all of the capability

[00:44:32] of the organization so that the organization is now dependent upon the consultancy so the

[00:44:38] company is now dependent upon the consultancy so that the organization is now dependent upon the consultancy

[00:44:39] so there’s this principal agent problem there which i think people should be aware of there

[00:44:45] that’s going to play out in the technical debt there of that the company may want lower low

[00:44:51] levels of technical debt but the principal if the principal is the is the project manager who is going

[00:44:58] to be perhaps moving to a different organization at the end of the project and their goal is to

[00:45:03] get the project in or appear in and it doesn’t matter to them how much technical debt there is

[00:45:08] you’ve got to be aware of that and that’s going to play out in the technical debt there of that

[00:45:08] that principal agent problem there so i say there’s the principal agent problem that is there

[00:45:14] and a second thing that i think that i would also highlight to the business because they

[00:45:20] won’t be so aware of this is the problem of externalities so an externality is basically

[00:45:29] it’s where one party can impose a cost or a benefit but usually it’s a cost you don’t worry

[00:45:37] about benefits they can impose a cost or a benefit and they can impose a cost or a benefit

[00:45:38] on another party and the other party has no say whatever in in whether they accept that cost or not

[00:45:49] and the most commonly cited example is pollution if you drive your car into the city

[00:45:57] and you’re there perhaps to pick up your wife and she’s out shopping and so you sat on the side of

[00:46:04] the road there waiting for her to come out of the shop there and you had your engine idling

[00:46:08] what you’re creating all this externalities in terms of the pollution that you’re creating

[00:46:13] but you’re sitting in your car and you are not suffering that externality it’s others that are

[00:46:19] suffering it there and that’s very much what happens on projects there where projects may

[00:46:26] be making decisions around how much technical debt they are piling up but they’re not necessarily

[00:46:34] going to be the ones that pay off that debt perhaps it’s going to be the support team

[00:46:38] i mean this was brought home to me once when i was at um not once many many times

[00:46:44] irritating me many times when i worked at hmv and we had a project manager there and whenever he

[00:46:51] caused a problem that affected a problem that affected another project or support he would just

[00:46:57] turn around and someone said all right what you’ve done now has done this and there he would turn

[00:47:02] around he would say that’s not my problem and so he was just saying effectively he was saying

[00:47:08] i am putting an externality on you and the structure of our organization is i don’t care

[00:47:13] whether i do that or not and the company doesn’t care and i’m getting away with it and technical

[00:47:18] debt is very much very often it’s an externality because the people that are making the decisions

[00:47:24] about it very often are not the ones that are going to end up paying that back at the end there

[00:47:29] so those are the two things that i think that i would take from economics to technical debt

[00:47:35] principal agent and externalities

[00:47:38] well i think now that you’re kind of like explaining and giving examples i’m sure some of

[00:47:43] us kind of like laughing you know hearing those examples because we could actually realize it’s

[00:47:48] happening to all of us in our career right so i think definitely this kind of principal agent

[00:47:53] problem right externalities where someone makes decision without actually taking the responsibilities

[00:47:58] later on it’s kind of like quite common especially in software projects where you kind of like

[00:48:02] engage consultants third parties on project basis rather than product basis right so i think we can

[00:48:08] see it in real life and let’s go to the next one which is the wicked problem you kind of like

[00:48:12] touch on a little bit earlier right in that wicked problem is something that maybe you don’t even know

[00:48:17] in the very beginning what could the solution look like you can always explore experiment until the

[00:48:21] solution actually comes out this is so much evident in software right because we’ll iterate

[00:48:26] right so we’ll come up with a very simplistic design that could maybe solve the problem the

[00:48:32] features show it to people people ask for more and we continue evolve it until it gets to a

[00:48:37] different kind of solution

[00:48:38] altogether so why do you think wicked problem is kind of like the outer layer which i assume is

[00:48:43] going to be the most complex thing to consider so what kind of insightful thing can you share

[00:48:49] with us today about wicked problem the wicked problem i would say that the there’s multiple

[00:48:55] parts to the wicked problem as you are you’re saying there’s a one characteristic of a wicked

[00:49:01] problem is that you don’t know what the problem is until you actually have a solution other things

[00:49:08] that you can do right or wrong there’s just better or worse but perhaps the really critical thing

[00:49:14] for us is that different parties will have different beliefs about what the problem is

[00:49:21] and what the better solution is so we may think something from a technical side there that what

[00:49:30] this is the best solution but from a business point of view they may be thinking something

[00:49:35] very different there and it’s how we’re going to solve the problem and how we’re going to solve the

[00:49:38] problem and how you resolve those things or attempt to resolve them or accommodate them there

[00:49:42] that’s something which i think most of us will find very difficult particularly within software

[00:49:49] development because we tend to be very technical people and we tend not to think of things in terms

[00:49:57] of political political sort of landscape and how we need to accommodate different things there

[00:50:04] and really the people that perhaps

[00:50:08] are best equipped to deal and understand those that political landscape and so on they’re all

[00:50:15] sitting in the business there it’s almost as if we need to get them or someone from that side to

[00:50:22] come over and advocate for ourselves there otherwise the risk is that we we end up in

[00:50:29] just like a standoff there of the technical people saying this technical debt is bad and we have too

[00:50:38] much money to pay for it and the market is saying yeah but we we’re getting the market is being

[00:50:41] dominated by somebody else we need to get a bigger market share which means we need more features we

[00:50:47] need more this or more that and once we’ve got a bigger market share we can sort out all these other

[00:50:52] things later it’s almost as if you’re having this argument but you’re arguing in two different

[00:50:58] languages there and i think that’s a tremendously difficult and wasteful thing to do there and i

[00:51:06] think that it’s not just for technical

[00:51:08] issues but it’s also for technical issues and i think that’s a tremendously difficult and wasteful thing to do there and i think that it’s not just for technical

[00:51:08] debt i think there’s a whole series of soft things around here or we have a whole lot of problems in

[00:51:15] software development which are wicked problems there and i think we should and we should perhaps

[00:51:19] try and understand better about wicked problems and what we can indeed do about them there

[00:51:25] i think uh after you explain it i’m sure um you know people can relate right what do you mean by

[00:51:32] wicked problem in software engineering and why you put it at the outer layer simply because yeah

[00:51:36] it’s very difficult um sometimes you could wear multiple hats only then you could see

[00:51:40] where things are kind of like not aligning you know things are always miscommunicated misunderstood

[00:51:45] and sometimes yeah like you mentioned people don’t have the same definition of problem

[00:51:50] doesn’t have the same definition of solution right or maybe we don’t know the solution in

[00:51:54] the very beginning uh only until you know we reach a certain point so definitely software

[00:51:59] engineering i find it’s a lot of wicked problem kind of a thing and we can see from all these

[00:52:04] layers that you just explained right

[00:52:06] technical aspect is just a small part of the technical debt and there are so many other

[00:52:10] things like organizational system the bias thinking the emotion social structure and

[00:52:15] things like that how would you advise software engineering team or organization to start

[00:52:20] managing their technical debt better or at least introduce technical debt in a more healthy manner

[00:52:25] rather than you know like trying to burn as many technical debt as possible and then try to repay

[00:52:31] in the end which will not happen and in the end you know it caused a lot of problems a lot of

[00:52:35] damage in some way

[00:52:36] of the stories you share in the book so maybe how can an organization start managing their technical

[00:52:40] debt better i’d say almost certainly if you’re managing technical if you’re coming at it from

[00:52:47] the viewpoint of we’ve got this managed this technical debt we need to manage it or burn it

[00:52:51] down you’re almost starting too late really it’s what you really need to be doing is avoiding

[00:52:58] creating the technical debt that you can avoid creating there and so i think that really

[00:53:06] there is it’s almost like an analogy would be doing a development at a at a sustainable pace there

[00:53:15] you can’t do development really really fast and then when you become completely tired and knackered

[00:53:22] now we will slow down to a sustainable rate it’s a bit too late no so it’s getting people into the

[00:53:30] mindset that they are making these trade-offs and these trade-offs will be there for an awful long

[00:53:36] time and getting them to make better trade-offs there now there’s always going to be technical

[00:53:42] debt and they need to you need to get this tech you need to take on this technical debt if you

[00:53:47] didn’t you couldn’t get the products out there in time you’d be too late in the marketplace

[00:53:52] but you don’t need to take on all the technical debt that you’re taking on and some of it would

[00:53:58] be unnecessary there and in particular i would say it’s things such as when you’re trading off

[00:54:05] technical debt you’re not going to be able to make better trade-offs there and you’re not going to

[00:54:06] be able to make better trade-offs there and you’re not going to be able to make better trade-offs there

[00:54:06] for additional features there you really need someone to push back on do we really need these

[00:54:12] features because it’s very easy for the business and the marketing to say this is absolutely

[00:54:19] essential this feature we must have it in and no one can prove otherwise and so it’s just because

[00:54:26] it’s so easy it’s so tempting to do that again and again and again until you end up with this

[00:54:30] very bloated product with lots of lots of debt in it

[00:54:36] it’s kind of starting it at the beginning there and one of the things i talked about in my book

[00:54:40] in the last third of the book there is really how you can address the technical debt but it’s

[00:54:46] addressing the technical debt from the mindset of avoiding creating it in the start there rather

[00:54:53] than getting rid and burning down this technical debt in fact that’s a very bad thing to do in many

[00:54:58] ways because once you do that it’s almost as if you’ve given the business permission to create

[00:55:05] this technical debt and you’re not going to be able to make better trade-offs there and so it’s

[00:55:06] really important to do that because you can just pay it down later trying to get them into this

[00:55:10] mindset of avoiding this technical debt and the costs of this technical debt there and why

[00:55:17] and how they can avoid it or minimize the amount of technical debt there yeah well i think that’s

[00:55:25] a very good uh reminder right so whenever we talk about managing technical debt probably it’s a bit

[00:55:30] too late right so i think avoiding it prevention is always the best cure right rather than you

[00:55:36] know just doing business as medicine or adding people buying software whatever that is right to

[00:55:39] actually kind of like solve the technical debt problem and i think you mentioned a very good

[00:55:43] keyword that i think we all need to always reflect right sustainable pace over a long term right

[00:55:49] so the moment you feel like kind of like the velocity is slowing down the team cannot deliver

[00:55:54] things as smooth as before right maybe that’s uh kind of like also a signal for for us to kind of

[00:55:59] think about how we can tackle or manage our technical debt better and communicate that to the

[00:56:03] business stakeholders right and in your book you have a lot of examples of how you can do that right

[00:56:05] and in your book you also mentioned a few common anti-patterns i think people who would love to

[00:56:11] kind of like advocate or champion you know managing technical debt better in an organization you should

[00:56:15] check out andrew’s book so it will be a miss if i didn’t you know mention or discuss about ai with

[00:56:21] technical debt right i think with the advent of ai we can certainly see there are many aspects of

[00:56:27] technical debt that could be i don’t know kind of like remodeled right so the first aspect is like

[00:56:35] say it could create a lot of technical debt right or maybe also and some other people say oh we have

[00:56:41] a very high technical debt system now with ai we can use it to actually solve technical debt

[00:56:46] maybe simply because i don’t know at least documenting the feature because the people

[00:56:50] have left or things like that or creating tests automatically so what do you view about ai is it

[00:56:57] something that is going to increase technical debt or is it going to be reducing technical debt

[00:57:01] i think that the most prominent that and

[00:57:05] the most salient visible part is the big increase which is going to come from non-technical people

[00:57:12] doing vibe code development there and creating enormous amounts of technical debt there

[00:57:19] so i can see that being a huge a huge thing there but i could also see that it may be that

[00:57:27] certain types of technical debt may become less important particularly if you’re able to

[00:57:34] create a lot of technical debt which is going to come from non-technical people doing vibe code

[00:57:35] these coding in this solution so much more easily it may well be that the debt is less important

[00:57:41] perhaps but i would say certainly it’s the ai and vibe coding does give you a a very strong feeling

[00:57:50] that this is something that could create enormous amounts of technical debt and particularly since

[00:57:56] i imagine vibe coding being written and if something is useful and it’s taking off it’s

[00:58:03] probably not going to get rewritten it’s let’s build on top of that there in which case yeah

[00:58:08] you’re you’re building on something that’s uh probably got a lot of debt or a lot of limitations

[00:58:13] in it yeah yeah so there’s this danger obviously about vibe coding or you just blindly accept

[00:58:18] whatever ai suggests right i think i i want to touch on also like the emotion aspect right

[00:58:23] whenever we use ai sometimes we feel very confident and it’s very easy right we could

[00:58:27] just churn out code after code after code building features on top of features sometimes there’s i

[00:58:31] think there’s a dopamine hit as well

[00:58:33] whenever you build such thing rapidly and you could see results you almost see the results

[00:58:38] you kind of like polish it more and more but unconsciously you introduce a lot more technical

[00:58:42] debt do you have like real case experience or examples where people use ai effectively

[00:58:48] like cautiously also not to take on more debt but also kind of like build a system that can

[00:58:53] also last like much much longer well okay so i’ve spoken to people that have been using ai

[00:59:00] and what if

[00:59:03] of course what they’re telling you may not be exactly the same as what they’re doing of course

[00:59:08] but what they were saying was that they were using it quite a lot for investigation and research

[00:59:15] there and if they wanted to find out something they were perhaps posing a question to an ai or

[00:59:23] an llm model there they were getting the answer back they were looking at it they were then

[00:59:30] refining their question

[00:59:33] firing it back again and going through a cycle then multiple times but then often at the end

[00:59:40] they were manually coding they were doing it there so they were doing it for this research there

[00:59:45] that at least that’s all that’s what they were telling me of course what people tell you isn’t

[00:59:50] always the same there and perhaps there’d be a reluctance to say yeah i just let ai do all of the

[00:59:55] the stuff for me there i guess we will see the results will come through i think yeah and we’ll

[01:00:03] be back with a new video next week and i’ll see you then bye bye

[01:00:03] be seeing those shortly i think right so i’m pretty sure uh one day we can because now everything

[01:00:09] is moving everything is changing uh and ai technology itself is being kind of like reinvented

[01:00:14] you know every week every month you know maybe there’s a new model coming new techniques coming

[01:00:18] out agentic thing now is also kind of like the craze thing and i’m sure ai will pop up in your

[01:00:24] layers i would assume it will be in the trade-off layer and some sometimes also in the weaker

[01:00:28] problem right so i think definitely it’s going to be fascinating this uh ai

[01:00:33] trend going in the software development world so andrew as we reach the end of our conversation

[01:00:38] thank you so much for outlining about this technical debt i find it very fascinating for

[01:00:42] us educating also for us like how we can make technical debt trade-off better before i let you

[01:00:48] go i have one last question it’s like a tradition in my podcast which is to ask this question called

[01:00:52] the three technical leadership wisdom so if you can think of it just like three advice you want

[01:00:56] to give to the listeners maybe if you can share your version today that would be great yeah sure

[01:01:01] so well i would say um

[01:01:03] that basically read more deeply okay if you think about where you’re spending your time

[01:01:10] quite a lot of your time it might be you’re just reading something on linkedin or perhaps

[01:01:15] watching something on youtube there are some really wonderful things that have been written

[01:01:21] out there and here i’m thinking of published books okay something that is published and

[01:01:28] something that is a book someone has spent a lot of

[01:01:33] time thinking about that doing that they will have put in hundreds or thousands of hours

[01:01:40] to produce that so there’s hundreds or thousands of hours that have gone into that thought

[01:01:45] and you can get that thought for an investment of just uh you know 10 20 hours or something

[01:01:51] reading through it there that’s not always going to be true though if it’s say a blog article

[01:01:57] there it won’t have been through all of that process there but if it’s being published

[01:02:01] and it’s being published by a book it’s going to be published by a book it’s going to be published by a book

[01:02:03] it’s going to be published by a publisher that has got they need to make money and in order to make

[01:02:07] money they need to do something that’s good enough quality that people will read it there and there’s

[01:02:12] a lot of stuff out there and here i was thinking about um you know one of your more recent guests

[01:02:19] was carl vegas with his programming pearls and it’s like just what a wonderful book there you

[01:02:24] know with all of these lots of good ideas there and you know similar there’s one with um it’s

[01:02:30] lessons learned in software testing lots of good ideas there and you know similar there’s one with

[01:02:33] some lots of really great ideas in there i think developers we probably read perhaps two books a

[01:02:41] year or something two technical books a year if that we could we really should be reading an awful

[01:02:46] lot more that’d be the first thing reading in our own subjects but then i would also say you should

[01:02:52] also you should read more widely and here i’m taking a uh sort of a a hint from something

[01:02:58] called red teams here which is where you should read outside of your experience

[01:03:03] so i mean i do a lot of a lot of work and a lot of research into the human factors but

[01:03:09] the human factors that had not you know i had nothing at all to do with it until i started

[01:03:15] thinking about why have we got all these problems in software development that have been around for

[01:03:19] decades that we haven’t and so i started looking around but where else have they had similar things

[01:03:23] so you know i’ve looked at that and i’ve looked at systems and systems thinking and dynamics

[01:03:29] so you should brought out your um your

[01:03:33] ideas and read more widely and particularly you should also read things that you don’t necessarily

[01:03:38] agree with you should expose yourself to different points of view now this means though this comes to

[01:03:44] the third bit here you need to set some time you need to allocate time to do this so put a slice

[01:03:51] into your calendar there maybe it’s going to be a morning or something every fortnight just for

[01:03:57] reading and nothing else well i think uh that’s a very again very good timely reminder

[01:04:03] for some of us who you know because these days social media or maybe short blog posts are so much

[01:04:09] easy to access and sometimes we get notified as well i find sometimes like all these creates

[01:04:14] fatigue as well right so you have so many content thrown out to you so we kind of like spend maybe

[01:04:19] short time reading it we forget a lot of things i think you your advice is very good timely reminder

[01:04:25] right read more deeply read more widely as well and set the time to actually do those two things

[01:04:30] right i think for software engineers yeah i i

[01:04:33] also think myself don’t read enough especially those technical books that could be very thick

[01:04:37] and sometimes very dry yes entertainment yeah yeah that is true yeah yeah but i think it’s

[01:04:46] very important especially if we want to keep ourselves up to date re-skilling again like

[01:04:50] coming back to the first thing that we discussed in our conversation so andrew if people love this

[01:04:56] conversation they want to reach out to you ask you more questions maybe about technical debt or

[01:05:00] social behavioral aspects which i know that you’re passionate about

[01:05:03] as well is there a place where they can find you online there’s linkedin you can probably find me

[01:05:08] there andrew brown at linkedin or i’m on youtube as well or you can find me an email which is we

[01:05:17] can perhaps put it in your uh session there it’s brown brown sensei is the email to get me out brown

[01:05:23] sensei at hotmail i i took brown sensei when i was working in japan actually at the time

[01:05:29] yeah and yeah i’d love to hear from people right

[01:05:33] nice nickname brown sensei so i think i i’m sure like we all learned a lot of things from you today

[01:05:39] from the sensei yes thank you for sharing your knowledge and your experience so yeah thank you

[01:05:43] again dr andrew thank you thank you very much henry thank you it’s been a pleasure thank you

[01:06:03] thank you i appreciate it so much thank you so much thank you for joining us today thank you

[01:06:07] man we’ll see you next week bye bye

[01:06:10] bye

[01:06:11] so

[01:06:13] so

[01:06:13] so

[01:06:15] so

[01:06:18] do

[01:06:19] do

[01:06:20] so

[01:06:21] do

[01:06:22] do

[01:06:22] do

[01:06:25] do

[01:06:26] you

[01:06:28] do

[01:06:30] do

[01:06:31] do

[01:06:31] you

[01:06:32] you

[01:06:32] you

[01:06:32] you

[01:06:32] you

[01:06:32] you

[01:06:33] you

Visão de gráfico