Latest / DevQuestions with Tim Corey / 265. Technical Debt Is Not What You Think It Is

Transcript

265. Technical Debt Is Not What You Think It Is · DevQuestions with Tim Corey

• 0:00
  SPEAKER_01: Everyone complains about technical debt.
• 0:02
  SPEAKER_01: When you join a new company, the first thing that will probably overwhelm you is the code base and how ugly it really is.
• 0:09
  SPEAKER_01: A real working code base almost never looks like what you would see in school or in demos.
• 0:16
  SPEAKER_01: It's rare to see a project that follows best practices, is written with clear, understandable code, and that is consistent throughout.
• 0:25
  SPEAKER_01: Instead, it's often a jumbled mess of hacked-together systems that don't follow solid, dry, or implement most design patterns.
• 0:35
  SPEAKER_01: Every company has technical debt, but it often has little to do with how their code is written.
• 0:43
  SPEAKER_01: So let's talk about what tech debt really is, when it's okay, and how you can reduce the harmful effects of tech debt in today's episode of DevQuestions.
• 1:02
  SPEAKER_00: Welcome to the DevQuestiPast with Tim Corey.
• 1:06
  SPEAKER_01: Software development is more than just writing code.
• 1:09
  SPEAKER_01: So let's talk about the rest of it.
• 1:11
  SPEAKER_01: Specifically, let's talk about technical debt and how to navigate it.
• 1:15
  SPEAKER_01: And let's start with a definition.
• 1:17
  SPEAKER_01: Ward Cunningham came up with the phrase technical debt or tech debt to describe the deliberate trade-offs of software development, getting a benefit today in exchange for a cost down the road.
• 1:31
  SPEAKER_01: It isn't necessarily about bad code.
• 1:34
  SPEAKER_01: As a developer, we work within constraints.
• 1:37
  SPEAKER_01: Those constraints force us to make prioritization decisions.
• 1:41
  SPEAKER_01: Do we launch today or do we wait a week and add unit testing?
• 1:46
  SPEAKER_01: Or do we add this feature or fix that bug?
• 1:49
  SPEAKER_01: One way we incur technical debt is by moving faster, knowing that we'll have to pay the interest later.
• 1:58
  SPEAKER_01: For example, I saw a company push a product to production before they had the ability to handle recurring billing.
• 2:06
  SPEAKER_01: They knew they had one month to figure it out before they had an issue.
• 2:10
  SPEAKER_01: By doing it this way, they incurred tech debt, including forcing themselves to create a feature quickly and they made it more difficult to implement because they'd already have live customers in the system.
• 2:25
  SPEAKER_01: But they were able to get their product to market that much faster.
• 2:30
  SPEAKER_01: So they chose a trade-off and they chose tech debt intentionally in order to get the benefits, even though there was a cost associated.
• 2:40
  SPEAKER_01: So let's talk about the various types of tech debt, how to identify their root causes, and then what to do about them.
• 2:48
  SPEAKER_01: Number one is sloppy code.
• 2:51
  SPEAKER_01: You've all seen this, code that is just poorly written.
• 2:54
  SPEAKER_01: It seems hasty, it seems messy, it seems like they really didn't care about the craft of writing software.
• 3:02
  SPEAKER_01: So what's the cause?
• 3:03
  SPEAKER_01: Well, here's some major overarching themes you'll probably see when you see sloppy code.
• 3:10
  SPEAKER_01: Poor process.
• 3:11
  SPEAKER_01: That's probably the biggest one.
• 3:13
  SPEAKER_01: So they don't do code reviews, or they do code reviews poorly.
• 3:18
  SPEAKER_01: They have a lack of shared conventions, or they have poor training.
• 3:24
  SPEAKER_01: So these systems are more about people and processes than they are about the code itself.
• 3:32
  SPEAKER_01: You see, if if a person writes sloppy code and it gets pushed to production, what had to happen for that to be the case?
• 3:41
  SPEAKER_01: Well, they had to write the sloppy code, which means they may be poorly trained and don't understand how to write good code.
• 3:48
  SPEAKER_01: But then the person that did their code review, if they have the code reviews, looked at that code and went, yep, sounds good, and sent that to production.
• 3:59
  SPEAKER_01: So they don't have a great process for code review.
• 4:02
  SPEAKER_01: And or that person that created the code, well, they did things the way they thought was the right way, but that conflicts with somebody else and how they thought was the right way.
• 4:13
  SPEAKER_01: And therefore, what they really need was a common set of conventions that they both follow or they all follow.
• 4:21
  SPEAKER_01: So what's the solution?
• 4:23
  SPEAKER_01: Improve the process.
• 4:25
  SPEAKER_01: You don't just improve the code, that's a symptom, not the actual root problem.
• 4:30
  SPEAKER_01: The root problem is the process.
• 4:33
  SPEAKER_01: So in improve the process.
• 4:35
  SPEAKER_01: What that might mean is it might mean just having a better training system in place where you once a month sit down and train up your whole team on here's how we do things.
• 4:49
  SPEAKER_01: Or maybe it is a better onboarding process for junior developers and interns, where you walk them through here's how to write good code with some regular check-ins.
• 5:00
  SPEAKER_01: Or it might be implementing a code review process so that prop that code isn't just sent to production without another set of eyes looking at it and reviewing it.
• 5:11
  SPEAKER_01: And that code review, it's important how you do it.
• 5:14
  SPEAKER_01: Code reviews shouldn't just be a let's format this differently.
• 5:18
  SPEAKER_01: That's not the purpose of a code review.
• 5:20
  SPEAKER_01: There's so much more to it.
• 5:21
  SPEAKER_01: We'll talk about that later.
• 5:23
  SPEAKER_01: But making sure you have the right processes in place to improve the quality of code is a solution.
• 5:30
  SPEAKER_01: Not just yelling at one person or just complaining about the fact that your code is bad.
• 5:36
  SPEAKER_01: Okay?
• 5:36
  SPEAKER_01: It's fixing the process first and the rest follows.
• 5:40
  SPEAKER_01: Now, number two, a tech debt you might see is workarounds, hacks, repeated code.
• 5:47
  SPEAKER_01: The code base is filled with these shortcuts to get the code working.
• 5:54
  SPEAKER_01: And you see, well, you know, if you'd spent a little extra time, you could have made this repeatable.
• 5:59
  SPEAKER_01: You could have made this better for everybody instead of this workaround.
• 6:03
  SPEAKER_01: Or you see hacks in place that might even say slash slash hack.
• 6:07
  SPEAKER_01: And they might say, this is a hack.
• 6:09
  SPEAKER_01: I know it's a hack, but it works.
• 6:11
  SPEAKER_01: So what is the cause of this?
• 6:14
  SPEAKER_01: Well, the big one will be tight deadlines.
• 6:18
  SPEAKER_01: So when you have rushed features, when the the boss is breathing down your neck saying, I need this out the door tomorrow, even though you know you've got 15 hours worth of work to do in eight hours.
• 6:30
  SPEAKER_01: Okay, so what you're doing is you're rushing, you're getting things done quickly.
• 6:35
  SPEAKER_01: You're you're throwing things against the wall.
• 6:36
  SPEAKER_01: If it works, it ships.
• 6:38
  SPEAKER_01: And you're just trying to get things in place.
• 6:41
  SPEAKER_01: Now, every company does this.
• 6:43
  SPEAKER_01: And part of the reason why is because developers forget why they are there.
• 6:49
  SPEAKER_01: They aren't there to write beautiful code.
• 6:52
  SPEAKER_01: They are there to write code that accomplishes a job.
• 6:56
  SPEAKER_01: And so the non-technical people, the people that are asking for the changes, what they're saying is we need to do our job better.
• 7:05
  SPEAKER_01: And you need to help us do that.
• 7:07
  SPEAKER_01: And we don't really want to hear about the bug fixes you did or the way you re-optimize the code base.
• 7:15
  SPEAKER_01: We don't care.
• 7:16
  SPEAKER_01: What we want is the thing to do our job better.
• 7:19
  SPEAKER_01: So there's always going to be some of that in organization, you can't just eliminate it.
• 7:25
  SPEAKER_01: But there are solutions to this tech debt problem.
• 7:29
  SPEAKER_01: And one of the solutions is clear cause and effect communication with leadership.
• 7:35
  SPEAKER_01: Last week we talked about talking to non-technical people.
• 7:39
  SPEAKER_01: This is especially the case in this particular tech debt.
• 7:43
  SPEAKER_01: Because when you don't communicate clearly the cause and effect of a particular issue, when you don't say, hey, we can absolutely do this, we can get this out tomorrow.
• 7:55
  SPEAKER_01: If we do, it will cost us an extra week of bug fixes.
• 7:59
  SPEAKER_01: Or if we do, we risk these issues happening.
• 8:04
  SPEAKER_01: If you don't clearly communicate that, then the person making the decision, the non-technical person, isn't going to take that into account.
• 8:13
  SPEAKER_01: And they're going to say, I want that feature.
• 8:15
  SPEAKER_01: And if I can have it tomorrow, I want it tomorrow.
• 8:18
  SPEAKER_01: So having clear communication will help reduce some of these.
• 8:23
  SPEAKER_01: It does not mean it will eliminate them, but it's going to improve things.
• 8:28
  SPEAKER_01: So the other part of this is to add in time donation systems.
• 8:34
  SPEAKER_01: Now I call it time donation.
• 8:36
  SPEAKER_01: That's just a term I made up.
• 8:39
  SPEAKER_01: But what I'm talking about is that when you're working in other projects, not every project has a deadline that's immediate.
• 8:47
  SPEAKER_01: You have to get it done now.
• 8:48
  SPEAKER_01: Now you always have to work fast, but there are pockets of time that you can work in, especially if you put into the schedule of every project you can extra flex time, which you should already be doing, but put even more in.
• 9:06
  SPEAKER_01: And then what you're going to want to do is bring those features in into production quicker than the expectation, which is going to benefit, but also save some time in there, some of your extra time, take some of that, and go back and fix some of the tech debt problems caused by those rushed features or tight deadlines.
• 9:28
  SPEAKER_01: So you go back and fix some problems on your own or using the budget of somebody else.
• 9:34
  SPEAKER_01: Okay.
• 9:35
  SPEAKER_01: So this is like if you're working around your house and you just have to get the lawn mowed and you rush around, you mow a lawn, but you didn't trim.
• 9:44
  SPEAKER_01: And you got the majority of stuff done and it it works.
• 9:48
  SPEAKER_01: But if you can take the time where maybe you have another project like sweeping a sidewalk, well, you could trim and sweep a sidewalk in that time and kind of donate some of the sweeping time to trim and sweep.
• 10:05
  SPEAKER_01: That way you are kind of picking up the slack where you can.
• 10:10
  SPEAKER_01: So you're not going to eliminate tight deadlines.
• 10:13
  SPEAKER_01: You're not going to eliminate rushed features.
• 10:16
  SPEAKER_01: But by clearly communicating the cause and effect, that will help.
• 10:20
  SPEAKER_01: And then also donating time from other projects or other places to going back to fix those issues will also help.
• 10:28
  SPEAKER_01: Number three in our tech debt category is misedmatch conventions or different technology versions used in a project.
• 10:39
  SPEAKER_01: So you come into a project and you realize hey, part of this is written in.NET framework, but then we've got.NET standards from other places and.NET Core and other places, and we've got these various versions of things.
• 10:51
  SPEAKER_01: And we started off with win forms.
• 10:54
  SPEAKER_01: It looks like they've upgraded parts of it.
• 10:56
  SPEAKER_01: And you've got this whole process of different systems, maybe different versions of a language.
• 11:03
  SPEAKER_01: Maybe you use microservices.
• 11:04
  SPEAKER_01: And some microservices are on.NET 5, and some are on 6, and some are on 7, some are on 8, some are on 9, some are even on the preview version of 10.
• 11:12
  SPEAKER_01: And you're like, man, this is a mess.
• 11:15
  SPEAKER_01: What's the cause of this?
• 11:17
  SPEAKER_01: Well, the cause is actually the evolutionary nature of software.
• 11:22
  SPEAKER_01: Your software is going to evolve over time.
• 11:25
  SPEAKER_01: And whenever you have an application that lives for more than a year, you're going to have some of this evolutionary nature.
• 11:34
  SPEAKER_01: Now, ideal would be that everything is on the latest version, that's an LTS version, at least, if not the latest version, and that you're always keeping all your dependencies up to date and you're always keeping everything at the latest supported version.
• 11:49
  SPEAKER_01: That's the ideal.
• 11:51
  SPEAKER_01: The real world's not ideal.
• 11:52
  SPEAKER_01: The real world's messy.
• 11:54
  SPEAKER_01: And you're going to find various versions throughout your application.
• 11:57
  SPEAKER_01: You're not going to be able to upgrade everything.
• 11:59
  SPEAKER_01: It's going to be a bit of a mess.
• 12:02
  SPEAKER_01: So what's the solution to this tech debt?
• 12:05
  SPEAKER_01: Well, this isn't really debt.
• 12:07
  SPEAKER_01: It's just the nature of the progression of age of an application.
• 12:12
  SPEAKER_01: Now, yes, again, ideal would be move everything to the latest version, but this is the nature of how an application grows over time.
• 12:22
  SPEAKER_01: And there will be natural stopping points, points where you just can't move forward, at least not without an incredible expenditure of time and effort.
• 12:32
  SPEAKER_01: And those aren't necessarily possible in most organizations.
• 12:35
  SPEAKER_01: And so you're going to stop.
• 12:37
  SPEAKER_01: I worked with somebody, I lamented with him as he explained how he was still on.NET Framework 3.5 and couldn't get off it because of some of their hardware.
• 12:51
  SPEAKER_01: And yes, that's going to happen.
• 12:53
  SPEAKER_01: And yes, that's frustrating.
• 12:54
  SPEAKER_01: And who wants to work on.NET Framework 3.5 applications today?
• 12:59
  SPEAKER_01: But that's going to happen.
• 13:02
  SPEAKER_01: And that doesn't mean that all their new applications, all their applications that interact are going to be.NET Framework 3.5 too.
• 13:09
  SPEAKER_01: They'll be different versions as they're able to progress different parts forward.
• 13:14
  SPEAKER_01: And that's just the nature of software development, especially with an application that is mature and large.
• 13:22
  SPEAKER_01: So it's not really a debt.
• 13:24
  SPEAKER_01: If you can improve it, that's great.
• 13:27
  SPEAKER_01: But it's just something that you have to live with as a feature of software development.
• 13:33
  SPEAKER_01: Now, number four in the category is poorly performing systems.
• 13:38
  SPEAKER_01: So I see this one a lot where the application is in production, it's been used for a couple of years, and the team is just starting to see some bad performance.
• 13:49
  SPEAKER_01: I was a consultant for a number of years, and I would come into companies to help them with these exact situations.
• 13:55
  SPEAKER_01: And I found there were some key things that they'd all done in a similar manner, especially since how I was working with things.
• 14:04
  SPEAKER_01: One of the big ones for me was entity framework.
• 14:06
  SPEAKER_01: I saw entity framework was the cause of a lot of these performance.
• 14:10
  SPEAKER_01: Now I say cause, it's not really the cause.
• 14:12
  SPEAKER_01: The real cause was a bad understanding of how to implement entity framework, which is why I say entity framework is a great tool, as long as you know how to use it well.
• 14:24
  SPEAKER_01: So what's the cause of these poorly performing systems?
• 14:27
  SPEAKER_01: Usually bad architecture or bad design decisions.
• 14:32
  SPEAKER_01: So when the team was building the application, they had a misunderstanding of how to build an application that would scale to where they would eventually be.
• 14:42
  SPEAKER_01: So maybe they worked great in development, it worked great with hundreds of customers.
• 14:48
  SPEAKER_01: But once they had tens of thousands of customers, it didn't work so well anymore.
• 14:53
  SPEAKER_01: And that's a difficult place to be because the tech debt is based upon the fact that you built your system on the wrong foundation.
• 15:04
  SPEAKER_01: You started with a wrong platform and started building off of that.
• 15:08
  SPEAKER_01: And again, that doesn't have to be the technology, it could be how you structured that technology.
• 15:14
  SPEAKER_01: So what's the solution?
• 15:16
  SPEAKER_01: The solution is often to make the best of it.
• 15:19
  SPEAKER_01: You can't say fix this.
• 15:22
  SPEAKER_01: This is why companies need, not just want, but need to have good technical leads or good senior developers that help them make good architectural systems, good architectural designs.
• 15:37
  SPEAKER_01: This is why experience matters.
• 15:41
  SPEAKER_01: Because when you have built demos, when you have built small apps, when you have built a couple of things, you have not seen the end result of these choices over and over and over again to go, oh, we don't want to do this this way.
• 15:58
  SPEAKER_01: We don't want to do that that way.
• 15:59
  SPEAKER_01: We want to make some tweaks here, some changes to make sure that we can scale in the proper way, to make sure that the decisions we make today aren't going to harm us tomorrow.
• 16:12
  SPEAKER_01: Because often you can't just go back and change out the whole foundation.
• 16:16
  SPEAKER_01: That's just not something you can often do.
• 16:18
  SPEAKER_01: When you're building a house, if you put the house on a bad foundation, ripping it out and replacing it is almost impossible.
• 16:27
  SPEAKER_01: It causes massive issues, and sometimes it's just not worth the cost.
• 16:32
  SPEAKER_01: The same is true in software development.
• 16:34
  SPEAKER_01: So sometimes tech debt is going to live with a company almost forever.
• 16:40
  SPEAKER_01: Sometimes the tech debt will live as long as the company does.
• 16:43
  SPEAKER_01: And so you are careful that you don't take on decision making in a way that you're not really familiar with, or that you're just following along with what somebody else says and don't know why.
• 16:56
  SPEAKER_01: You need to understand through experience.
• 16:58
  SPEAKER_01: And that experience comes through building things.
• 17:01
  SPEAKER_01: Because in this category, the solution is just make the best of it, optimize as best you can, rewrite what you can, and just make it as efficient as possible, but know that it will never be as efficient as it could have been had you built it on a different foundation.
• 17:20
  SPEAKER_01: So not all tech debt is created equal.
• 17:24
  SPEAKER_01: And every system is going to have tech debt.
• 17:27
  SPEAKER_01: We don't live in a perfect world.
• 17:29
  SPEAKER_01: We live in a world where we need to make trade-offs every day.
• 17:33
  SPEAKER_01: The key is to understand, understand this idea of making trade-offs and that not all tech debt is created equal, and then make the right trade-offs.
• 17:45
  SPEAKER_01: So thanks for listening.
• 17:47
  SPEAKER_01: And as always, I am Tim Corey.
• 17:49
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 17:52
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcorey.com and enroll in a course.