13 ms·

All code is technical debt

273 points by j45 3y ago

jeffrallen 3y ago
Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.
- sitzkrieg 3y ago
  this is why deleting code is so great. a lot easier time than the MEs too
  - adolph 3y ago
    https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday . . . . Bill Atkinson, the author of Quickdraw and the main user interface designer, . . . was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. . . . they stopped asking Bill to fill out the form, and he gladly complied.
- datadrivenangel 3y ago
  The code without code is the eternal code. All other code requires updating dependencies.
- phpisthebest 3y ago
  You mean a No Code Solution like PowerApps :)
- toppy 3y ago
  https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode
- zoogeny 3y ago
  Early in my career I worked with an engineer more senior than me who was responsible for performance optimization. He once told me "the fastest thing you can do is nothing at all" which was his way of saying it is better to find unnecessary steps to eliminate rather than making necessary steps execute faster.
- Jensson 3y ago
  Code isn't a product, code is the blueprint for the product. Have you heard mechanical engineers say "no blueprint is the best blueprint"?
  - jeffrallen 3y ago
    I've heard "grinder and paint makes me the welder I ain't!" Close enough.
StayTrue 3y ago
Sure I sometimes say features are assets but code is a liability. Usually as part of an argument against complexity that some engineers favor to be ready for speculative future circumstances.
pphysch 3y ago
I work with a FOSS product that has millions of lines of C. As a student, I would have been wowed by seeing these FOSS contributors each with +100,000 LOC in a single project. Now that I am more familiar how barely-functional the software is, with glaring architectural mistakes papered over by literally millions of LOC, I am more cynical. "Contributing" 100K LOC by implementing a bespoke http.c and mysql_client.c in 2020 is almost never something to be proud of from a SWE and product perspective. Great for ego/NIH and job security though. “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry
- ravenstine 3y ago
  That's the thing. Not making the problem worse is fine and all, but most projects simply aren't removing enough. It's amazing that today's software functions as well as it does, and programmers today are lucky they can hitch a free ride on decent hardware.
  - pphysch 3y ago
    Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+. It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability. But if you propose a major refactor, there is no question about (rightly) where the blame lies.
    - ravenstine 3y ago
      Modern software is so buggy, but it's considered the norm. I was talking to a non-technical person recently about that, and although they were at first puzzled by my view that most software is problematic, they realized that they experience the same bugs I complain about all the time. It's become so normal that people hardly notice it, but that doesn't make it better because bad software wastes human life time whether they realize it or not. > But if you propose a major refactor, there is no question about (rightly) where the blame lies. LOL Yep. Worse is when the blame lies on the semi-technical cofounder of your company who, granted, achieved quite a lot on their own, wrote a barely maintainable mess. Do you really want to be the one to indirectly point out that his code needs to be replaced? Haha I think a lot of developers would rather wait for the Dilbert Principle to kick in so that the cofounder gets out of the way enough for significant changes to finally be made.
tomxor 3y ago
> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development. No! Ward's blog post linked in this very paragraph [0] describes the original definition quite clearly, and it's not this. The term was originally intended to describe the delta between a programmer's current understanding acquired through the process of developing the software, and the accumulated implementation which is based upon a combination of past understanding. Because writing a program is often a process of discovery and learning about the problem and solution space, it's not usually possible to write the ideal implementation up front. It's quite clear In Ward's 2nd paragraph where he describes the correction of this debt: > it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk. What the author is describing is the modern definition that it has acquired independently, where by programmers knowingly take shortcuts... this is an entirely different phenomenon, intentionally writing code in a way that is less than ideal even based on current understanding. I find the original definition far more interesting and insightful, but the modern one is perhaps more reflective of the more common realities of the pressure developing software in a business today. [0] https://wiki.c2.com/?WardExplainsDebtMetaphor https://wiki.c2.com/?WardExplainsDebtMetaphor [edit] Despite this error, I do agree with the sentiment of the article, that too much code is a liability, that features can cost more than they are worth. Ward's definition of technical debt affects the cohesion and correctness of the code, the idea that if you could tear it all up every day and re-write it from scratch that it would always reflect the most up to date understanding, and for moving targets the most up to date problem, that it be absent of the weight of past misconceptions or solutions to past problems... aiming for minimal code makes achieving that state far more viable - these are complementary insights, so it's a shame the nuance of the original definition was lost.
- 0xdeadbeefbabe 3y ago
  I had no idea Cunningham was so thoughtful about it. It's a term used by less thoughtful people in most of my experience.
cesarvarela 3y ago
Living is dying.
- ranting-moth 3y ago
  You should write a 15 minute-reading blog post about that. Make sure to do a summary. I think you could use this linked blog post as a template.
0xbadcafebee 3y ago
Don't you just love clickbait blog articles that make no sense? HN sure does!
- metabagel 3y ago
  Even if you disagree with the article, I feel like the comments here are insightful.
ravenstine 3y ago
More code means more opportunities for things to go wrong, but I wouldn't go quite as far as saying that all code is tech debt, even though it makes for a good blog post title. Looking at all code in such a pessimistic light doesn't actually seem that useful. It might be one thing if there were adequate measures for "good code", but those hardly exist, or are dwarfed by inadequate measures that are entirely opinion-based. Less code than more might be as good as it gets, but I would rephrase the author's "To avoid technical debt, don’t write code" as "To avoid technical debt, write less code" (though perhaps "fewer codes" may be more grammatically accurate). Code is not bad, and tech debt isn't necessarily bad either. We code to accomplish things, and as much as I despise shitty codebases, even companies with a lot of tech debt often provide a lot of value to both customers and employees. In fact, I would say that tech debt in and of itself is no more a problem than monetary debt in real life, except when it's not being paid off and is collecting interest. We could not only write less code but actually pay off our tech debts, yet the structure of incentives and most companies hardly facilitates that.
ska 3y ago
I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is most often used - which isn't exactly the original proposal as another commentpoints out. The key part of it is the analogy with an interest rate. I can decide do put 5k on the credit card for a last minute holiday, but for as long as I don't pay that off, I'm paying 20-something percent, every month, forever. Similarly for example a rush to add features to hit a demo deadline can introduce brittleness and abstraction failures into your codebase that you pay for every time you make changes, add features, do nearly anything. The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). That doesn't mean its the wrong move, for the same reasons that taking on debt can be the right move for a person or business.
- sorokod 3y ago
  Yes, a bit silly this. Code is means to an end, it makes sence to think of code as liability (maintenance cost, inevitable bugs, etc .. ) but this must be contrasted with the value it provides within some reasonable timeframe.
  - deleted 3y ago
    [deleted]
- seadan83 3y ago
  I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a brand new story does not have this constraint / cost. Which is all to say, software is an asset, code is a cost. The functionality of software is the valuable thing, all the code to do that is overhead. Thus, every line of code has a cost, and an ongoing cost that is forever then payed (which is exactly the interest; simply taking the time to scan/read over a line, to scan between 5 files vs 20, those are all ongoing costs)
iraqmtpizza 3y ago
Please sign the rights to all your technical debt over to me. Thank you.
anonporridge 3y ago
All wealth (negentropy/complexity) creation creates debt. Whenever we build, we use intelligence to rearrange things in more complex ways that don't naturally occur. Ideally, this creates value by unlocking things we want that we previously couldn't have. But this work always creates a burden on the future (debt) to maintain the complexity we built. This is especially true if the complexity doesn't gracefully degrade back to a more primitive state and the choices of people coming after you are "maintain" or "collapse and regress back further than your predecessor started, because you've forgotten the old ways". If you don't want to place this burden on the future, then the only surefire solution is to not build anything. Just be happy with maintaining what you have and hope that the environment doesn't change around you so much that what you have isn't good enough. But I don't think this is what we want. We need to build a LOT more for some of the existential goals we have as a civilization. Just know that every act of creation that sticks around intrinsically creates a burden on the future to maintain it. Acknowledge and respect that, but keep building.
- anonporridge 3y ago
  Addendum; A concrete example of this conflict that I've been wrestling with recently. I've been considering going all in on home automation. Zigbee devices and sensors everywhere managed with custom rules on Home Assistant. I want to get to the point where I don't ever have to touch a light switch. However, I also recognize stories of others who have done this, and then died leaving their less technical spouse with an unmaintainable mess that gradually degrades and falls to Entropy. They eventually have to hire someone to rip it all out and revert to a dumb house. By going all in on home automation, I'm creating debt for future me and my partner to maintain it all. At the moment, I'm not convinced that this act of creation will actually create enough value to justified the debt incurred.
  - flerchin 3y ago
    This is exactly why I haven't automated my newest house. All the automation in my last one was net-negative to the buyer.
deleted 3y ago
[deleted]
captainkrtek 3y ago
I like to think of technical debt with a counter balance of a “credit score”. Ie: as an organization, what is our ability and track record to manage complexity over time. It’s not a perfect analogy, but the difference between a low interest rate mortgage and a high interest payday loan have parallels to the balance made in delivering software while limiting complexity. A developer that is a bit of a tornado, rapidly churning out new and exciting capabilities at the expense of reliability, brittleness, and complexity, will surely catch up with an organization sooner or later.
jmduke 3y ago
I agree with many of this essay's points, but the flamboyant headline is a reductive way to view software (and a bit of a dangerous meme.) Your job as an engineer is, amongst other things, to identify the (sometimes rare!) instances in which code creates leverage beyond the business value it creates. Good abstractions are valuable assets!
Ensorceled 3y ago
> So to give a quick recap, as adding more code to a product will slow down development, we should view all code as technical debt. Not a fan of this habit of taking a perfectly good technical term and redefining for another purpose; especially if there is already good, existing measures, such as code complexity. Rather, than calling all new code "technical debt", how about every planned feature, as part of it's total cost calculation, include the incremental costs of any increased code and/or architectural complexity it introduces.
mjr00 3y ago
The author is conflating a few different things. All code and features are overhead. It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked full-time on a new feature, they would be at 50% of their capacity after the feature was "done" for 3-12 months due to ongoing maintenance. So yes, writing less code rather than more code for the same feature is good, generally. But all software requires some code, so the challenge is figuring out which code is necessary for which the maintenance and overhead costs are worth it. Technical debt is a bit different; the code is there, but something about it makes it challenging to maintain. There's lots of reasons this can happen. Sometimes the business requirements change and the domain concepts or abstractions no longer make sense. Sometimes the technical requirements change and decisions made at the time are no longer the right ones, if they were ever right at all. But the most common reason, in my experience, is that the people have changed. New people have come in, looked at existing systems and code, and either don't understand it or don't agree with how it was written from a personal stylistic point of view. Like a functional programming looking at a system that was designed with textbook OOP and calling that technical debt. As you move into more senior technical positions or engineering management one of the bigger challenges is determining what's "real" technical debt that's worth tackling, versus what's perceived technical debt that's based on personal opinions.
- metabagel 3y ago
  And sometimes it can be difficult to tell when a complex solution is actually appropriate and not a candidate for being re-implemented.
AndyPa32 3y ago
In a similar vein I always try to convince colleagues that the best code is the one that is never written. As a close second the code that has been deleted. It has no bugs and doesn't need maintenance.
abakker 3y ago
Put more directly: all choices are costs. Specifically, a choice is choosing to incur opportunity cost in order to realize some outcome. E.g. Buying a sandwich so you can eat it to be full is choosing not to spend that $10 on anything else. In durable and intellectual domains, choices can incur opportunity costs, but also lead to switching costs in the future. I've always understood technical debt to be the combination of opportunity costs and switching costs resultant from a specific choice that resulted in a durable physical or intellectual good. In this way, technical debt is not a particularly complicated topic. The issue is that switching costs can be very high, and to eliminate the accumulated opportunity cost and switching costs of a previous decision, it is necessary to incur a new set of costs going forward. There is no "debt", there is only cost. The idea that you can "owe" on a series of choices implies that you can "pay it back". This is false. You can make choices - some may be more costly than others both immediately and in the future - but all choices have costs always. To quote Rush, "if you choose not to decide, you still have made a choice".
knodi 3y ago
If all code is tech debt then all employees are liabilities.
- marcod 3y ago
  I mean I have definitely felt like a liability before :p "What do you mean, we have to pay health insurance for all of them?? Let's get the cheapest option available!"
- imhoguy 3y ago
  Well, IT/Engineering as a cost center is everyday corporate life.
ranting-moth 3y ago
Excuse my rule breaking, but holy shit this is crap.
open-paren 3y ago
I prefer to say that "code is a liability, not an asset." Liabilities are useful and help achieve goals (want a house, get a mortgage), but the code is not the goal. Code is a mechanism that achieves that goal, but more code becomes a drag.
indymike 3y ago
"I prefer my products to have less code in them." -- Can't remember what smarter person than I said it... Conceptually, I think every developer eventually realizes that every line of code ends up adding maintenance cost, and potentially constraints on the future. "Technical Debt" is one way to think about it - if you don't have the resources to maintain. Otherwise, it's just a cost as others have pointed out. Maintenance is harder than most people think: documentation, translations, tests, all are part of this cost.
erikerikson 3y ago
The author should really read Peter Naur's "Programming as Theory Building". [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
jrockway 3y ago
Code is inventory, not debt. Inventory is good and bad. If someone comes to your store and everything is out of stock, you will make $0. So you want some inventory. But if you have too much inventory and nobody is buying anything, then your inventory just rusts in storage and becomes worthless. Code is pretty much exactly the same. Most features are sitting in storage in the hopes that someone comes by to buy it. Sometimes they do! Sometimes they don't. If you were the guy with a toilet paper warehouse in March 2020 you did great.
- mmcnl 3y ago
  Code is an asset. Assets need to be managed, maintained, or else they will degrade. Assets have costs.
  - postalrat 3y ago
    Gold bars don't need to be maintained and don't degrade. They just exist. That's the type of asset to own. A white elephant needs a living are, food, elephant experts, vets, etc. That's much closer to the type of asset most code is.
    - defrost 3y ago
      I bet you five gold bars that five gold bars left "unmaintained" won't be there when you pop back in a year. It's not a big thing and there's no need for us to fall out over this .. but gold bars are famous for requiring additional ongoing security costs. Even just burying them in the desert isn't as secure as it used to be.
      - postalrat 3y ago
        I'll take that bet for 5 unmaintained gold bars. If you win you get all 5. If I win you give me 1. I'll let you know when they are buried.
        defrost 3y ago
thiago_fm 3y ago
The correct term is "technical liability". I like to dive into a codebase the same way people do accounting for the finances of a company, the parallels always make sense.
rqtwteye 3y ago
I always tell people that deleted code is the best code.
alex201 3y ago
Insightful articulation of the concept of technical debt (likening it to a financial loan) but it somewhat oversimplifies the nuanced and often non-linear nature of software development. I observe that technical debt is not always a straight trade-off between speed and future maintenance. Sometimes, what appears as debt could be a strategic decision aligned with evolving business goals or market demands. The article underestimates the dynamic nature of software projects where initial assumptions might change, making the so-called 'debt' a necessary step in the process of innovation and adaptation. This perspective fails to acknowledge that in certain scenarios, adhering too rigidly to best practices can lead to missed opportunities or an inability to pivot quickly in response to user feedback or changing market conditions.
jfengel 3y ago
Conversely: "The things you own, end up owning you". A line of code is something you own. It makes you obligated to either maintain it or let it go. The only truly free development is greenfield development, where you can write whatever you want. And now you've got code you own, and you're in its debt. So yeah, we can all live wonderfully free lives by writing no code, but that does tend to up our other debts, i.e. student loans, mortgages, etc. Good code is not more code or less code but code that does what the customer actually wants it to do. The better we understand the customer's needs, the more we can write just the correct code. We can't always do that; often the customer themselves doesn't know what they need. Regardless, the way out of this conundrum is to stop counting code, technical debt, or other ways of trying to make the human problem into a computer problem. The real problems are always out there, not in our repositories.
fhars 3y ago
There is this old notion that you should think of "lines of code spent to solve a problem", not of "lines of code produced".
veucast 3y ago
It's interesting to see someone putting a positive spin to technical debt. The level of technical debt you can afford taking on (technical risk) is heavily dependent on how you define technical debt at your company. You must understand how taking on a technical risk will have an impact in the current and future operation of the entire business/product/team. Not all technical debts are created equal, so to encourage people to see it as a positive thing or risk worth taking, without giving them this disclaimer is irresponsible.
otabdeveloper4 3y ago
Nah, some of it is an heirloom.
equalsione 3y ago
This is a “when you think about it” argument. As in “humans are just tubes, when you think about it”. Technical debt is a thorny issue already. Arguments like this don’t help.
daniel-cussen 3y ago
[dead]
wins32767 3y ago
Code is best reasoned about as a depreciating asset, not technical debt.
pyromaker 3y ago
Ultimately, everything can be debt. If code is technical debt, a HR system or a process that you implement for the company at that particular point in time is also a debt (process debt? HR debt? debt nonetheless). If we are trying to deliver fast by expediting software development and taking shortcuts (technical debt), another department can also do something similar (quick, our HR process is slow and cumbersome, implement that HR system) - which would solve the particular issues for the business at that particular point in time, but may not the needs of the business later on. For software, the issue is that we believe we can introduce technical debts, that is, it is permissible to introduce and talk about technical debts. We wouldn't necessarily talk about implementing a new HR system often. We think writing a line of code is fast (and define what "fast" means) but it isn't.
- dilyevsky 3y ago
  Yeah “code is debt” seems to be popular meme among the “thought leaders” these days. Somehow their baroque processes (eg scrum), nonsense okrs and out of touch roadmaps are never debt - curious, right?
csours 3y ago
Any code _having_side_effects_ is technical debt. Pure functional code is innocent of any sin.
Nevermark 3y ago
Like quite a few people, to me the word "debt" doesn't naturally fit the problem of building code that will be harder to build on later. For me, "technical debt" would be shipping a product that immediately starts consuming technical resources not associated with value production. Like a rickety distributed database that needs manual labor to fix regular corruptions. That would seem analogous to debt. Not fully paying for what you have, resulting in continuous expense until the full payment is made. Writing code without care for future work is a different problem. It is the "bad foundation" problem shared by design, engineering, construction, book stacking, ... It has 1000 names: "Building on Sand", "Ticking Timebombs", "Bandaid Solutions", "Cutting Corners", "Short Term Fixes", "Playing Jenga", "Putting Lipstick on a Pig", "Haste Makes Waste", "Disaster Waiting to Happen", etc. Living code is a foundation. Shoddy foundations are dangerous to build on & costly to fix. Don't build shoddy foundations. No new terminology. You don't need a special strategy to explain this. Tell your CEO they can get their enormous features yesterday, they just need to sign off on a "shoddy foundation" exception. Informally by email is fine. You are ready to unleashed the troops from responsibility for future mishaps! All you need is that little written record! Then presto. The coders are standing by, breathless, ready to party! (And preparing their resumes.) ___ I love the essay's point that each feature adds assumptions, and assumptions add complexity. The rub of remodeling.
- deleted 3y ago
  [deleted]
jrochkind1 3y ago
Whether it is exactly the same concept as actual technical debt or not... This makes a lot of sense to me, and explains why you always think "I can do better than that monster", and it does always feel better at first, then then inevitably grows to feel like a monster where it's hard to make any changes. Especially when we are thinking about tools for developers, where developers are the users, libraries or web frameworks and such. Or even languages/ecosystems. A bunch of existing libraries/frameworks/platforms/ecosystems are a mess... surely we can do better! let's make a new thing! This explains why we are always hopping to the new thing, and always convinced the new thing is better... And the new thing is better and so much easier to work with, even though it doesn't have all the features the old thing did, but okay, we just need to keep building it out to encompass those features, using our much better sense of architecture and usability that we've proven we have because look how clean and simple and usable our first draft is! Now, there is such a thing as better or worse designed, as the OP admits, poorly implemented or beautifully implemented. But... comparing the new thing that only has the most basic features and seems really elegant to the old thing that covers all the edge cases... isn't actually a good comparison to tel you which is better implemented. That new thing is going to get cruftier when you cover the edges, _always_. And it shows that if you want to keep your thing feeling smooth and elegant and easy to work with.. you have to keep it as small as possible and resist all feature requests! > For a feature to add value to your product, it needs to be useful to users. Features can have a negative value when the technical debt they add to your product outweighs the value they add to it. Thinking of tools for developers where developers are the users... oh yeah it's true. > A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones I would describe that as limiting the number of "concepts" inside your code... and definitely applies to libraries/frameworks/tools for developers.
mjw_byrne 3y ago
Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom. Other examples that come to mind are "a complete rewrite is always a mistake" (no, it just has different risks/rewards), "if you are reading this part of the docs, you are trying to be too clever" (your API is too much for my puny brain is it?) and "all functions are APIs" (no, my two-line string quoting func is not an API, actually).
- drewcoo 3y ago
  > Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom. That seems to describe most of the programming clickbait here. I could swear there used to be more discussion of startups . . .
lnxg33k1 3y ago
I personally consider tech debt code that is hard to reason about, change, understand or not covered by unit test. I think the author just wanted to say something nonsense to go viral and get share/increase klout, but if the concept of code is symmetrical to the one of tech debt then the concept of tech debt is useless and we need something else to scope code that is hard to be worked on, and back to square one
resters 3y ago
I've ranted about this before. Everyone would like to have infinite time to write the best possible code and do everything right. In a business, particularly a time constrained or financially constrained one, the art of running the business entails deciding which corners to cut, what tradeoffs to make. Ironically, startups hire inexperienced people who often over-peform but sometimes underperform. A less risky approach would be to spend more (cash or equity) to hire people who are more of a sure thing. This could be called "execution debt" but it is accepted as visionary and associated with believing in people and being able to sense talent. Tech (architecture, code, devops, etc.) is no different. A highly skilled team will be able to make the right tradeoffs and cut the right corners. Tech debt is usually what people call something that appears in hindsight to have been the wrong corner to cut, however one would need a time machine to understand why the decision were made and what was competing for time/attention/resources and why. Engineering is the discipline of managing tradeoffs to create something. When working with a codebase that appears to be technical debt, the important thing to ask is what the options are today to address it. It may be beautifully written, clean code that uses the wrong abstractions, or it may be a solid architecture with some ugly code and style that needs to be addressed. Lots of people have biases due to their own preferences, but the thing to rememeber is that chances are the code was not made by someone with infinite time and perfect knowledge.
csbartus 3y ago
I think code / coding is overrated. Coding is debt. If we look at math / category theory we have functorial semantics, which means semantics (code) is auto-generated from syntax (design): https://www.algebraicjulia.org/assets/slides/nist-workshop-2022/main.html#/syntax-and-semantics https://www.algebraicjulia.org/assets/slides/nist-workshop-2... If we look in another direction we see LLMs which (will one day) generate code from design. If I look back those years in my career, I was always paid to write the same code all over again (lists, trees, tables, menus, user profiles, shopping carts, dashboards, heroes, apis, databases...), each time in a different context (given by the company) ... Such a waste of my time, and my employers money. Today at least in the MVP / startup scene coding is debt / obsolete. Startups all should go no-code. Later, after the startup phase, companies should focus _only_ on provably-correct, likely-correct understanding of their problem domain, on a design specific to their audience, and rapid iteration. The rest, coding, should be not no-code, but fully automatic yet provably correct (in the sense of total and partial correctness) I hope, and I wish coding will be eliminated. It's a big fun writing machine code in Assembly, algorithms in C/C++, full-stack web apps in Ruby on Rails, and user interfaces in React. But after a while it's not sustainable neither emotionally nor economically.
- syndicatedjelly 3y ago
  Do you really believe no-code applications mean there’s 0 code? You’re just relying on someone else’s code at that point, and have no ability to customize business logic.
hohu 3y ago
[flagged]
28304283409234 3y ago
The way I see it: Code is an abstraction of reality. Reality changes continuously. Therefore all code is techdebt. This is one of the reasons I oppose the “automate all the things” mantra.
wanderr 3y ago
This article seems to be more making the case that features are technical debt, sort of. And that's a valid point too. But it is so so easy for useless code to accumulate. At every company where I've worked as an engineer, I've ended up deleting lots and lots of code, far more than I ever write. Like, half of the codebase. Largely by applying static analysis to find code that clearly never worked, the confirming that it's not used (which is usually obvious or we'd be seeing crashes). Often times it's sad to see how long that code was maintained, with engineers wasting effort on migrating it as things changed, without ever questioning whether it's even needed.
rglover 3y ago
My standard for tech debt: - Unnecessary (too many or too heavy) dependencies that can be replaced by DIY code, or at least, smaller dependencies. - Implementations that stray from the standard set by the rest of the code in the project or actual guidelines written by a project leader (e.g., we don't use jsdoc anywhere but a developer randomly crams it in during a copypasta). - Over-complicated implementations that serve as an ego-pleasing flex for the author, but are impossible for even an experienced developer to reason through. - Implementations that were done to service a single customer in pursuit of short-term revenue, or, that were rushed through due to manager/stakeholder panic and inevitably collide with one of the above. --- Keep those three in check and you'll have limited issues. Edit: a good talk by Oliver Reichenstein (of iA Writer fame) that helped me years ago https://vimeo.com/102343006 https://vimeo.com/102343006 -- it's from a design perspective but has parallels to development. One quote of his that constantly pings in my head: "slow the fuck down."
- deleted 3y ago
  [deleted]
jongjong 3y ago
Code which solves a well defined problem with the absolute minimal amount of logic necessary is not technical debt. If a module is fully replaced later, it doesn't mean it was technical debt. Technical debt is characterized by its need to be refactored/modified in a way which is not backwards compatible. If a module can be substituted in its entirety with minimal changes which directly reflect requirement changes, then it wasn't technical debt. Good code is about setting up components in a hierarchy which allows you to adapt to requirement changes by substituting modules as opposed to refactoring those modules. Note that if you're adding features to an existing module, this does not count as a refactoring. Not if the module is backwards compatible with respect to its dependents. But of course when adding new features you want to stick to the minimalist philosophy so you need each module to have clear responsibilities.
RecycledEle 3y ago
I could argue that every mechanical thing will eventually fail, requiring a repair or a redesign and rebuilding. By that argument, every physical thing is technical debt. The reality is that some things we use are joys to use, and other things are problems that we have to keep patching. Some cars are fantastic, good-performing, reliable tools that get the jobs done. Others are constantly breaking down and just might make it, sputtering, over the next hill. I wonder how hard it would be to get major religions to endorse the concept that engineers who build useful, reliable, loved things are rewarded in the afterlife, while those who create things we all hate will be punished in the afterlife. Most religions already endorse the concept that we should serve our fellow man, and not cause needless suffering. Causing millions of hours of suffering for a paycheck is generally considered evil.
- steveBK123 3y ago
  It's not THAT hard to start a new religion these days. Plenty of prior art. I mean look at Mormons, Scientology or you know.. the EA people.
resonious 3y ago
> To avoid technical debt, don’t write code I think there's some truth to this, but code isn't always written by software engineers and isn't always executed by computers. You might end up with crazy Excel macros, and/or arcane people-processes with single points of failure. To "not write code" at all is probably to never move or do anything. Sure, you never lose if you never play, but you also never win.
deleted 3y ago
[deleted]
orourke 3y ago
All code may be technical debt but the interest rate can vary.
thomastjeffery 3y ago
All debt is credit. The only differences are who it is going to, and when. So what should our goals be? Less code means fewer features, which can make the UX path longer. More code means more features, which can make the UX path more confusing and strenuous. There is some kind of balance to be struck. The goal is for every UX path to be flexible and easy. Is that even possible? Can we have our cake and eat it, too? > Adding new assumptions increases debt There's the word I have been thinking about all week: "assumption". It's a tricky little bastard, and it really deserves more focus than it has any right to. You see, that word is the heart of our problem. It's not the amount of code you write, the features you add, the way you design your UI/UX, or even how flexible your user configuration is. It's the assumptions themselves. Assumptions are walls. Once an assumption has been added, it’s there to stay. It's easy to move an assumption around. Too easy! So easy that you move it without even knowing; but it is still there, lurking. No matter how hard you try to get rid of it, or to get around it, the assumption is guaranteed to stand in your path. Your only hope is that the assumption is there to guide you; its only other option is to guard you. So what can we do about it? We can not. No need to get rid of something you never made in the first place, right? But how do you make software that is unassuming? How can you make a tool without catering that tool to its intended work? How can you make a path without a destination? There's something we have gotten notoriously used to as software engineers: a finished product. After all, what else would an engineer strive to make? Finished products are things. Programs aren't. Programs are systems! Programs are stories. What kind of system is ever finished? I can only think of one: a dead one. At the end of its life, a system becomes cold, hard, sturdy, and complete; and the story meets its end. How did we ever convince ourselves that that is a worthy goal for software? I'll tell you how: we assumed. That assumption has been lurking at the heart of software design ever since, and all we can do now is move it. It's time to start over. --- This is where I answer my very first question: who? Who designs the software? Don't assume it's the engineer's job: it's the user's turn now. The next question is, when? When does the user design their software? When they use it. Any time before that would make them an engineer. What should our goals be? That's the best part! The user already knows her goal. That makes her precisely the right man for the job. --- If you followed any of my rambling so far, you are probably asking yourself the most important question, "What could this possibly look like?" That's a good question. I have something really close to a coherent idea. If you would like to hear about it, feel free to ask.
bue7jclotemp 3y ago
I only skimmed through the article so I might have missed this part, but did the author consider picking up a few books about domain design or search some examples how do others implement such event organizing systems? Because based on what I read, that seems to be his problem. He started implementing a system without having a good understanding of the domain's inherent problems and their common solutions. Not everything needs to be re-invented. Even though I have never worked in this domain (event organizing) but still I could from the top of my head pull out one such example where a team went into great detail how to design and implement an event organizing system which answers most of not all the problems that the author faced: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/jj591578(v=pandp.10)?redirectedfrom=MSDN https://learn.microsoft.com/en-us/previous-versions/msp-n-p/...
pluto_modadic 3y ago
without reading the article, the title is basically the thesis of every CIO/CTO who's drunk the koolaid and thinks moving to AWS somehow removes complexity. It trades complexity of code for grey problems and complex infrastructure/terraform/builds. Just a note - all extra AWS infrastructure over a simplistic minimum is technical debt.
kammygood 3y ago
Working code may not require maintenance, but dynamic context often requires adjustment. How do you think we balance the flexibility and inherent stability of well-functioning code?
5350-uiop-1130 3y ago
some devs really have their heads up their own arse we seem to believe we are craftsmen sculpting some work of art code is just shit you write, means to an end, be it closing a ticket or going home. soon deleted ("deprecated") and replaced with new trendier shit. > "we need to ensure we’re working on valuable features" yeah valuable features are what your boss's boss needs to get their promotion and/or bonus.
lngnmn2 3y ago
[dead]
hasoleju 3y ago
Reading this article reminded me that we need to think more about the whole lifecylce of a software product. I usually make the mistake developing a product thinking that it will exist forever and new features will be added continuously. The truth is: Almost every software product has a point in time where it is obsolete. (Maybe except some really big enterprise solutions or OS libraries). I see these phases for many small software product: 1. Development Phase (Features are added continuously) 2. Maintenance Phase (No features are added, compatibility is ensured and bugs get fixed) 3. End of Support Phase (Basically no development happens for the product any more.) The second phase "Maintenance Phase" is usually much longer than the development phase for a successful product. The cost during this phase heavily depends on the amount of features, that were added in the first phase. So be careful what you develop, you need to maintain it for a long period of time and at one point in time it will be obsolete anyways.
015a 3y ago
- "Technical debt" (usefully) divorces the idea of implementation velocity from business outcomes. You have a thirty year old system written in a language barely anyone understands anymore; but, its still generating profit for the business. This is technical debt; its "useful" to separate from business outcomes because it enables you to consider it as one factor, among many, to overall business outcomes, rather than prematurely co-mingling the two ideas. - Similar to the generality "all code is technical debt" I'll make one of my own: "All technical debt is abstraction assumption failure". You've got an abstraction; you assume it behaves some way; it doesn't. You've got an abstraction; you need to add new functionality behind that abstraction; you assumed this is a good place or a good way to add this functionality; it isn't. The vast majority of technical debt is just this. There may be a couple more categories like "we can't hire people to work in this language" or even something like system performance, but the vast majority of technical debt is a failure of understanding of some abstraction. - That previous statement does not assert that this is an invalid way of viewing technical debt. "Understanding" the code is literally the most important job of software engineers; less "engineer" and more "museum keeper" sometimes. I've never liked the term "bad abstraction" because it shifts the responsibility of being understood to the abstraction, and not the engineer. It encourages "code bad, rewrite" mentality. Sometimes that is the best course, but I think its always a bad idea to tackle that without understanding the abstraction, and if you understand the abstraction then you probably wouldn't be calling for a rewrite because its "bad"; you'll be calling it for more specific reasons. - Unilaterally classifying all code as technical debt isn't just wrong; its asinine. "Technical debt" is a useful way of thinking about some code; if you remove that from your lexicon, you may start believing that all code either is or isn't technical debt. If all code is technical debt, your ability to think about the quality of code holistically, with its nuance, is reduced durastically. If you think no code is technical debt, you'll inevitably walk down the path of hyper-engineering perfect giga-systems that, even if they work flawlessly and satisfy all business needs, took way too long to build, cost way too much to run, and inevitably still confuse your replacement in six years.
kugurerdem 3y ago
I just read the essay and found the examples given interesting. I certainly believe there are valuable lessons to be learned from them. However, I don't think the content fully supports the claim made in the title. It seems that the author's focus is on how things can become needlessly complicated, even when trying to implement a seemingly simple feature. However, citing only a few examples is not sufficient evidence. Could we not also consider instances where writing additional code could actually help reducing long-term technical costs? Aside from this, I found the following points interesting: > A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones. > Even when it becomes apparent after the fact that the feature isn’t performing as well as we anticipated, the typical approach is to do nothing. Part of this is the sunk cost fallacy. Often there is the hope that even if the feature isn’t used today, it will be in the future. But there’s also a legitimate reason for doing nothing. Removing a feature also has a cost, both in the development effort needed to cleanly remove it, and in potentially upsetting customers. So once a feature is added to a product, it is almost always there to stay.

273 points by j45 3y ago

jeffrallen 3y ago

Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.

sitzkrieg 3y ago
this is why deleting code is so great. a lot easier time than the MEs too
- adolph 3y ago
  https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday . . . . Bill Atkinson, the author of Quickdraw and the main user interface designer, . . . was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. . . . they stopped asking Bill to fill out the form, and he gladly complied.
datadrivenangel 3y ago
The code without code is the eternal code. All other code requires updating dependencies.
phpisthebest 3y ago
You mean a No Code Solution like PowerApps :)
toppy 3y ago
https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode
zoogeny 3y ago
Early in my career I worked with an engineer more senior than me who was responsible for performance optimization. He once told me "the fastest thing you can do is nothing at all" which was his way of saying it is better to find unnecessary steps to eliminate rather than making necessary steps execute faster.
Jensson 3y ago
Code isn't a product, code is the blueprint for the product. Have you heard mechanical engineers say "no blueprint is the best blueprint"?
- jeffrallen 3y ago
  I've heard "grinder and paint makes me the welder I ain't!" Close enough.

StayTrue 3y ago

Sure I sometimes say features are assets but code is a liability. Usually as part of an argument against complexity that some engineers favor to be ready for speculative future circumstances.

pphysch 3y ago

I work with a FOSS product that has millions of lines of C. As a student, I would have been wowed by seeing these FOSS contributors each with +100,000 LOC in a single project. Now that I am more familiar how barely-functional the software is, with glaring architectural mistakes papered over by literally millions of LOC, I am more cynical. "Contributing" 100K LOC by implementing a bespoke http.c and mysql_client.c in 2020 is almost never something to be proud of from a SWE and product perspective. Great for ego/NIH and job security though. “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry

ravenstine 3y ago
That's the thing. Not making the problem worse is fine and all, but most projects simply aren't removing enough. It's amazing that today's software functions as well as it does, and programmers today are lucky they can hitch a free ride on decent hardware.
- pphysch 3y ago
  Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+. It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability. But if you propose a major refactor, there is no question about (rightly) where the blame lies.
  - ravenstine 3y ago
    Modern software is so buggy, but it's considered the norm. I was talking to a non-technical person recently about that, and although they were at first puzzled by my view that most software is problematic, they realized that they experience the same bugs I complain about all the time. It's become so normal that people hardly notice it, but that doesn't make it better because bad software wastes human life time whether they realize it or not. > But if you propose a major refactor, there is no question about (rightly) where the blame lies. LOL Yep. Worse is when the blame lies on the semi-technical cofounder of your company who, granted, achieved quite a lot on their own, wrote a barely maintainable mess. Do you really want to be the one to indirectly point out that his code needs to be replaced? Haha I think a lot of developers would rather wait for the Dilbert Principle to kick in so that the cofounder gets out of the way enough for significant changes to finally be made.

tomxor 3y ago

> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development. No! Ward's blog post linked in this very paragraph [0] describes the original definition quite clearly, and it's not this. The term was originally intended to describe the delta between a programmer's current understanding acquired through the process of developing the software, and the accumulated implementation which is based upon a combination of past understanding. Because writing a program is often a process of discovery and learning about the problem and solution space, it's not usually possible to write the ideal implementation up front. It's quite clear In Ward's 2nd paragraph where he describes the correction of this debt: > it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk. What the author is describing is the modern definition that it has acquired independently, where by programmers knowingly take shortcuts... this is an entirely different phenomenon, intentionally writing code in a way that is less than ideal even based on current understanding. I find the original definition far more interesting and insightful, but the modern one is perhaps more reflective of the more common realities of the pressure developing software in a business today. [0] https://wiki.c2.com/?WardExplainsDebtMetaphor https://wiki.c2.com/?WardExplainsDebtMetaphor [edit] Despite this error, I do agree with the sentiment of the article, that too much code is a liability, that features can cost more than they are worth. Ward's definition of technical debt affects the cohesion and correctness of the code, the idea that if you could tear it all up every day and re-write it from scratch that it would always reflect the most up to date understanding, and for moving targets the most up to date problem, that it be absent of the weight of past misconceptions or solutions to past problems... aiming for minimal code makes achieving that state far more viable - these are complementary insights, so it's a shame the nuance of the original definition was lost.

0xdeadbeefbabe 3y ago
I had no idea Cunningham was so thoughtful about it. It's a term used by less thoughtful people in most of my experience.

cesarvarela 3y ago

Living is dying.

ranting-moth 3y ago
You should write a 15 minute-reading blog post about that. Make sure to do a summary. I think you could use this linked blog post as a template.

0xbadcafebee 3y ago

Don't you just love clickbait blog articles that make no sense? HN sure does!

metabagel 3y ago
Even if you disagree with the article, I feel like the comments here are insightful.

ravenstine 3y ago

More code means more opportunities for things to go wrong, but I wouldn't go quite as far as saying that all code is tech debt, even though it makes for a good blog post title. Looking at all code in such a pessimistic light doesn't actually seem that useful. It might be one thing if there were adequate measures for "good code", but those hardly exist, or are dwarfed by inadequate measures that are entirely opinion-based. Less code than more might be as good as it gets, but I would rephrase the author's "To avoid technical debt, don’t write code" as "To avoid technical debt, write less code" (though perhaps "fewer codes" may be more grammatically accurate). Code is not bad, and tech debt isn't necessarily bad either. We code to accomplish things, and as much as I despise shitty codebases, even companies with a lot of tech debt often provide a lot of value to both customers and employees. In fact, I would say that tech debt in and of itself is no more a problem than monetary debt in real life, except when it's not being paid off and is collecting interest. We could not only write less code but actually pay off our tech debts, yet the structure of incentives and most companies hardly facilitates that.

ska 3y ago

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is most often used - which isn't exactly the original proposal as another commentpoints out. The key part of it is the analogy with an interest rate. I can decide do put 5k on the credit card for a last minute holiday, but for as long as I don't pay that off, I'm paying 20-something percent, every month, forever. Similarly for example a rush to add features to hit a demo deadline can introduce brittleness and abstraction failures into your codebase that you pay for every time you make changes, add features, do nearly anything. The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). That doesn't mean its the wrong move, for the same reasons that taking on debt can be the right move for a person or business.

sorokod 3y ago
Yes, a bit silly this. Code is means to an end, it makes sence to think of code as liability (maintenance cost, inevitable bugs, etc .. ) but this must be contrasted with the value it provides within some reasonable timeframe.
- deleted 3y ago
  [deleted]
seadan83 3y ago
I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a brand new story does not have this constraint / cost. Which is all to say, software is an asset, code is a cost. The functionality of software is the valuable thing, all the code to do that is overhead. Thus, every line of code has a cost, and an ongoing cost that is forever then payed (which is exactly the interest; simply taking the time to scan/read over a line, to scan between 5 files vs 20, those are all ongoing costs)

iraqmtpizza 3y ago

Please sign the rights to all your technical debt over to me. Thank you.

anonporridge 3y ago

All wealth (negentropy/complexity) creation creates debt. Whenever we build, we use intelligence to rearrange things in more complex ways that don't naturally occur. Ideally, this creates value by unlocking things we want that we previously couldn't have. But this work always creates a burden on the future (debt) to maintain the complexity we built. This is especially true if the complexity doesn't gracefully degrade back to a more primitive state and the choices of people coming after you are "maintain" or "collapse and regress back further than your predecessor started, because you've forgotten the old ways". If you don't want to place this burden on the future, then the only surefire solution is to not build anything. Just be happy with maintaining what you have and hope that the environment doesn't change around you so much that what you have isn't good enough. But I don't think this is what we want. We need to build a LOT more for some of the existential goals we have as a civilization. Just know that every act of creation that sticks around intrinsically creates a burden on the future to maintain it. Acknowledge and respect that, but keep building.

anonporridge 3y ago
Addendum; A concrete example of this conflict that I've been wrestling with recently. I've been considering going all in on home automation. Zigbee devices and sensors everywhere managed with custom rules on Home Assistant. I want to get to the point where I don't ever have to touch a light switch. However, I also recognize stories of others who have done this, and then died leaving their less technical spouse with an unmaintainable mess that gradually degrades and falls to Entropy. They eventually have to hire someone to rip it all out and revert to a dumb house. By going all in on home automation, I'm creating debt for future me and my partner to maintain it all. At the moment, I'm not convinced that this act of creation will actually create enough value to justified the debt incurred.
- flerchin 3y ago
  This is exactly why I haven't automated my newest house. All the automation in my last one was net-negative to the buyer.

deleted 3y ago

[deleted]

captainkrtek 3y ago

I like to think of technical debt with a counter balance of a “credit score”. Ie: as an organization, what is our ability and track record to manage complexity over time. It’s not a perfect analogy, but the difference between a low interest rate mortgage and a high interest payday loan have parallels to the balance made in delivering software while limiting complexity. A developer that is a bit of a tornado, rapidly churning out new and exciting capabilities at the expense of reliability, brittleness, and complexity, will surely catch up with an organization sooner or later.

jmduke 3y ago

I agree with many of this essay's points, but the flamboyant headline is a reductive way to view software (and a bit of a dangerous meme.) Your job as an engineer is, amongst other things, to identify the (sometimes rare!) instances in which code creates leverage beyond the business value it creates. Good abstractions are valuable assets!

Ensorceled 3y ago

> So to give a quick recap, as adding more code to a product will slow down development, we should view all code as technical debt. Not a fan of this habit of taking a perfectly good technical term and redefining for another purpose; especially if there is already good, existing measures, such as code complexity. Rather, than calling all new code "technical debt", how about every planned feature, as part of it's total cost calculation, include the incremental costs of any increased code and/or architectural complexity it introduces.

mjr00 3y ago

The author is conflating a few different things. All code and features are overhead. It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked full-time on a new feature, they would be at 50% of their capacity after the feature was "done" for 3-12 months due to ongoing maintenance. So yes, writing less code rather than more code for the same feature is good, generally. But all software requires some code, so the challenge is figuring out which code is necessary for which the maintenance and overhead costs are worth it. Technical debt is a bit different; the code is there, but something about it makes it challenging to maintain. There's lots of reasons this can happen. Sometimes the business requirements change and the domain concepts or abstractions no longer make sense. Sometimes the technical requirements change and decisions made at the time are no longer the right ones, if they were ever right at all. But the most common reason, in my experience, is that the people have changed. New people have come in, looked at existing systems and code, and either don't understand it or don't agree with how it was written from a personal stylistic point of view. Like a functional programming looking at a system that was designed with textbook OOP and calling that technical debt. As you move into more senior technical positions or engineering management one of the bigger challenges is determining what's "real" technical debt that's worth tackling, versus what's perceived technical debt that's based on personal opinions.

metabagel 3y ago
And sometimes it can be difficult to tell when a complex solution is actually appropriate and not a candidate for being re-implemented.

AndyPa32 3y ago

In a similar vein I always try to convince colleagues that the best code is the one that is never written. As a close second the code that has been deleted. It has no bugs and doesn't need maintenance.

abakker 3y ago

Put more directly: all choices are costs. Specifically, a choice is choosing to incur opportunity cost in order to realize some outcome. E.g. Buying a sandwich so you can eat it to be full is choosing not to spend that $10 on anything else. In durable and intellectual domains, choices can incur opportunity costs, but also lead to switching costs in the future. I've always understood technical debt to be the combination of opportunity costs and switching costs resultant from a specific choice that resulted in a durable physical or intellectual good. In this way, technical debt is not a particularly complicated topic. The issue is that switching costs can be very high, and to eliminate the accumulated opportunity cost and switching costs of a previous decision, it is necessary to incur a new set of costs going forward. There is no "debt", there is only cost. The idea that you can "owe" on a series of choices implies that you can "pay it back". This is false. You can make choices - some may be more costly than others both immediately and in the future - but all choices have costs always. To quote Rush, "if you choose not to decide, you still have made a choice".

knodi 3y ago

If all code is tech debt then all employees are liabilities.

marcod 3y ago
I mean I have definitely felt like a liability before :p "What do you mean, we have to pay health insurance for all of them?? Let's get the cheapest option available!"
imhoguy 3y ago
Well, IT/Engineering as a cost center is everyday corporate life.

ranting-moth 3y ago

Excuse my rule breaking, but holy shit this is crap.

open-paren 3y ago

I prefer to say that "code is a liability, not an asset." Liabilities are useful and help achieve goals (want a house, get a mortgage), but the code is not the goal. Code is a mechanism that achieves that goal, but more code becomes a drag.

indymike 3y ago

"I prefer my products to have less code in them." -- Can't remember what smarter person than I said it... Conceptually, I think every developer eventually realizes that every line of code ends up adding maintenance cost, and potentially constraints on the future. "Technical Debt" is one way to think about it - if you don't have the resources to maintain. Otherwise, it's just a cost as others have pointed out. Maintenance is harder than most people think: documentation, translations, tests, all are part of this cost.

erikerikson 3y ago

The author should really read Peter Naur's "Programming as Theory Building". [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

jrockway 3y ago

Code is inventory, not debt. Inventory is good and bad. If someone comes to your store and everything is out of stock, you will make $0. So you want some inventory. But if you have too much inventory and nobody is buying anything, then your inventory just rusts in storage and becomes worthless. Code is pretty much exactly the same. Most features are sitting in storage in the hopes that someone comes by to buy it. Sometimes they do! Sometimes they don't. If you were the guy with a toilet paper warehouse in March 2020 you did great.

mmcnl 3y ago
Code is an asset. Assets need to be managed, maintained, or else they will degrade. Assets have costs.
- postalrat 3y ago
  Gold bars don't need to be maintained and don't degrade. They just exist. That's the type of asset to own. A white elephant needs a living are, food, elephant experts, vets, etc. That's much closer to the type of asset most code is.
  - defrost 3y ago
    I bet you five gold bars that five gold bars left "unmaintained" won't be there when you pop back in a year. It's not a big thing and there's no need for us to fall out over this .. but gold bars are famous for requiring additional ongoing security costs. Even just burying them in the desert isn't as secure as it used to be.
    - postalrat 3y ago
      I'll take that bet for 5 unmaintained gold bars. If you win you get all 5. If I win you give me 1. I'll let you know when they are buried.
      - defrost 3y ago

thiago_fm 3y ago

The correct term is "technical liability". I like to dive into a codebase the same way people do accounting for the finances of a company, the parallels always make sense.

rqtwteye 3y ago

I always tell people that deleted code is the best code.

alex201 3y ago

Insightful articulation of the concept of technical debt (likening it to a financial loan) but it somewhat oversimplifies the nuanced and often non-linear nature of software development. I observe that technical debt is not always a straight trade-off between speed and future maintenance. Sometimes, what appears as debt could be a strategic decision aligned with evolving business goals or market demands. The article underestimates the dynamic nature of software projects where initial assumptions might change, making the so-called 'debt' a necessary step in the process of innovation and adaptation. This perspective fails to acknowledge that in certain scenarios, adhering too rigidly to best practices can lead to missed opportunities or an inability to pivot quickly in response to user feedback or changing market conditions.

jfengel 3y ago

Conversely: "The things you own, end up owning you". A line of code is something you own. It makes you obligated to either maintain it or let it go. The only truly free development is greenfield development, where you can write whatever you want. And now you've got code you own, and you're in its debt. So yeah, we can all live wonderfully free lives by writing no code, but that does tend to up our other debts, i.e. student loans, mortgages, etc. Good code is not more code or less code but code that does what the customer actually wants it to do. The better we understand the customer's needs, the more we can write just the correct code. We can't always do that; often the customer themselves doesn't know what they need. Regardless, the way out of this conundrum is to stop counting code, technical debt, or other ways of trying to make the human problem into a computer problem. The real problems are always out there, not in our repositories.

fhars 3y ago

There is this old notion that you should think of "lines of code spent to solve a problem", not of "lines of code produced".

veucast 3y ago

It's interesting to see someone putting a positive spin to technical debt. The level of technical debt you can afford taking on (technical risk) is heavily dependent on how you define technical debt at your company. You must understand how taking on a technical risk will have an impact in the current and future operation of the entire business/product/team. Not all technical debts are created equal, so to encourage people to see it as a positive thing or risk worth taking, without giving them this disclaimer is irresponsible.

otabdeveloper4 3y ago

Nah, some of it is an heirloom.

equalsione 3y ago

This is a “when you think about it” argument. As in “humans are just tubes, when you think about it”. Technical debt is a thorny issue already. Arguments like this don’t help.

daniel-cussen 3y ago

[dead]

wins32767 3y ago

Code is best reasoned about as a depreciating asset, not technical debt.

pyromaker 3y ago

Ultimately, everything can be debt. If code is technical debt, a HR system or a process that you implement for the company at that particular point in time is also a debt (process debt? HR debt? debt nonetheless). If we are trying to deliver fast by expediting software development and taking shortcuts (technical debt), another department can also do something similar (quick, our HR process is slow and cumbersome, implement that HR system) - which would solve the particular issues for the business at that particular point in time, but may not the needs of the business later on. For software, the issue is that we believe we can introduce technical debts, that is, it is permissible to introduce and talk about technical debts. We wouldn't necessarily talk about implementing a new HR system often. We think writing a line of code is fast (and define what "fast" means) but it isn't.

dilyevsky 3y ago
Yeah “code is debt” seems to be popular meme among the “thought leaders” these days. Somehow their baroque processes (eg scrum), nonsense okrs and out of touch roadmaps are never debt - curious, right?

csours 3y ago

Any code _having_side_effects_ is technical debt. Pure functional code is innocent of any sin.

Nevermark 3y ago

Like quite a few people, to me the word "debt" doesn't naturally fit the problem of building code that will be harder to build on later. For me, "technical debt" would be shipping a product that immediately starts consuming technical resources not associated with value production. Like a rickety distributed database that needs manual labor to fix regular corruptions. That would seem analogous to debt. Not fully paying for what you have, resulting in continuous expense until the full payment is made. Writing code without care for future work is a different problem. It is the "bad foundation" problem shared by design, engineering, construction, book stacking, ... It has 1000 names: "Building on Sand", "Ticking Timebombs", "Bandaid Solutions", "Cutting Corners", "Short Term Fixes", "Playing Jenga", "Putting Lipstick on a Pig", "Haste Makes Waste", "Disaster Waiting to Happen", etc. Living code is a foundation. Shoddy foundations are dangerous to build on & costly to fix. Don't build shoddy foundations. No new terminology. You don't need a special strategy to explain this. Tell your CEO they can get their enormous features yesterday, they just need to sign off on a "shoddy foundation" exception. Informally by email is fine. You are ready to unleashed the troops from responsibility for future mishaps! All you need is that little written record! Then presto. The coders are standing by, breathless, ready to party! (And preparing their resumes.) ___ I love the essay's point that each feature adds assumptions, and assumptions add complexity. The rub of remodeling.

deleted 3y ago
[deleted]

jrochkind1 3y ago

Whether it is exactly the same concept as actual technical debt or not... This makes a lot of sense to me, and explains why you always think "I can do better than that monster", and it does always feel better at first, then then inevitably grows to feel like a monster where it's hard to make any changes. Especially when we are thinking about tools for developers, where developers are the users, libraries or web frameworks and such. Or even languages/ecosystems. A bunch of existing libraries/frameworks/platforms/ecosystems are a mess... surely we can do better! let's make a new thing! This explains why we are always hopping to the new thing, and always convinced the new thing is better... And the new thing is better and so much easier to work with, even though it doesn't have all the features the old thing did, but okay, we just need to keep building it out to encompass those features, using our much better sense of architecture and usability that we've proven we have because look how clean and simple and usable our first draft is! Now, there is such a thing as better or worse designed, as the OP admits, poorly implemented or beautifully implemented. But... comparing the new thing that only has the most basic features and seems really elegant to the old thing that covers all the edge cases... isn't actually a good comparison to tel you which is better implemented. That new thing is going to get cruftier when you cover the edges, _always_. And it shows that if you want to keep your thing feeling smooth and elegant and easy to work with.. you have to keep it as small as possible and resist all feature requests! > For a feature to add value to your product, it needs to be useful to users. Features can have a negative value when the technical debt they add to your product outweighs the value they add to it. Thinking of tools for developers where developers are the users... oh yeah it's true. > A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones I would describe that as limiting the number of "concepts" inside your code... and definitely applies to libraries/frameworks/tools for developers.

mjw_byrne 3y ago

Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom. Other examples that come to mind are "a complete rewrite is always a mistake" (no, it just has different risks/rewards), "if you are reading this part of the docs, you are trying to be too clever" (your API is too much for my puny brain is it?) and "all functions are APIs" (no, my two-line string quoting func is not an API, actually).

drewcoo 3y ago
> Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom. That seems to describe most of the programming clickbait here. I could swear there used to be more discussion of startups . . .

lnxg33k1 3y ago

I personally consider tech debt code that is hard to reason about, change, understand or not covered by unit test. I think the author just wanted to say something nonsense to go viral and get share/increase klout, but if the concept of code is symmetrical to the one of tech debt then the concept of tech debt is useless and we need something else to scope code that is hard to be worked on, and back to square one

resters 3y ago

I've ranted about this before. Everyone would like to have infinite time to write the best possible code and do everything right. In a business, particularly a time constrained or financially constrained one, the art of running the business entails deciding which corners to cut, what tradeoffs to make. Ironically, startups hire inexperienced people who often over-peform but sometimes underperform. A less risky approach would be to spend more (cash or equity) to hire people who are more of a sure thing. This could be called "execution debt" but it is accepted as visionary and associated with believing in people and being able to sense talent. Tech (architecture, code, devops, etc.) is no different. A highly skilled team will be able to make the right tradeoffs and cut the right corners. Tech debt is usually what people call something that appears in hindsight to have been the wrong corner to cut, however one would need a time machine to understand why the decision were made and what was competing for time/attention/resources and why. Engineering is the discipline of managing tradeoffs to create something. When working with a codebase that appears to be technical debt, the important thing to ask is what the options are today to address it. It may be beautifully written, clean code that uses the wrong abstractions, or it may be a solid architecture with some ugly code and style that needs to be addressed. Lots of people have biases due to their own preferences, but the thing to rememeber is that chances are the code was not made by someone with infinite time and perfect knowledge.

csbartus 3y ago

I think code / coding is overrated. Coding is debt. If we look at math / category theory we have functorial semantics, which means semantics (code) is auto-generated from syntax (design): https://www.algebraicjulia.org/assets/slides/nist-workshop-2022/main.html#/syntax-and-semantics https://www.algebraicjulia.org/assets/slides/nist-workshop-2... If we look in another direction we see LLMs which (will one day) generate code from design. If I look back those years in my career, I was always paid to write the same code all over again (lists, trees, tables, menus, user profiles, shopping carts, dashboards, heroes, apis, databases...), each time in a different context (given by the company) ... Such a waste of my time, and my employers money. Today at least in the MVP / startup scene coding is debt / obsolete. Startups all should go no-code. Later, after the startup phase, companies should focus _only_ on provably-correct, likely-correct understanding of their problem domain, on a design specific to their audience, and rapid iteration. The rest, coding, should be not no-code, but fully automatic yet provably correct (in the sense of total and partial correctness) I hope, and I wish coding will be eliminated. It's a big fun writing machine code in Assembly, algorithms in C/C++, full-stack web apps in Ruby on Rails, and user interfaces in React. But after a while it's not sustainable neither emotionally nor economically.

syndicatedjelly 3y ago
Do you really believe no-code applications mean there’s 0 code? You’re just relying on someone else’s code at that point, and have no ability to customize business logic.

hohu 3y ago

[flagged]

28304283409234 3y ago

The way I see it: Code is an abstraction of reality. Reality changes continuously. Therefore all code is techdebt. This is one of the reasons I oppose the “automate all the things” mantra.

wanderr 3y ago

This article seems to be more making the case that features are technical debt, sort of. And that's a valid point too. But it is so so easy for useless code to accumulate. At every company where I've worked as an engineer, I've ended up deleting lots and lots of code, far more than I ever write. Like, half of the codebase. Largely by applying static analysis to find code that clearly never worked, the confirming that it's not used (which is usually obvious or we'd be seeing crashes). Often times it's sad to see how long that code was maintained, with engineers wasting effort on migrating it as things changed, without ever questioning whether it's even needed.

rglover 3y ago

My standard for tech debt: - Unnecessary (too many or too heavy) dependencies that can be replaced by DIY code, or at least, smaller dependencies. - Implementations that stray from the standard set by the rest of the code in the project or actual guidelines written by a project leader (e.g., we don't use jsdoc anywhere but a developer randomly crams it in during a copypasta). - Over-complicated implementations that serve as an ego-pleasing flex for the author, but are impossible for even an experienced developer to reason through. - Implementations that were done to service a single customer in pursuit of short-term revenue, or, that were rushed through due to manager/stakeholder panic and inevitably collide with one of the above. --- Keep those three in check and you'll have limited issues. Edit: a good talk by Oliver Reichenstein (of iA Writer fame) that helped me years ago https://vimeo.com/102343006 https://vimeo.com/102343006 -- it's from a design perspective but has parallels to development. One quote of his that constantly pings in my head: "slow the fuck down."

deleted 3y ago
[deleted]

jongjong 3y ago

Code which solves a well defined problem with the absolute minimal amount of logic necessary is not technical debt. If a module is fully replaced later, it doesn't mean it was technical debt. Technical debt is characterized by its need to be refactored/modified in a way which is not backwards compatible. If a module can be substituted in its entirety with minimal changes which directly reflect requirement changes, then it wasn't technical debt. Good code is about setting up components in a hierarchy which allows you to adapt to requirement changes by substituting modules as opposed to refactoring those modules. Note that if you're adding features to an existing module, this does not count as a refactoring. Not if the module is backwards compatible with respect to its dependents. But of course when adding new features you want to stick to the minimalist philosophy so you need each module to have clear responsibilities.

RecycledEle 3y ago

I could argue that every mechanical thing will eventually fail, requiring a repair or a redesign and rebuilding. By that argument, every physical thing is technical debt. The reality is that some things we use are joys to use, and other things are problems that we have to keep patching. Some cars are fantastic, good-performing, reliable tools that get the jobs done. Others are constantly breaking down and just might make it, sputtering, over the next hill. I wonder how hard it would be to get major religions to endorse the concept that engineers who build useful, reliable, loved things are rewarded in the afterlife, while those who create things we all hate will be punished in the afterlife. Most religions already endorse the concept that we should serve our fellow man, and not cause needless suffering. Causing millions of hours of suffering for a paycheck is generally considered evil.

steveBK123 3y ago
It's not THAT hard to start a new religion these days. Plenty of prior art. I mean look at Mormons, Scientology or you know.. the EA people.

resonious 3y ago

> To avoid technical debt, don’t write code I think there's some truth to this, but code isn't always written by software engineers and isn't always executed by computers. You might end up with crazy Excel macros, and/or arcane people-processes with single points of failure. To "not write code" at all is probably to never move or do anything. Sure, you never lose if you never play, but you also never win.

deleted 3y ago

[deleted]

orourke 3y ago

All code may be technical debt but the interest rate can vary.

thomastjeffery 3y ago

All debt is credit. The only differences are who it is going to, and when. So what should our goals be? Less code means fewer features, which can make the UX path longer. More code means more features, which can make the UX path more confusing and strenuous. There is some kind of balance to be struck. The goal is for every UX path to be flexible and easy. Is that even possible? Can we have our cake and eat it, too? > Adding new assumptions increases debt There's the word I have been thinking about all week: "assumption". It's a tricky little bastard, and it really deserves more focus than it has any right to. You see, that word is the heart of our problem. It's not the amount of code you write, the features you add, the way you design your UI/UX, or even how flexible your user configuration is. It's the assumptions themselves. Assumptions are walls. Once an assumption has been added, it’s there to stay. It's easy to move an assumption around. Too easy! So easy that you move it without even knowing; but it is still there, lurking. No matter how hard you try to get rid of it, or to get around it, the assumption is guaranteed to stand in your path. Your only hope is that the assumption is there to guide you; its only other option is to guard you. So what can we do about it? We can not. No need to get rid of something you never made in the first place, right? But how do you make software that is unassuming? How can you make a tool without catering that tool to its intended work? How can you make a path without a destination? There's something we have gotten notoriously used to as software engineers: a finished product. After all, what else would an engineer strive to make? Finished products are things. Programs aren't. Programs are systems! Programs are stories. What kind of system is ever finished? I can only think of one: a dead one. At the end of its life, a system becomes cold, hard, sturdy, and complete; and the story meets its end. How did we ever convince ourselves that that is a worthy goal for software? I'll tell you how: we assumed. That assumption has been lurking at the heart of software design ever since, and all we can do now is move it. It's time to start over. --- This is where I answer my very first question: who? Who designs the software? Don't assume it's the engineer's job: it's the user's turn now. The next question is, when? When does the user design their software? When they use it. Any time before that would make them an engineer. What should our goals be? That's the best part! The user already knows her goal. That makes her precisely the right man for the job. --- If you followed any of my rambling so far, you are probably asking yourself the most important question, "What could this possibly look like?" That's a good question. I have something really close to a coherent idea. If you would like to hear about it, feel free to ask.

bue7jclotemp 3y ago

I only skimmed through the article so I might have missed this part, but did the author consider picking up a few books about domain design or search some examples how do others implement such event organizing systems? Because based on what I read, that seems to be his problem. He started implementing a system without having a good understanding of the domain's inherent problems and their common solutions. Not everything needs to be re-invented. Even though I have never worked in this domain (event organizing) but still I could from the top of my head pull out one such example where a team went into great detail how to design and implement an event organizing system which answers most of not all the problems that the author faced: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/jj591578(v=pandp.10)?redirectedfrom=MSDN https://learn.microsoft.com/en-us/previous-versions/msp-n-p/...

pluto_modadic 3y ago

without reading the article, the title is basically the thesis of every CIO/CTO who's drunk the koolaid and thinks moving to AWS somehow removes complexity. It trades complexity of code for grey problems and complex infrastructure/terraform/builds. Just a note - all extra AWS infrastructure over a simplistic minimum is technical debt.

kammygood 3y ago

Working code may not require maintenance, but dynamic context often requires adjustment. How do you think we balance the flexibility and inherent stability of well-functioning code?

5350-uiop-1130 3y ago

some devs really have their heads up their own arse we seem to believe we are craftsmen sculpting some work of art code is just shit you write, means to an end, be it closing a ticket or going home. soon deleted ("deprecated") and replaced with new trendier shit. > "we need to ensure we’re working on valuable features" yeah valuable features are what your boss's boss needs to get their promotion and/or bonus.

lngnmn2 3y ago

[dead]

hasoleju 3y ago

Reading this article reminded me that we need to think more about the whole lifecylce of a software product. I usually make the mistake developing a product thinking that it will exist forever and new features will be added continuously. The truth is: Almost every software product has a point in time where it is obsolete. (Maybe except some really big enterprise solutions or OS libraries). I see these phases for many small software product: 1. Development Phase (Features are added continuously) 2. Maintenance Phase (No features are added, compatibility is ensured and bugs get fixed) 3. End of Support Phase (Basically no development happens for the product any more.) The second phase "Maintenance Phase" is usually much longer than the development phase for a successful product. The cost during this phase heavily depends on the amount of features, that were added in the first phase. So be careful what you develop, you need to maintain it for a long period of time and at one point in time it will be obsolete anyways.

015a 3y ago

- "Technical debt" (usefully) divorces the idea of implementation velocity from business outcomes. You have a thirty year old system written in a language barely anyone understands anymore; but, its still generating profit for the business. This is technical debt; its "useful" to separate from business outcomes because it enables you to consider it as one factor, among many, to overall business outcomes, rather than prematurely co-mingling the two ideas. - Similar to the generality "all code is technical debt" I'll make one of my own: "All technical debt is abstraction assumption failure". You've got an abstraction; you assume it behaves some way; it doesn't. You've got an abstraction; you need to add new functionality behind that abstraction; you assumed this is a good place or a good way to add this functionality; it isn't. The vast majority of technical debt is just this. There may be a couple more categories like "we can't hire people to work in this language" or even something like system performance, but the vast majority of technical debt is a failure of understanding of some abstraction. - That previous statement does not assert that this is an invalid way of viewing technical debt. "Understanding" the code is literally the most important job of software engineers; less "engineer" and more "museum keeper" sometimes. I've never liked the term "bad abstraction" because it shifts the responsibility of being understood to the abstraction, and not the engineer. It encourages "code bad, rewrite" mentality. Sometimes that is the best course, but I think its always a bad idea to tackle that without understanding the abstraction, and if you understand the abstraction then you probably wouldn't be calling for a rewrite because its "bad"; you'll be calling it for more specific reasons. - Unilaterally classifying all code as technical debt isn't just wrong; its asinine. "Technical debt" is a useful way of thinking about some code; if you remove that from your lexicon, you may start believing that all code either is or isn't technical debt. If all code is technical debt, your ability to think about the quality of code holistically, with its nuance, is reduced durastically. If you think no code is technical debt, you'll inevitably walk down the path of hyper-engineering perfect giga-systems that, even if they work flawlessly and satisfy all business needs, took way too long to build, cost way too much to run, and inevitably still confuse your replacement in six years.

kugurerdem 3y ago

I just read the essay and found the examples given interesting. I certainly believe there are valuable lessons to be learned from them. However, I don't think the content fully supports the claim made in the title. It seems that the author's focus is on how things can become needlessly complicated, even when trying to implement a seemingly simple feature. However, citing only a few examples is not sufficient evidence. Could we not also consider instances where writing additional code could actually help reducing long-term technical costs? Aside from this, I found the following points interesting: > A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones. > Even when it becomes apparent after the fact that the feature isn’t performing as well as we anticipated, the typical approach is to do nothing. Part of this is the sunk cost fallacy. Often there is the hope that even if the feature isn’t used today, it will be in the future. But there’s also a legitimate reason for doing nothing. Removing a feature also has a cost, both in the development effort needed to cleanly remove it, and in potentially upsetting customers. So once a feature is added to a product, it is almost always there to stay.