Types Of Technical Debt And How To Manage Them

every now and then an idea resonates and kind of sticks sound bites in particular ideas so sticky that it's impossible to shake them loose even if you wanted to one that's in that category is the idea of technical debt so what is technical debt where does the analogy with real debt work and where does it break down oh and rather importantly how should we deal with technical debts when we're faced with it foreign hi I'm Dave Farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you like the content today hit like as well I'd like to thank our sponsors equal experts octopus trisentis and transfig they support the channel so please do support them in turn by checking out their links in the description below technical debt is one of those ideas as soon as you hear the idea for the first time it's kind of obvious what it means the concept of technical debt was invented by Ward Cunningham Ward also invented the wiki so in a rather lovely example of resonance here's what Wikipedia the wiki based encyclopedia on the internet has to say on the topic of technical debt from its inventor technical debt is the implied cost of additional rework caused by choosing an easy or limited solution now instead of using a better approach that would take longer analogous with monetary debt if technical debt is not repaid it can accumulate interest making it harder to implement changes over time these days the idea of technical debt is pretty widely accepted when it was introduced in the early 1990s I think it was probably a bit more controversial so here is an analogy likening ideas in finance to those in software if we write bad code that requires us to revisit it later because it of its low quality or the inapplicability of the solution then that's a debt that we will either repay or that will grow over time and we until we're bankrupt unable to repay our debt and so keep going the bankruptcy equivalency in software terms takes the form of a code base that's so difficult to change that change grinds to a halt or at least slows to the extent that you're spending more time and money on fixing things than you are on producing new ones I see lots of firms that find it hard to release new features even as infrequently as once per year the analogy with financial debt is good in a variety of ways for a start not all debt's bad we might take out a loan of some kind to buy a house or a car and as long as we're in a position to pay off our debts this is a good thing the trouble is that software and software development is as usual a bit more slippery than that if we take out a loan to buy a new car then there's someone who loaned us the money and it's distinctly in their interest to remind us when payment is due they're also going to keep a close eye on us to make sure that we don't start slipping behind with our payments and spending money that we should be using to pay off the loan on I don't know beer or parties this is one of the places where the debt analogy between software and finance breaks down a little bit the problem here is that the debt is based on us taking a loan from ourselves in the future when we're talking about software and let's be honest we're a bit less likely to call the debt police on ourselves or break our own legs if we don't repay on time this means that the slippery slope into technical debt is if anything steeper and slipperier than the slope into real-world debt there are a couple of other places where the analogy breaks down too the first is in how the repayments work if you borrow some money the repayments are usually time based you'll pay off your debt at a specific time or more or more likely through a sequence of payments at regular intervals that makes it easy to track the payments if you don't pay on time the bank can take your car away or Knuckles can come and pay you a friendly visit to remind you of the importance of timely debt repayments how we pay technical debt is different though rarely do we fix a time for repayment and even if we do rarely do we repay on that time then again some of these debts are more important to repay than others if I cut corners and write some terrible code that's nasty to look at and horrible to change I may be ashamed of myself but the degree to which that matters depends very much on the context if my horrible code works and is in a part of a system that's not actually changing now paying off that debt Matt is an awful lot less than if my change is flaky because of the horridness of my solution and in constant development and use by other people in the first case the debt's kind of hidden tucked away and of little real cost in the second the costs will grow pretty rapidly as it affects the work of others and as bug cancer rise this is the interest on our loan I remember facing exactly this dilemma a few years ago we had a couple of usually very good developers working on an important new service I don't really know what came over them on this piece of work but they ended up with an overly complex fairly unpleasant solution to the problem that all of us disliked including them but it worked it passed all of the tests and when we did put it into production it kept working we had it on our to-do list for months and months but it never got high enough up the list for us to actually fix it during the time that I was there anyway this wasn't a bad decision in fact I still think it was the right decision but it still niggles me that there was this part of the otherwise great system that we were all proud of that we weren't proud of Hidden Away in a corner of an otherwise very good system actually I think that this is nearly always true of any system even if it is generally wonderful there will always be parts of it that you'd like to go and tidy up that you're not quite so proud of so our decision on where to make payments for Tech debt is driven not really by time but by urgency and utility if you will forgive me straining the metaphor of tech debt even further we can imagine three different types of debt we could borrow off a supportive friend or family member um they aren't likely to hurt us if we don't pay back at the right time they may not even charge us interest on the payments and possibly they may even loan us some more if we really need it we could borrow from a bank they're going to be stricter about the repayments there will certainly be interest to pay uh debt will automatically grow over time and they'll punish us if we don't pay back at the right times the punishment will be painful but not usually fatal and finally We could decide to borrow from a loan shark the interest on this will be extreme our debt will grow very fast indeed if we don't pay the consequences will be really severe and probably involve visits from Knuckles again we may or may not survive this depending on the nature of the loan so the example I gave earlier the service that we weren't proud of but that worked and wasn't a maintenance headache is the loan from a friend or family member I'd say that deferring the use of automated testing but covering it with manual testing instead is the bank loan it's a pretty slippery slope it's nasty because of the interest the costs of the loan is ever increasing until it's repaid that is your testing will get slower and slower if it's manual and the system is growing you may get into serious enough debts that all forward progress holds you're working so hard maintaining the repayments testing your releases that you're almost grind to a halt and struggle to make an annual or a six monthly release I worked with a company a few years ago that hadn't released any new features into production for over five years and then there's the loan shark this is not doing any testing and no real design and taking a purely tactical approach to change this is fairly common in feature Factory organizations where the rate of feature production is prioritized above all else or in Legacy shops where the debt is so high already that no one's even trying to pay it off anymore they just try not to be in when Knuckles visits at its extreme organizations that do this often also see the best way of scaling up as adding more people so teams will have hundreds of people working in Big Balls of mud systems who are afraid to change anything significant because the system's not tested in any useful way and they're scared of breaking things so now they compound the debt problem adding to the interest repayment by simply adding their code for a new feature in the first place that they find they don't really think about the design of the system there isn't one really They Don't Really worry about the maintainability of the solution the code's already in a mess and so this change only makes it a little bit worse this is a death spiral approach they will come a time when Knuckles is knocking at your door and there's no way where to escape to feature will be asked for that is essential for the business and impossible to add by the tech team customers will start complaining about the low quality of the code but the team struggle to fix things because every change destabilizes the system further they're so afraid to make changes that they get more and more conservative in what they will are willing to change and so slower and slower in terms of output this may sound like hyperbole but this is surprisingly common particularly in big companies there are lots of causes of technical debt Wikipedia lists 15. I think that at least the first three will be familiar to you if you've been around software for any amount of time the incremental growth of cruft it even has a name some people call it bit rot I'd recast the second one a bit because it's easy to misunderstand I'd prefer to say the failure to start and maintain a sense of design throughout the life of the system rather than requiring us to design at the start and I imagine a lot of people nodding along when we lay the blame also on the third one in the third one on business pressures let's look at each of these and talk about how to avoid these causes of debt I think that the idea that bits rot and that systems always get worse is wrong or rather it's a symptom of a deeper problem I can remember during the internet boom of the 2000s being approached by several startups trying to hire me to help them build their world beating software the business ideas were sometimes wacky but also pretty diverse but quite a lot of them had something in common when it came to business strategy their aim was to hire a technical team to get them to build their software quickly to implement this world-beating idea and then get rid of the technical team because they were too expensive once the software was finished the only real good thing about this strategy was that it made my decision easy I'm not going to work with anyone who thinks like that about software this is not how software works in the real world in the real world the majority of settings software is never really finished good software is built through an evolutionary process and then it's maintained through an evolutionary process even in the old days I've planned waterfall style development people recognize that software spent lots more time and effort in maintenance than it did in development most estimates during that time said that in terms of cost it was something like an 80 20 split in favor of Maintenance 80 percent of the time software spent its and cost software was in maintenance not in development I think that the model has moved on in Agile development certainly in good Agile development there isn't really a clear division between development and maintenance rather it's about an ongoing iterative incremental development and maintenance of all of the time until the product dies this is more like gardening than fire and forget widget creation if we treat our software as a more organic thing tending it and reshaping it over time we start from the assumption that our guesses today are probably wrong and so we'll need correction at some time in the future if we maintain our code as a habitable space where we can quickly confidently and safely make change then we're never really done our code is just the current snapshot of the continuing evolution of our system in this world view maintaining our ability to easily and safely make change is the definition of quality in a system really once the software Works high quality software on this measure can be changed more easily to correct any of the other deficiencies that we might spot over time teams that work this way have a laser focus and a very low tolerance for technical debt they prefer to live debt free on the whole which is why I'm still agonizing over that damn service all of those years ago the solution to the next problem on Wikipedia's list follows on from the solution to the first the reason that I corrected in my terms Wikipedia's description is because a naive reading of this says okay that means I need to design everything up front and that's a terrible idea I think that coding is design and design is architecture we don't get any of these things right first time and so great systems come from people recognizing that and working in a ways that allow for it so we need to fairly quickly come up with a rough cut initial guess at our design to start with some organizing principles that will help us to structure choices in our code and then we start work and every time we spot a place where our initial design guesses were wrong we refine our code our design and maybe even our architecture I think it's important to maintain this sense of design in the team as an ongoing thing so that there is some agreed sense of where stuff should exist in the code even if years later after the system has been in production for years um we need to add a new feature we don't just drop it in randomly anywhere in the first place that we think of we think about how this relates to our design and we place it in the best best guess of the right place for it to live the place where we look for it if we didn't know where it was this means maintaining the model this tourist map of our system all of the time this mitigates against the Tactical creep the old Coast code bases otherwise face finally what about the dreaded business pressures well this is where the other side of the financial analogy really kicks in the world of Finance how do we avoid falling into debt in the first place we invest in things we may invest in skills and our careers so that we have some source of income but we also invest financially we pay now to accrue bigger benefits later this analogy stands up in software too if your boss comes and applies business pressure by saying something like we've got this deadline coming so we need you to get stuff done then what does that really mean are they some kind of drug drug addict borrowing money from Knuckles to feed their habit of features or do they really mean we need to produce software as efficiently as possible and maintain our ability to continue to do that because if it's the second one and it ought to be the second one then working with high quality working to always minimize technical debt working so that our code is a high quality easily maintainable place to work is the most efficient way to do work if we write crap today my work will be slower tomorrow because I'll be fixing the crap that I wrote today we borrow from our own future when we allow technical debt to grow we invest in our own future productivity if we work to minimize technical debt even then we will still make mistakes and create unintended debt but then we've only borrowed from a friend and so the consequences aren't quite so severe thank you very much for watching foreign [Music]

Channel: Continuous Delivery

Views: 51,345

Keywords: technical debt, managing technical debt, tech debt, how to manage technical debt, types of technical debt, scrum, agile, computer science, Continuous Delivery, software engineering, software development, Dave Farley, software testing, what is technical debt, technical debt in software engineering, technical debt definition

Id: 1MBpK_PxEnU

Length: 17min 58sec (1078 seconds)

Published: Wed Sep 28 2022