5 ms·
Self-Admitted Technical Debt
- tpoacher 4y agoMaybe this says more about how I personally use this, but I dont consider FIXME labels to denote technical debt per se. It mostly denotes a "will implement later' top-down prioritisation strategy regarding order of implementing things. E.g. returning a NotaimplementedError may have a a FIXME / TODO next to it to help me find such places in code quickly. True technical debt is stuff like 'lets just use a csv file for now and pretens its a proper solution and totally not give any thought on whether we have an appropriate infrastructure to accommodate a proper database that we will inevitably need down the line'.
- namuol 4y agoMy LinkedIn title has been “Tech Debt Loan Shark” for years and it has garnered some of the funniest cold opens from recruiters over the years. I don’t think there’s a real problem with admitting technical debt at healthy engineering orgs. I call myself a “Loan Shark” because if you aren’t given an option by leadership to take the time to do something right, “admitting” technical debt is less about “taking blame” than it is about covering your ass. When that debt comes to bite the company later, bring your receipts and use them as leverage to do some proper technical investment driven by the engineers on the ground floor.
- adityaathalye 4y agoThat's hilarious! Does that make Management "Technical Debt CDO Traders"? :) "Loan Shark" nicely anchors the business consequence of piling debt on top of debt. The interest rate ain't gonna be your safe little bond interest rate, it's gonna be whatever the situation says it is.
- layer8 4y ago> has garnered some of the funniest cold opens from recruiters over the years. Please elaborate.
- erikpukinskis 4y agoI also don’t think tech debt is a problem in and of itself. And I’ve worked a number of startups with serious tech debt that was holding back velocity. I really enjoy the challenge of plotting a course out of a hole like that. However in my experience without management buy-in it just won’t happen. Even if you as an engineer do the planning work to make it as easy as possible to pick off low hanging fruit, you’ll typically be seen as “off task”. You’ll get lip service about how code quality matters, because without that they’ll scare away the other devs. But they’ll be hoping you give up and just focus on delivering what the management team is asking for each quarter. It takes a ton of patience and management hand-holding, on the scale of 2+ years to shift the culture. And you have to be willing to forgo any chance at personal advancement for that time. Because you’re “off task”. I think you could take that approach and eventually get an advancement bump around the 3-4 year timeframe but it’s not the fastest way to advance by any means. And the total failure rate for an endeavor like that is pretty high. Maybe more than half. Still, it is fascinating work.
- robertlagrant 4y agoTechnical debt is entered into deliberately, as a trade-off for time that must be paid back, with interest. There's no technical debt that isn't "self-admitted".
- groestl 4y agoPublicly self-admitted, in this case. Apart from that: if I inherit the code base of a bad programmer on my job, with a lot of technical debt, which part of it is a deliberate trade-off? It's still "time that must be paid back, with interest", but how it came to be is not part of the definition. The term is merely meant to help confer the problem to non-technical people, who _then_ can make a conscious decision to accrue technical debt. If they do so out of incompetence, it's still technical debt.
- korijn 4y ago> but how it came to be is not part of the definition It's possible the people working at the time were not conscious of the trade-offs they were making. But it still happened and that's how it came to be. > if I inherit the code base of a bad programmer on my job It sucks, but it's almost guaranteed to be the case, to some degree. Think from the company perspective. You're thinking too much from your personal perspective, which is kind of irrelevant to the company. You're not using the term just for you.
- groestl 4y ago> Think from the company perspective I do, rest assured, part of this is my job description. I'm just bumping over the assertion that a deliberate trade-off is a prerequisite for technical debt. It's too specific a reason, and like saying your expenses are higher than your earnings, that's why you are in debt. But in reality, there are many more ways to end up in debt, spending more than you earn is just one possible cause. If you identify technical debt, either hypothetical or existing, the term is an option to explain this to your superiors in a way they might understand. They'll know that they need to do regular small investments to pay it off, or chose an alternative option to avoid it. But that's all there is to it.
- 3np 4y agoWe run on a debt-based economy so it should be no surprise that consciously issuing and managing tech debt works for growth in similar ways IMO. Sure, it's possible to live debt-free and manage finances or architecture frugally - and I consider that a noble thing - but you will have a hard time keeping up with those who keep covering up their debt with more and larger debt.
- adityaathalye 4y agoYes, and I think that is what makes risk assessment hard. All debt packages risk. However, the kind of debt/risk perception we are personally conditioned around in daily life does not translate to software. Managing software debt requires investment banker-like thinking, rather than the mindset of a credit card or mortgage holder.
- adityaathalye 4y agoThis kind of "debt" is seldom "technical". It is a symptom of all manner of factors. In software organisations the symptoms of trouble become visible in codebases and/or behaviour of systems. Thinking about the artifacts as the problem area tends to cause fixing of symptoms and fringe causes, not systemic causes. As far as I've experienced, this sort of "narrow solving due to narrow framing" is endemic in software. It takes a lot of culture building for things like Gemba walk to work in practice, i.e. sure, root about for bad smells because that's how you discover something's fishy, but then work at a systems level to root out the systemic causes and malincentives. edit: use better words
- still_grokking 4y agoNever heard the term Gemba walk before. So I've looked it up: https://en.wikipedia.org/wiki/Gemba https://en.wikipedia.org/wiki/Gemba Gemba means "the actual place" (where value is created). The core idea behind the Gemba walk is a follows: > Gemba (aka Walkie Lookie) walks denote the action of going to see the actual process, understand the work, ask questions, and learn. It is also known as one fundamental part of Lean management philosophy. > Taiichi Ohno, an executive at Toyota, led the development of the concept of the Gemba Walk. The Gemba Walk is an opportunity for staff to stand back from their day-to-day tasks to walk the floor of their workplace to identify wasteful activities. The objective of Gemba Walk is to understand the value stream and its problems rather than review results or make superficial comments.
- atsjie 4y agoWe stopped some devs in our project from adding too may TODOs and FIXMEs. For good reason; the more TODOs and FIXMEs a codebase contains, the less impactfull they are. We had so many TODOs no-one every batted an eye when seeing them, and they never got fixed. It just made you feel bad. Also a lot of TODO's expressed opinions about the "ideal" scenario, but in practice most of those TODOs were for code that was "fine" or "good enough". In those scenarios it's better to omit the TODO/FIXME keyword and just describe the design decision that was made.
- groestl 4y agoDespite their name, i think TODOs should not be treated like tasks to complete, you should not let them make you feel bad. Instead, they are kind of a shorthand documentation of what's going on in an implementors mind, what extensions did they think of? Where did they feel improvements could be made? When changing or rewriting the code, these thoughts can be considered.
- still_grokking 4y agoOh, this smells… If you have mostly "fine" and "good enough" code I fully understand why people want to put TODOs and FIXMEs everywhere; as the code is likely a technical debt catastrophe all over the place. (Because that's the usually meaning behind wording like "good enough".) If nothing of this got ever fixed this means the devs never got time to do that. Just the next red flag… If a manager would tell me I shouldn't put TODOs / FIXMEs into the code I would be on my way out pretty quickly. As this means they constantly produce tech dept but actually want to hide this fact.
- evol262 4y agoIt's just as likely that it's "TODO: add handling for this case which is out of scope during design and which no user is likely to ever request, because the developer argued that it should be there and got shot down"
- throwbadubadu 4y agoDisagree, but this maybe stems from different interpretations of those keywords. Too often seen, and similar often in the aftermath realized myself placing TODOs at places that really were just good enough, bug-free, served all business needs, and mostly could have been a MAYBE or NICE2HAVE (if not totally omitted, because just distracting and not relevant). Often however those ideas are also wrong perfectionalism and can lead to more bug potential or complexity to understand, like trying to create the perfect abstraction while you only have n=1 use cases, especially the younger devs are prone of. (Or one dev believing this part should be written like that and that, while 5 other devs would disagree, that's the best.) TODOs should be really for stuff that is still missing and needed, because of a requirement or some real ugly workaround taken and tech debt created, and not just because a dev has feelings about some code. Similar FIXME also only for really broken stuff or corner cases one for whatever reason cannot fix right now.. > If a manager would tell me I shouldn't put TODOs / FIXMEs into the code I would be on my way out pretty quickly. As this means they constantly produce tech dept but actually want to hide this fact. Noone said that (just not too many), it is not black and white. Often what one sees as tech debt is only wrong perfectionalism, that in the end doesn't help. If you need to place TODOs and FIXMEs often, then why not do them right now? If they are really necessary and you need to put them often like once a day, then actually I would question the place. Placing TODOs and FIXMEs is right where necessary, but please not once a day for something that maybe could just be done better. I btw like the "No TODO without a ticket" rules, they help with this problem automatically :)
- DeathArrow 4y agoWe have technical debt mostly because business guys want it done yesterday with as little people as possible. I always tell POs that if they want X done until Y day, that is going to result in tech debt. When they are asking later why Z doesn't work properly or why it takes time, I just remind them of that technical debt they've agreed on.
- still_grokking 4y agoDoes this change anything in the long run?
- layer8 4y agoIt certainly does sometimes.
- bandika 4y agoNot sure if the code is the best place to track technical debt. Whenever a compromise made that results in tech debt, a ticket should be created in the issue tracker. That way it's easier to get an overview about the project's health.
- replygirl 4y agoin my experience no one doubts that the debt exists, rather people just don't see the same value in addressing it, and aren't easily convinced by arguments they've already been ignoring for years or decades i'm one of two feature devs on a team of four. over three years the team wrote a few hundred tickets for debt. when the client was acquired and we finally got space to address debt, non-technical stakeholders asked us to nuke the list and write a much shorter one that we can prioritize by complexity and customer impact. the debt is now being addressed in the same way as new build, because that's how we treated it; much like new build, it won't be completed to our satisfaction in my experience the only thing that works, short of a major incident that devs forecasted and offered to prevent, is buying time--either to just write better code up front, or to use on _undirected_ remediation
- resonious 4y agoPeople always have stories about technical debt at work and open source, etc. Does anyone have stories of projects with no technical debt? Perfectly maintainable code? We like to blame bizdev and sales for putting pressure on us, but that feels like a cop-out to me. Maybe I'm just a bad programmer but even if you took out the deadlines and "requirements" I'll probably still ship code with some warts here and there. Complaining about people in other positions is no way to improve. Sorry, maybe a bit of an extreme take. Am still interested in stories of especially maintainable codebases, as I'm probably over-correcting here.
- intelVISA 4y agoIt is possible but only in your own projects as tech debt is the result of: Programmers who aren't you, and those damn MBAs ruining your flowstate
- AndreasHae 4y agoCode doesn’t have to be perfectly maintainable and „elegant“. It just has to be useful i.e. good enough. If it solves your user‘s problem, that’s good enough. If your development speed can keep up as you add new requirements, that’s good enough. Doesn’t mean you should ship untested code because that would decrease both the value to the user and your development speed. There are projects out there that go into the other extreme, entering the realm of premature abstraction and accidental complexity. In my experience that’s even worse because in that case it’s hard to convince stakeholders that there even is a problem. It‘s a tough pill to swallow for devs with perfectionist inclinations like me, but at the end what matters is providing value to the user. In fact, I think technical debt will always be present as long as requirements change, and as the saying goes, change is the only constant in software engineering. It‘s not something to be completely avoided as that’s impossible. It just needs to be managed in a pragmatic way to keep up velocity.
- MonkeyMalarky 4y agoI have micro-services that haven't been touched in years because they do one thing, and the requirements of that one thing never change.
- 4y ago
- amelius 4y agoSomeone should write a GPT-3 based technical debt detector.
- didgetmaster 4y agoMy own project has a number of TODO: comments in it. Some of them could be accurately described as unfixed bugs. Others are more like 'feature requests'. When I am in 'bug fix' mode, I will try to locate and fix a few of them. I try to allocate a day now and then to focus on cleaning them up. When you are in startup mode, trying to find the right product-market fit you cannot afford to make the code perfect. You have to get it to the point where potential customers find real value in what it can currently do. Shortcuts are a byproduct of that process. Even if you can't get to it right away, a quick note of the issue in the code itself can make it easier to address it later when the problem is not fresh in your mind (or if someone else is tasked with doing it).
- bradwood 4y agoI think that in an ideal world the only tech debt that's okay is the debt you knowingly enter into. Debt is a part of life as tradeoffs are made every day. But sleep-walking into it is the real risk. Knowing you have it, or are going to incur (more) of it is half the battle. Getting space and buy-in to pay it down, the other half.