Tech Debt In Software Engineering Is Like... Toyota?!

Transcript is auto-generated and may contain errors.

all right folks I'm just headed to the office I guess I have to put it in the drive first um kind of sucks the insta 360 was plugged in but I guess it was plugged in in like file transfer mode so the battery is dead even though it's been plugged in the whole weekend um so that's annoying especially cuz it's actually not raining right now but uh anyway we will go to Reddit for a topic today and uh that's my reminder to you folks that if you want your questions answered leave them Below in the comments uh I would much rather answer your comments before going to Reddit and if you want to have something that's Anonymous or add more detail look for Dev leader on social media that's my main YouTube channel just passed 10,000 subscribers after 26 months yesterday um yeah you can

look for that or Nick centino on LinkedIn send me a message I will keep you Anonymous um Okay so today's topic is going to be about tech debt I feel like this is something that I have to talk about regularly um I guess lots of different perspectives on Tech Deb this one's a little interesting because I think the person is self- acknowledged like I do development you know outside of work and they have this take on Tech de and the first part of the question seemed like genuinely they were C ious on the second part was maybe they got maybe they had snarky comments I didn't read the whole thread uh but they they kind of didn't edit to it and they're like oh like apparently I ship software that is actually not going to be thrown away um which I thought was kind of

interesting um but the way that they framed up how they're looking at Tech Deb I think is the the really interesting thing here I think there's a bit of a a gap in the in the terminology or the understanding of it at least so when they were talking about tech debt they're essentially saying like like isn't hasn't it been proven that basically as soon as you find issues you fix them immediately and um the example they use of in this case is Toyota the car manufactur so they say like and I don't actually know if this is true I think I've heard something like this but the the claim that like you know if Toyota finds any issue uh you know in production or in whatever they will basically go back and and fix it as soon as possible so that they're not rolling out

with more issues and if this is true I think the idea here is like Toyota is uh you know popularly known for being having very reliable cars I think my understanding is both Honda and Toyota do but uh Toyota in particular from what I gather is supposed to uh have high quality vehicles uh I don't drive a Toyota because I don't like Toyotas I like my Mercedes but the interesting thing I think here is that this person's confusing uh bugs and Tech de and in some cases they can be the same or related right you might have buggy software because there is a lot of tech debt that has not been addressed I'm stuck behind a school bus by the way so my morning's about to get worse um I'm already already late for trying to get to work I wanted to get there for

8:00 it's 7:40 and it says it's going to be 50 minutes so that's not happening um which is great but yeah there you can have situations where there's bugs in software because there has been Tech that that's not been addressed and then people have a hard time going to clean it up fix bugs so it's not like I'm making the statement that these two things are completely unrelated and can never be talked about together but in terms of how we look at these things I think that there's something different to look at here so in the example that was oh my god oh they're turning right nice they're not pulling over yes get out of here turn slower next time um in the the case of Toyota and looking at uh got a red light perfect uh and looking at errors in manufacturing this is

what I would call more like a bug in software um yes I would say depending on the severity of the bug this is something you want to address right away but again like I'm introducing the concept of severity and what this person was saying for Toyota it sounds like you know this is just person on Reddit but they're like they find an issue they fix it immediately they didn't mention anything about the severity of the issue right uh but my my guess is that the claim is that Toyota will prioritize any type of issue and get the bug or production issue if I can call it a bug um address straight away now this is tricky in software and It's Tricky for many reasons because even when we call something a bug in software the definition isn't always totally clear right if you have you

can have behavior that you expect because you designed it a particular way and your system behaves as you expect and maybe that's not exactly what a user expects so is it a bug or not your code does exactly what you told it to do which by the way code always does exactly what you tell it to do but um you know you design something to to operate a specific way works for you now you have feedback from users this do not do what I expect is it a bug right in my in my opinion this is arguably a more important thing to address if users that are I don't think it's a bug necessarily Not By Design at least but this is something you'll want to address or else you have unhappy users you might have other situations where a code path isn't doing what

you told it to or what you intended it to and no one even uses that feature they don't even know what exists do you go prioritize fixing that right the the reality is we're talking when we're trying to compare car manufacturing to software these are very different things there's also different implications of of that kind of thing when you have a physical product like a car that comes off of an assembly line and software so I think the analogy is unfortunately just uh not a very good one but I I can understand where they're trying to come from so what I would like to do is briefly talk about maybe the concept of an assembly line and bugs and automated testing I think that could be interesting way to look at it but in terms of tech that I think we're talking about different things

so I'll I'll use the second half of this to talk about but more specifically around Tech that I just need a sip of water here as I pull up to this light okay so what I'm making the claim of here is it conceptually an assembly line for a car manufacturer or assembly maybe it's not even directly on the assembly line it could be other parts of the process I'm not a car manufacturer so I don't mean to oversimplify the entire process of creating a c to just the physical assembly line um but I think that that set of steps in general is a lot more similar to um to trying to put software through like uh cicd right so your continuous integration continuous deployment system and the reason I say that is because your or assembly line in a car manufacturing scenario is a lot

more around something being regularly exercised so that would be like your continuous uh build system right that might be taking code and trying to turn it into the finished product and then there going to be automated tests and stuff that run and if you have quality control checks in your assembly line again I'm not a car manufacturer but I assume that they have these typ YP of things built in at different points in time this would be like running automated tests truly um now in some situations uh an assembly line might be like a better comparison it's like it's kind uh finding an issue in a specific car so not necessarily like the entire model of car is problematic I'm sure they could find issues like that but um I'm assuming it's more likely to say hey this particular vehicle that was being assembled is

is broken or has an issue does not pass the quality control in software the closest maybe analogy to that is like if you're using the same bits of code right so the analogy I'm trying to draw is like if you have a car and the model is being built you'll have different instances of the model coming off of the assembly line we have to think about everything like objectoriented programming right um the uh example with a build system for software is that if the bits were the exact same you would really hope that your tests you know are having the exact same behavior over and over however if the bits are different which is why this kind of is like a bit of a weird analogy cuz like a car model it's going to be the same supposed to be the same each time um

if the bits are different for your build that's like having a different instance of the car coming through the assembly line if you were to find either issues in a specific car that was being manufactured like that instance of the car you would do something about it right you're not going to go say oh well let's just ship it anyway because a customer is going to be paying money for that and they're not going to be happy right and the logic is that once you put it in the customer's hands if they're going hey I found an issue it's going to be a lot more expensive to deal with that down the line and this is a similar parallel to what we have in software and your build system where yeah if you find an issue during testing during your automated test runs you likely

at that point you likely won't go oh let's just ship it because you know you have a bug you actually have tests around the scenario right generally this is what we would call like a regression right so if you have systems that will do regression testing and they catch an issue this is generally in software where you would not ship that so I do see some parallels there but what I'm talking about specifically is is testing in bugs now this person was writing about Tech dead and this is why when I started the conversation I was saying I think the analogy when we think about tech dead and and this process doesn't really line up the same way I think that you could I think you could try and take the example and try to fit it but I don't think it's necessarily uh an

accurate one or it's kind of like there's nothing here car why are you beeping literally in the fast lane on the highway person in front of me is like 30 m ahead uh I think you could try to fit the tech de analogy together there but I think it's going to be kind of clunky so let's talk about tech debt when we have Tech debt uh the way that I look at this is that you could have either conscious Tech de or unconscious Tech de and maybe to to back up one more step because depending on the viewer base I'm sure many of you have heard of tech and have experiences or opinions on Tech and there's probably some other viewers that are going okay like I maybe I've heard of this but I don't exactly know what it is so uh I'm going to

break it down in those two categories but at a high level um Tech dead is going to be sort of like state of our system that is not ideal and there's an Associated cost with trying to go between two uh two states of a system that's a very generic way for me to say it uh now if I if I may if I go to break it down into conscious and unconscious Tech debt what I will do is try to explain it a little bit more and a little bit more specifically so if we have conscious Tech de this is uh maybe a more popular view of how people have negative experiences with it but if we have conscious Tech de this is like a situation where you know as a software developer you're like I want to go build this perfectly and I'm going

to go make it amazing and then you have your your manager is saying no we have to ship the software faster there must be a better way to get it done and you're like look this is the way to do it and then they go no but we have to ship it tomorrow and you go okay there is a corner we could cut and we could you know make this we could do this architectural change or we could design it this way but we don't love it and your manager goes I don't care like we can get it shipped tomorrow and you go yeah and they go great do that and then you're unhappy about it but you do it and then you move on and then it happens again and then basically you are as a business consciously making these DEC decisions where you

were taking what some would argue is the worst or the worst of the two or a worse design decision or technical change right this is just an example but the idea being that you are consciously making a decision to incur some debt into the code base something that you will want to fix up later something that you acknowledge is not ideal okay so hopefully that's a better more clear definition and then unconscious Tech de is basically the same thing except instead of being I was trying to give you a bit of an exaggerated example uh maybe not exaggerated for some people but my version of unconscious Tech dead is that this type of thing actually occurs over time and even if you believe you're making the best design or best architectural decisions for your code base because requirements for software do change over time I've

I've personally in like however long it's been now uh 15 years of building software um I have I have never seen requirements not change uh they're always changing from my experience and when I say always I mean in some cases like you know from working in a startup I've seen requirements change like multiple times in a week uh for working at larger companies I've seen requirements change uh over longer periods of time but they're changing and they're evolving and that's not necessarily A Bad Thing by the way because if you're listening to what your customers want or the environment around you is changing and you know if customers are saying we want something different or environment says nope this is how this is how the world works now um if you don't make changes then what's going to happen is you're going to have unsatisfied

customers or things aren't going to sort of be the way that you expect because the world around you is also changing so if you acknowledge that these types of things happen in software development it means that the way that you architected and designed something to be you know air quotes perfect today is very likely going to have to try and accommodate some different set of requirements later so just a brief Point here that like if you're you know especially if you're more new to this kind of thing picking architectures and design approaches that allow you to be flexible in terms of the directions you go uh I would you know lean towards those types of things because trying to get it perfect for today does not account for the fact that it's likely going to to have uh different requirements in the future having flexibility

baked into that is uh a huge value ad unless you're of the mindset where where you're going well in the future if things change enough we'll just rewrite it anyway uh or rewrite the parts of it anyway that's not necessarily wrong I'm just I air on the side of flexibility so we have conscious Tech debt where we're making a decision consciously to introduce some debt and unconscious because things are evolving over time and you know if you fast forward a year 2 years 5 years from where you're at the code base that you try to make perfect has a crude debt because design decisions were made early on uh Andor even if you're trying to adopt new new ways forward you might have a code base that is a mix of patterns there might be some Legacy parts of the code base that uh you

know they didn't have to get updated at the time but Tech Deb will be the existence of code in your code base that uh generally is going to require extra time and effort to get it up to par or or to get it to a state where you can work with it more effectively now one of the comments that I read right at the top of this Reddit thread and I'm actually kind of happy that it was right at the top because when I do these um depending on what like sometimes I'll go through and I'm like I'm going to try to get a whole bunch of comments so I can when I talk to all of you I can represent the thread and give you my perspective and other times like it's I don't know I I don't want to call it like cheating

but like I want to be able to talk about it give you my view and not have it totally biased by what I read in in the Reddit thread but uh in this case I was like I'll peek at the top one especially because the person had an edit to their post that made me think like they got flamed right away sorry my wife's messaging me she's asking me to take off the cat's collar because our one cat veto decided that he was going to figure out how to explore outside because we have a dog door so we have callers that will beep at them if they get close to the dog door but uh I put the cats away instead so I think she forgot that I was driving to the office early I need water um sorry I got a little distracted there

and now I don't know exactly where I left off and we're screwed um that's what happens when it's early I don't have caffeine so let me let me just kind of start rambling again if I rewind in my brain um I was trying to mention code basis changing over time uh there's going to be cost to getting things to a state that you want to build on top of the um oh yes the redit thread comments see I knew it would come back thanks for thanks for sticking with me the uh top comment was around this idea that they're like you know the re I can't remember even the exact word so I'm not going to do it justice but they basically were saying like the reason that you even have a job in the first place is is like your ability to ship value

to customers essentially so it was kind of of the uh along the lines of like you know there're number one I felt like they were addressing like not really a good comparison um and as long as people are willing to pay for the value that they're perceiving then that's uh that's what you got right so you're not employed to try and it's I know this is kind of hard hard for people to hear but like you're not employed to have perfect code and you're not employed to have zero de Tech debt and you're not employed to have zero bugs that exist in the software these are all things that we want right we want zero bugs in the software we want zero Tech debt but you're employed because you are helping ship value to customers right from a software engineering perspective I see this posted

on LinkedIn all the time like you're you're not paid to code you're paid to solve problems and um this is I mean in my opinion a reality right like you're part of your job is that you're writing code part of your job is that you're fixing bugs that you're addressing Tech debt but you are paid because you're helping ship value to customers right that's what customers pay money for and for some people they've heard me talk about this before and they're like here we go like broken record but um I think for some other people I've had people say in the comments I haven't thought about it that way before which is why I am repeating it and I will keep repeating this in other videos because it's a it's a mind mindset shift right like as as technical people like I'm sure if you're

watching this if you're a software developer like you really enjoy writing code you would want for things to be perfect cuz you're proud of it but that's not going to be the reality okay so what do we do about tech debt right this is maybe the question this whole video begs the question like well why are we talking about it in the first place what are we doing about it if it's not going to be like Toyota where we find some tech debt and we fix it immediately what like what's going on with this now I've also talked about this in other videos but I figured this would be a good spot to bring it up as well which is like as a software developer you're going to find yourself in a position where I mean I shouldn't say guaranteed I think it's extremely likely

in your career you'll find yourself in a position likely more than once where you have identified some part of the code base that you really think should be updated right you're looking at it going man this is bad code or I've had to fix bugs in here like a 100 times and like it's really difficult to work in um we can't write tests on this you know whatever the reason happens to be and you're kind of looking at this going man like I really think that this coach to get some attention it either needs to be uh refactored or it needs to be you know this part needs to be completely Rewritten uh or this part's dead and we should remove it um you like whatever it needs to be and you're going to have this experience where you think it's a a priority and

for those of you that have watched my videos you might know exactly where this is going but you'll find yourself in this position where you're going I think that this is a priority how do I convince others that we should do this work we got to switch lanes over here let me in let me in blue Mercedes um now what does it mean when we have to convince others it means that we have to find effective ways to communicate and what are effective ways to communicate well being able to explain things to your audience in a way that they're going to understand to oversimplify it right like so when we are trying to have conversations about having Tech that addressed what is insufficient and what you may find gets you into a frustrating position is making statements about the state of a code alone right

if you have to talk to a person that is less technical whether that's your manager or a dedicated product owner and you're saying look this code is super messy it's not my my favorite term it's not clean it's not clean code I should just make a rant video about clean code drives me absolutely nuts um clean right you're pry to tell this to your product owner the code's not clean we need to go spend time rewriting it that product owner by that statement why should they care about that right the product owner is interested in getting more value shipped to customers why and I don't me I don't mean this factiously like why should the product owner care about how clean that part of the code is or uh how uh coupled it is to something else or you know how brittle it is like

why should they care about that or how much you don't like looking at it because it's hard to read why should they care about it because stating those things are reasons why you care about it and this is the difference when you're trying to get people bought into something and like sell them on the idea of it say like hey this is why we should what you want to avoid is framing things all about the reasons why you think it's important or it's important to you sorry that's what I mean to say because it's not about what's important to you for someone else to make a decision on it why should they care about it so and I've you know like I said if you've watched my other videos you you'll know where this is going but we have to just change the framing of

it right so you take something where you're like the code is two coupled and you then you go well Nick says we should try to make a or we should try to see like why should the product owner care about this okay well the code's very coupled and that means well I know the product owner has a handful of features they want us to go build in here if I go to touch this code that's very coupled to something else it's potentially likely I'm going to break some other part of the uh the software which means I have to move a lot slower through there or we have a higher risk of something else breaking and we might not notice and also the reason we might not notice until it's too late say in customer hands is because uh the way the code is written

uh it's doesn't support writing tests very easily at least automated tests so really because of the state of the code it's coupled we can't test it uh in an automated way very easily so we're going to have to number one have a higher risk number two spend more time manually testing it right so there is a challenge with time and there's a a risk aspect to it as well and those might be things that a product owner cares about and they might and they might say Hey look it's only this one feature going in there and you're telling me the uh the tech debt work is going to take 3 months and we we haven't touched this part of the code in 2 years and we're just adding one feature they might go I don't think it's a priority it's wor like legitimately it is

worth the r and it's worth spending a little bit of time extra manual testing on it and we'll I'm fine with that and that might be a very acceptable thing based on the tradeoff but at least they have information to try making that decision now it might be very different if they're like hey we plan to keep adding more features into this area so that little three Monon or that three-month investment might seem like a little three-month investment now because we know that over the next two years we plan to keep building in this spot so yeah we should go take some opportunity to go invest more time and maybe even take more than 3 months um you will also find that you'll have more success with the dressing Tech Deb if you're not uh basically grinding to a halt on delivery of other things

right so if for example you're telling a product owner for the next 3 months we can't ship any features or any fixes or anything else because we're we're just going to be rewriting and refactoring this code that's going to be a way harder sell than hey we could incrementally approach this because at least you're adding more value as you're going still a lot of people forget that when you have a business you don't have the luxury of just like turning off adding value you can absolutely do that in your hobby personal projects who cares right like it's for you you do whatever the hell you want and it's not wrong it's literally your project you can do whatever you want if you have tried if you do run a business selling software or selling like software services you might understand this a lot better because

you'll know that if you said I'm just going to take the next X number of months to go rewrite something what's going to happen if you know you have customers that are like there's a bug here and I need it fixed or you have all these customers yelling at you that they want this new feature right are you going to be just like sitting there like and you might you might say like I don't care about getting more users or making more money um by adding this feature I would rather just spend time and then now you have to justify to yourself like I want to address this Tech dad like why is it actually worth me not adding more customers or keeping more customers on right because you have uh your turn rate with customers as well so I feel like there's this element

of like a lot of the time people forget that as software developers were were working for a business and that that separation causes a lot of frustration right because people are like I don't like why don't the product owners get it why doesn't my manager get it and if you look at it from the other side like I've talked to product owners that are like man like I don't understand how the engineers think that I can prioritize this work like I know that they're frustrated by it but like what do they expect me to do I don't understand the code mode and it's just because people aren't communicating effectively that's technically a stop sign I'm going to keep going though there's a school bus but so it's four lanes and the middle turning lane there's a school bus on the other side with the stop

sign out and there's literally I'm not making this up there's probably about 50 plus kids stand outside the school bus there there are no children on the other side of the road the guy in front of me went so I went too but yeah I think a lot of the time I see this frustration come up around Tech de because because people aren't communicating effectively um now anecdotally I will add in uh less this has been less of an issue or Topic at Microsoft in my time here and I'm not saying that it doesn't exist at Microsoft I'm just saying at least the teams I've been on less of an issue but certainly at the the company I was at before from talking with product owners I can say that I don't know a single product owner from my time before that would say oh

my god let's go that's a red light for you you dummy absolute I don't know a single product owner from my time before that has said that they're against Tech Deb every single one of them that I have talked to has said that they are happy to schedule it they want to be able to schedule it for the engineers but the ones that are not doing it are the ones that are also frustrated because they're like I don't understand how I'm supposed to prioritize it against other things so it is it's a bit of a two-way street but the engineers need to do a better job of explaining the other side because the product owner can explain why we need to go either ship bug fixes or features but you can't expect them to understand the code you need to meet them at a point

where they can understand why that has value so I'm just going to the office here like I said I'm way later than I plan so I'm going to wrap it up thanks so much for watching sorry for ranting a little bit but hopefully that perspective helps in some way so thanks and I'll see you next time