Using Technical Debt in Your Favor

Managing technical debt is one of them most important parts of engineering. When you&#x27;re resource constrained, which is almost a given in the real world, you need to think carefully about what kinds of debts are worth accruing, and what kinds are absolutely not.<p>I think this is both an art and a science, and the right balance comes with not just engineering experience, but also domain experience, team maturity&#x2F;talent, market&#x2F;competitive pressures, leadership, and culture.<p>There are so many factors involved that it&#x27;s not surprising so many projects accrue horrible debt.

Sure, and credit cards can be a good thing, too. The problem is that most non-technical and formerly-technical project managers just charge everything to their credit cards and don&#x27;t even know they <i>own</i> debt and are making interest payments on it.<p>When that&#x27;s the level of awareness the average development team is dealing with, there&#x27;s limited practical purpose in exploring the nuances of healthy debt management. It&#x27;s more useful to talk about technical debt like nutritionists talk about empty calories and transfats.

I&#x27;m starting to see a trend in hacker news stories of the type:<p>Why <i>bad for you thing</i> is actually good for you. or Why <i>thing everybody likes</i> is not so great after all.<p>Is everyone on hacker news just a compulsive contrarian?

From my recent experience in a new team, this article strikes a chord.<p>Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily.<p>We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.

I&#x27;d say that technical debt is often the best kind of debt you can take on as a startup. Difficult to maintain code is <i>not</i> going to be the thing that puts you out of business. Usually that&#x27;s making the wrong product or not being able to reach your market.<p>Compare that to the other kinds of debt (convertible, for instance). They cost a lot of time to obtain and, potentially, a lot of money in the long run if you do well.<p>Many of the most successful startups had (have?) shitty code. Of course there&#x27;s great counterexamples (i.e. WhatsApp having a 5 person backend team when they were acquired), but as a programmer and founder I find that my urge to make shitty code and ship fast is waay smaller than my urge to make fantastic beautiful code.<p>Of course shipping fast does not imply writing crap code in general. <i>At all</i>. But sometimes it does, and when it does, I&#x27;ve learned that hard way that maybe it&#x27;s better to choose the crap code.

Technical debt can benefit from being managed in it&#x27;s own category - it&#x27;s inevitable as bugs and features. Unmanaged technical debt is sometimes the &#x27;bad&#x27; technical debt we think and read about in hindsight.<p>When I&#x27;m a little more aware of technical debt being created - I track and manage it just like a feature or a bug in the project management system. Separate type, label or category of ticket. It surprising several tools don&#x27;t have this out of the box for some reason.<p>There&#x27;s a few benefits to technical Debt being categorized separately:<p>Tracking technical debt helps provide a sense of the technical debt tickets that are being opened, and floating around both in numbers, size and unknowns.<p>Keeping technical debt items tracked along side features, and bugs in it&#x27;s own category is an invaluable form of cross-training to new team members who are learning the why the current code base came to be how it is, and not just what they may see or think is best.<p>We see how good we might be as a team and individually at identifying technical debt, and if we are improving at identifying it, and help develop a ratio for future accuracy.<p>Regular technical debt review helps create a sense of what technical debt is occurring, and what can be fixed under the hood on another project, if desired, or possible.<p>Keeping an eye on technical debt is important too, if something initially small is at risk of painting the project into a corner, or becoming exponentially difficult to re-factor.<p>Would love to hear strategies and tactics you might use in your TD practice.

&quot;Bad code isn’t Technical Debt, it’s an unhedged Call Option&quot;<p><a href="http:&#x2F;&#x2F;www.ontechnicaldebt.com&#x2F;blog&#x2F;bad-code-isnt-technical-debt-its-an-unhedged-call-option&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.ontechnicaldebt.com&#x2F;blog&#x2F;bad-code-isnt-technical-...</a>

I&#x27;ve often thought that what software projects need is some equivalent of a balance sheet and P&amp;L report - &quot;assets&quot; and &quot;liabilities&quot; together with &quot;income&quot; and &quot;expenditure&quot; equivalents.<p>Looking at technical debt in isolation and always regarding it as a bad thing always seemed simplistic to me.

&quot;If there&#x27;s a chance that the code you&#x27;re writing will never be touched again, why bother to invest a lot of time in it?&quot; In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design.&quot;

This is one of those things I don&#x27;t understand about about software engineering and developers lacking professionalism.<p>Articles and handwavy comments tend to dismiss technical debt as a shrivelling pesky geek who keeps waxing on about how vi is better than emacs. (Someone who doesn&#x27;t have a lot of influence, nor as important).<p>Pushing techincal debt to be managed by the PO, Scrummaster, busuiness, and&#x2F;or managers creates major concerns and problems with what you&#x27;re producing. The passive agressive response: &quot;well convince them&quot; is naive and wrong. They don&#x27;t care. If we&#x27;ve seen anything from the experiences below, they just end up hoping those days won&#x27;t come.<p>Examples:<p>1. Experian- I&#x27;m fairly confident that they had at last one engineer there that bitched about how much the dependencies were falling behind. If they have good ones, there would have been talk about how to automate that process.<p>2. Half baked products&#x2F;data loss bugs - (See mongo)<p>3. Frequent &quot;redesigns of projects&quot; - There are major companies out there that have had to redo their entire product range due to this. It can&#x27;t possibly be affordable. I&#x27;m sure theres lot&#x27;s of lessions on the migrations. But it&#x27;s a lot more expensive in the long run. Side rant: I guess if you believe that you&#x27;re going to go out of business tomorrw, this is justified.<p>My point:<p>1. Be a professional developer, get deep knowledge on frameworks<p>2. Take your time and develop correctly at the start<p>3. Build experience with engineering, not the latest JS library that ignores experience.<p>4. Actually give a shit. Venkat Subermanian made a great qoute at one time: Your code quality is a reflection about how you feel about yourself and your coworkers.

Programmer morale is another factor in good&#x2F;bad technical debt. It can be quite enjoyable to take something like three separate implementations of a similar function, combine them, and delete a bunch of duplicate code.<p>On the other hand, it is nightmarish to toil through some tightly coupled mess and try to rewrite it in a manner that is more maintainable.<p>One makes you feel happy and in control, the other makes you feel like everything is falling apart.

I&#x27;d like to quibble a bit with the definition of technical debt being used. A decision not to refactor code when you don&#x27;t know if you will be improving it is not technical debt in my book. There are many times when I look at a piece of code and say, &quot;This is a smell here, but until we know better what we are building I can&#x27;t remove the smell&quot;. It actually <i>would</i> be technical debt if I covered up the smell with something pretty that wasn&#x27;t related to what I actually needed. Later on I&#x27;ll have to remove that pretty code (or work around it). Hopefully making me feel better about apparent lack of smells is worth it ;-)<p>The idea of technical debt is that you are trading some kind of completeness&#x2F;correctness in the code for something else that is valuable. Usually that valuable thing is time, but it can be something else. For example, perhaps you know that your requirements are wrong. However, the client is unhappy with answering questions. You <i>could</i> pester them some more, or you could implement the obviously wrong requirements and wait for them to find the problem themselves. In this way you defer the frustration of your client to a later time when they might be more approachable.<p>It should go without saying that you should almost never do the above: I&#x27;m only using it as an example of tech debt that isn&#x27;t to do with saving time.<p>There are lots of times where technical debt is beneficial. The key is to understand the cost&#x2F;benefit. This is where we usually go wrong. The cost&#x2F;benefit analysis is usually done by someone who only understands the benefit. It&#x27;s just making the analysis of borrowing money and making the assumption that you don&#x27;t have to pay it back. Hmm... how much money should I borrow in that case? Obviously, as much as I can get!

Information presentation nit: did anyone else find those &quot;mental model&quot; diagrams really hard to parse? (Especially the first one.)

I think this is just another way of saying &quot;avoid gold-plating.&quot; Building a new service to stand up to millions of users and nation-state attackers is probably overkill until you know whether anyone actually wants it.<p>That said, there are definitely early technical decisions that will be very painful to change later on, like how you authenticate users and protect PII.

A lesson I learned early in my career was to avoid spinning out too much on why a particular piece of code someone else wrote was so “bad”.<p>The metaphor in this article fits perfectly- the developer who wrote this borrowed from the future, and without being there at the time, I can’t really judge their calculations.

I’ve always found the metaphors around Technical Debt really interesting. They simplify it to a point where everyone “gets it”; however I have often worried whether there’s a cult of “anti-technical-debt”, much like there are the cults of “absolutely no credit card debt &#x2F; usage ever”. Sure, it works for some, but I’ve also seen product progress completely halt over the argument of “that’s adding to our technical debt”, surely it would be phrased better as “this is adding to our customers experience, at the cost of our chase for purity and technical perfection”?<p>As has been said a few times in this thread: there’s nuance to engineering, and a careful trade off. I think the metaphors are weaponized to a point where that nuance is lost in harsh memories of student-era credit card debt.

I know most here are focused on the dev side of things, but coming from the sysadmin side where I&#x27;ve had to deal with the technical debt of devs + the entire rest of the business IT technical debt, it is anything but good.<p>I&#x27;ve seen the insides of hundred of companies, and the number one cause of technical debt is lack of proper manpower to work ratios. Usually due to short term thinking of IT as a janitorial cost sink instead of as an investment.<p>any company that can break this mold is going to be light years ahead in the long run, because I have a secret to tell you all...<p>The infrastructure holding most businesses up is set to crumble at the slightest puff o wind, whether that wind be legal, like a lawsuit or an audit, or technical like an internal data breach...

&quot;If there&#x27;s a chance that the code you&#x27;re writing will never be touched again, why bother to invest a lot of time in it? In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design.&quot;<p>I found the article excellent and I like the financial debt metaphor a lot. However, the quote above is somewhat confusing. I usually get rid of technical debt (post task) so that a developer can read and understand the code better. They need to do this in order to make some future unknown change. Since a &quot;better design&quot; would at least involve understanding the current design then a strongly disagree with leaving technical debt in code you do not think will be touched again.

There&#x27;s a fine line between iterative development (&quot;first do it, then do it right, then do it fast&quot;) and actual technical dept caused by bad practices (e.g. copy-and-edit instead of re-use). The former method is well-aware of shortcomings and heading towards eliminating them eventually, so I&#x27;m not sure if it should even be called technical debt. Actual technical debt (like real life debt) has the problem of &quot;interest&quot; attached to it, so it grows exponentially. So if you&#x27;re not constantly working to reduce it, it may grow out of hand quickly.

There is a dangerous moral hazard where the people who take out the debt aren&#x27;t the ones to pay it back though. I&#x27;ve seen quite a few people jump from company to company using roundabout ways of creating success that are actually debt of some form. Then they leave as the success is claimed with their resume showing that once this lynchpin left the team&#x2F;company fell apart...

That&#x27;s a decent argument for bottom-up programming. Though I&#x27;d also say what&#x27;s really at issue here is short term vs. long term technical debt. Writing software bottom-up front-loads some short term technical debt but leaves you much better able to avoid long-term technical debt because you have a much more flexible product.

Technical debt is a debt that someone else will have to pay off.<p>My greatest accomplishment at my current job has been deleting 45K-60K lines of code.<p>Not every bit of code will be perfect for many reasons, but please be thoughtful at least, and not just hammer out code. Someone else is going to have to clean up your mess.

There are different kinds od technical debt. One should aim to keep abstractions simple, and to be able to refactor as quickly as possible. But that also means that the code should be manageable. Unreadable code is never a good thing, and will slow down development considerably.

Fantastic article. As an engineering manager working for a lot of young startups, I’ve found technical debt to be inevitable. The author seems to have come to the same conclusion I have: embrace technical debt by leveraging it conciously and tracking it carefully.

We hear a lot about it, but how many people have actually been successful in avoiding technical debt? Any links to writeups&#x2F;blogs&#x2F;analyses?

A far better title for this article, given the content, would have been &quot;How to Manage the Inevitable Technical Debt of your Projects&quot;.

Financial debt - you can see a number and make judgments if you have too much of it or too little. How do you measure technical debt?

Technical Debt, like actual debt, is neither a good nor bad thing. The problem is when you have the wrong amount of it.

Best part is the narration and how Mr. computer says a lot of &quot;undefined&quot; in the middle of the text. :love

My org has no system updates during the month of fiscal close, so we spend that month addressing technical debt.