11 ms·

Isn't it more useful to think of code not as an asset but as a liability? As in, instead of code being "produced", you "spend" lines of code when you solve a pr

Isn't it more useful to think of code not as an asset but as a liability? As in, instead of code being "produced", you "spend" lines of code when you solve a problem, i.e. "Getting X amount of business value cost us Y lines of code"? As for the phrase "technical debt": While I like the metaphor, in my experience, most people use it as a synonym for "bad code", so I recommend making sure everyone agrees on the same definition before using it.

chii 3y ago
> i.e. "Getting X amount of business value cost us Y lines of code"? it's not the lines of code that costs, but time. It may be OK to use lines of code as proxy for time spent - but that sort of assumes that each line took similar amounts of time to write. I am not sure that's really the case, but even if it is, hiring somebody more competent will get more lines in less time! Therefore, why not just measure the time directly?
- hamandcheese 3y ago
  It costs time to write the code, yes, but the liability of that code existing will cost an additional, unknown amount at some indeterminate time in the future.
  - flkenosad 3y ago
    Or that code existing will bring an additional, unknown at some indeterminate time in the future, cost savings when you go to implement a nearly identical feature and you find out you won't be needing to start from scratch as you already have all this well tested, named and organized code to pull from as you craft a new solution. Your perspective just needs a shift from negative to positive.
    - hamandcheese 3y ago
      I see that happen maybe one or two times a year, at most. Meanwhile I debug broken code literally every day.
- layer8 3y ago
  The cost lies in the existing code’s implication on future maintenance and changes. You can’t measure that future time cost until it’s too late.
munksbeer 3y ago
> Isn't it more useful to think of code not as an asset but as a liability? In my view yes. I often find it frustrating how much code people will generate to solve a problem that occurs extremely rarely and the consequences are not severe anyway. All of that code is now a liability and must continue to cope with any future changes to the system. No matter how elegantly you think you write code, the easiest code to change is the code that doesn't exist at all.
- rijx 3y ago
  That reminds me of SpaceX saying the most reliable part is no part at all!
  - nativeit 3y ago
    Bumper sticker philosophies tend to have limited real-world utility.
    - atlanticaccent 3y ago
      I'm going to put this on a bumper sticker
    - rightbyte 3y ago
      Especially among programmers, who takes rule of thumbs way to literally.
- flkenosad 3y ago
  Is it the sheer volume of code that bothers you or is it poorly organized in some way?
  - sam_bristow 3y ago
    One of my key metrics when adding code to a system is how easy it is to rip out later. It's served me well so far.
AnimalMuppet 3y ago
The functionality is an asset; the lines of code to produce the functionality can be considered a liability. But... if you do the same thing in fewer lines, by writing terser code, that may be harder to understand and therefore maintain, and that's also a liability - maybe more of a liability. If lines of code are a liability, some lines of code are much more so, because they are hard to understand, overengineered, badly designed, brittle, or probably several other reasons. Code is a liability; bad code is far more so. Get the most assets - functionality - with the least cost - lines of code plus "things that make code more expensive".
- mkoubaa 3y ago
  Code is a liability does not imply more lines of code is more liability. You can owe 1000 dollars to one neighbor and 1 dollar each to 100 neighbors. The number of neighbors you owe money to is not the right metric for how much liability you have. But it's still wrong to say that owing 13 cents to your best friend is not a liability
- hamandcheese 3y ago
  Think of lines of code as parts in a mechanical assembly. Not all parts are the same, obviously. But a design with fewer parts will probably be cheaper and more reliable than a design with more parts.
christophilus 3y ago
> lines of code If you measure cost by lines of code, you'll get programs like this: https://www.youtube.com/watch?v=a9xAKttWgP4&t=402s https://www.youtube.com/watch?v=a9xAKttWgP4&t=402s
PH95VuimJjqBqy 3y ago
one wonders when code will be thought of as ... code.
reactordev 3y ago
The problem is in the mis-characterization that lines of code somehow equal better. Lines of Code(tm) is nothing but a measurement of how much effort it was to do, not how complex or how valuable. Just throwing that out there for the Erlang folks who produce very little lines of code but tremendous business value.
- JohnFen 3y ago
  > Lines of Code(tm) is nothing but a measurement of how much effort it was to do It's not even that. There are certainly low-effort projects that take a lot of lines of code, and there are high-effort projects that take few.
globular-toast 3y ago
It's both! I like the garden analogy. We want a garden to be pleasant and nice, but we'd also like it to be easy to maintain. A successful garden is about finding that balance between plants that mostly take care of themselves and a few unique things that might take a bit more care but make the garden special. Daffodils require no maintenance at all but they only appear briefly and everyone has them. A garden full of daffodils isn't special. Software is there to be useful, to provide some business value. But it can't all be boring old daffodils. There has to be something your business is doing that is different from any other business, otherwise why are you even writing software? So, yes, there is a liability in the sense that you need to tend to whatever garden you decide to grow, but there is a definite asset in the sense that it is delivering value to the business. It's all about trying to manage the size of the liability given the size of the asset.
bayindirh 3y ago
> Isn't it more useful to think of code not as an asset but as a liability? Yes. I love to code and I love that metaphor. One day while browsing Reddit/TIFU, a post jumped at me: "TIFU by creating and releasing a Reddit plugin for Firefox/Chrome, because I'll have to maintain it for my whole life." It's so funny, true and enlightening at the same time. > most people use it as a synonym for "bad code" For me, "tech debt" is the suboptimal solution you shoehorned in the last minute because you don't have any alternative course at that moment (time, brain fog, etc.), which can boil to bad code, in general. Presence of code itself is not the technical debt itself.
- ruszki 3y ago
  As I became senior, I realised that you always have that alternative course. It’s definitely a skill to avoid technical debt, even when you don’t have the knowledge at a given time. For example, if you code something in Spring and it seems that something is against the “Spring mindset”, then it’s almost 100% that you introduce technical debt. There was only one single time when Spring utterly broke its own methodologies, and it was needed for my day-to-day job (ie Spring Security with multiple providers). Looking after such cases is way more beneficial, than that one case when it took me a deep inspection of Spring to figure out, that there is really no nice solution. Nowadays it’s even easier with LLMs, they can help you point to the right direction, then it’s easy to validate with some search engines.
butterisgood 3y ago
Yes and no. Sometimes people try to write a short implementation to be clever (code golf) and the result is another liability. Code should 1. Function as needed 2. Be clear to read and understand 3. Perform well enough Possibly even in the order listed. Performance is the trickiest one of course. Sometimes it's not negotiable and messes with #2. But one should always benchmark and profile to see what needs to actually be done before sacrificing clarity and cleanness.
- deleted 3y ago
  [deleted]
williamcotton 3y ago
Software is a depreciating asset which has maintenance costs. Rushing out poorly architected and implemented software systems means that the asset depreciates at a much greater rate than otherwise, just like a crappy vacuum cleaner. Since we’re mainly in the business of building a single self-updating vacuum cleaner per business we’re fully capable of taking a cheap design and a cheap implementation and making it better over time… at a cost!
- williamcotton 3y ago
  For the accounting nerds out there: We've got an asset account, and a couple of expense accounts, depreciation and maintenance. So the depreciation transactions are from some kind of assessment of the asset's value over the full lifetime (read: will anyone still use this Android app in 10 years?) while the maintenance transactions are from the actual costs to keep the asset operational. Depreciation isn't really about quality or value, rather lifetime expectation. As a consumer buying a cheap vacuum cleaner you are knowingly buying a product that depreciates at a higher rate. You can maintain that vacuum cleaner for a lifetime if you wish but those are separate expenses. So in terms of software, if you should be rushing something out the door in order to try and find product-market fit, do so with the knowledge that you are creating an asset with a shortened expected lifetime, ie, that depreciates at a higher rate. As you transition from prototype to a more robust system you adjust the rate the depreciation to match. You can choose to keep maintaining the prototype but the costs of doing so are probably more than the enhancement costs that are offset by increased capitalization. But again, do you expect anyone to be using your Android app in 10 years? The accounting practices in software are much different than thinking about a widget factory so I do get the sense we could using some innovation in the field.
hmottestad 3y ago
Equating technical debt to bad code does seem fairly common, but I think that that stems from what people think of as bad code. I feel that technical debt is commonly references in connection to writing some quick and dirty code that solves the immediate problem with little regard for the future. Code that is quick and dirty may feel like bad code, but it doesn't have to be. If your fix is good code though, doesn't that kinda mean that it's not quick and dirty and that it doesn't add any technical debt to a project? Architectural decisions may very well result in technical debt, but an architectural decision to go with a vertically scaling solution doesn't have to be a bad decision or bad code. It's only really a problem once you get enough users that you need to start scaling horizontally. At that point though it would very much be considered a technical debt since it was originally trading development time with future scalability.
- layer8 3y ago
  Technical debt is the difference between the actual code and how you would ideally write it with today’s knowledge and no time constraints. By that definition, bad code is a subset of technical debt, as you presumably wouldn’t write that bad code today unless maybe under time pressure. The other kind of technical debt is when you have in principle good code but the assumptions, requirements or external conditions have changed, and thus you wouldn’t write it that way today. Your second paragraph matches that case.
  - hmottestad 3y ago
    That’s a good way of putting it :)
bregma 3y ago
> Isn't it more useful to think of code not as an asset but as a liability? In the same way a factory should be accounted for as a liability. You spend to build the factory, then it depreciates to zero value, so all you've done is lose your original capital. It's not possible to ever get ahead. That's just a very bad understanding of basic accounting. Code is a capital asset. Getting value from it over the long term requires maintenance and repairs, improvements and replacements. "Technical debt" is a complete misnomer in terms of accounting principles.
chaps 3y ago
I think of "technical debt" in the same way that I do construction scaffolding: it's essential, but if you focus only on your scaffolding then you won't build the building you're trying to build. If you never take the scaffolding down, then it becomes part of the whole project. If your scaffolding is poorly done, then your building (program) will crash or will take forever to build. Lots of potential to build proper scaffolding that vastly reduces the cost of a project. Can't be done without it, but it can definitely get in the way.
olejorgenb 3y ago
So the analogy become: Capabilities/functionality is "assets", code is "liability"? (or maybe "perfect" code is closer to equity) Just as "real" assets depreciate, capabilities/functionality can as well. Require both maintenance and has a operation cost (also beyond hardware cost).
brlewis 3y ago
>Isn't it more useful to think of code not as an asset but as a liability? No, it is not. For consistency, you'd have to start thinking of everything you own as a liability, and only use "asset" to refer to a problem solved by something you own. This would be confusing to everyone you talk with about assets and liabilities. On a day when you didn't drive anywhere, you'd point at your car and say "I got no assets from this liability today." (There would be some truth in that statement, but your listeners would definitely be confused.) EDIT: I should add, I believe Dijkstra was using hyperbole to make a point with the "lines spent" part of https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
- karmakaze 3y ago
  > The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. It doesn't sound like hyperbole to me. "lines of code" without context is a liability, more is not better. The correct side of the ledger is being stated as liability, if we're to consider lines of code at all.
  - brlewis 3y ago
    If you were advising an airplane manufacturer where production was tracked by weight, you might admonish them that they were putting airplane parts on the wrong side of the ledger. But later, after they changed their practices to stop encouraging the production of useless parts, the remaining airplane parts would be counted as assets, not liabilities. You, and they, would look back on the ledger comment as hyperbole.
sorokod 3y ago
Teeth are liability in a similar way. Once we get the permanent set, they need to be maintained in various expensive and painful ways. On the plus side, they do provide value. Software rots too, if for no other reason then due to Lehman's 1st law [1]. Difference is that with code we have more choices. [1] https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_ev...
karmakaze 3y ago
All bad code is tech debt, but not in the sense that it was consciously chosen. We usually only talk about the cases that currently limit progress/quality. The interest rate varies on where that bad code lives and how cumbersome it is to work with. If it's in an area with frequent changes that are incidentally difficult to implement, then it's high on the tech debt list.
rightbyte 3y ago
> cost us Y lines of code I don't like these rules of thumb that when taking literally screws us. Some manager is going to want to minimize locs now. Code suckiness per feature is a qualitative measurement. I don't think there should be any allusion of absolute numerical scores for that property.
- karmakaze 3y ago
  This is where the distinction between essential/intrinsic and incidental/accidental complexity comes in. Any code in the solution but not required in the solution is excess. Usually though we don't measure this in lines, but rather in cognitive load (which can come in any number of inappropriate choices).
  - rightbyte 3y ago
    Ye sure. I know good code when I see it. The scale is very fuzzy, and others might disagree with my taste and we both are right. "Cognitive load" has to be normalized by "stuff done". I mean the unit is something like: (stuff done by app) / (code stuff) where 'code stuff' is really really fuzzy. I mean dependencies count into that measure, even though they are zero loc written by you. Etc.
    - karmakaze 3y ago
      I agree that it's a fuzzy scale. What I usually pick out isn't the amounts of stuff but how much of it either goes against the grain or piles on abstractions without a simplifying payoff (reduced cognitive load). Basically it comes down to picking the right set of abstractions (choosing your chunks/seams) and good naming since the factors which are being separated aren't vague. Few things are 50/50--those cases rather tend to be "no one really knows yet". My phrasing is "you'll know good code when it's shown to you" where "you" is myself for my own work.
- _v7gu 3y ago
  That’s the kind of opportunity I’m looking for to introduce array languages to the codebase :^)
ActionHank 3y ago
Having worked on several large and complex codebases there is a very distinct difference in how the teams working on them saw the code based on whether or not it was unit tested. The teams who were fastidious with their unit and automation testing saw the code as an asset. It was generally reliable and not risky to change. The teams with little to no unit or automation testing saw their code as an ever growing liability as complexity increased ultimately culminating in the great rewrite every few years.
- JohnFen 3y ago
  > ultimately culminating in the great rewrite every few years. Damn! I'm fortunate to have never experienced this. In my entire career, only once have I seen a project suffer from a complete rewrite, even with projects that did no unit testing.
flkenosad 3y ago
I think I see the disconnect. People who can read code, don't see it as a liability, but an extremely valuable asset. People who can't read code, however, only see it as a liability. The value to them is in the compiled binary because that is what they know how to interface with.
taeric 3y ago
The biggest mind bend you can give yourself here is that the difference between asset and liability is largely perspective only. Consider your deposit in a bank. It is, by definition an asset. However, it is also, by definition, recorded as a liability for the bank. They both lend against it, as an asset, and they are required to pay it back, as a liability. That is, yes. Code is a liability. This does not keep it from being an asset, as well.
JohnFen 3y ago
> Isn't it more useful to think of code not as an asset but as a liability? If we're thinking in these terms, code is clearly both an asset and a liability. I don't think of code in those terms at all, though. I think of code in terms of change. Changing code brings risk and expense, and that's why the rule of thumb is to never touch an existing line of code without careful consideration and a very good reason to do so.
javier_e06 3y ago
The first time I heard the time 'technical debt' was during a discussion on software related activities to fixing something that is not a bug or a feature which are usually the two main categories that the product owner cares. You meet your deadlines and the customer is elated with the software/product, then 'technical debt' is the whatever bucket.

chii 3y ago

> i.e. "Getting X amount of business value cost us Y lines of code"? it's not the lines of code that costs, but time. It may be OK to use lines of code as proxy for time spent - but that sort of assumes that each line took similar amounts of time to write. I am not sure that's really the case, but even if it is, hiring somebody more competent will get more lines in less time! Therefore, why not just measure the time directly?

hamandcheese 3y ago
It costs time to write the code, yes, but the liability of that code existing will cost an additional, unknown amount at some indeterminate time in the future.
- flkenosad 3y ago
  Or that code existing will bring an additional, unknown at some indeterminate time in the future, cost savings when you go to implement a nearly identical feature and you find out you won't be needing to start from scratch as you already have all this well tested, named and organized code to pull from as you craft a new solution. Your perspective just needs a shift from negative to positive.
  - hamandcheese 3y ago
    I see that happen maybe one or two times a year, at most. Meanwhile I debug broken code literally every day.
layer8 3y ago
The cost lies in the existing code’s implication on future maintenance and changes. You can’t measure that future time cost until it’s too late.

munksbeer 3y ago

> Isn't it more useful to think of code not as an asset but as a liability? In my view yes. I often find it frustrating how much code people will generate to solve a problem that occurs extremely rarely and the consequences are not severe anyway. All of that code is now a liability and must continue to cope with any future changes to the system. No matter how elegantly you think you write code, the easiest code to change is the code that doesn't exist at all.

rijx 3y ago
That reminds me of SpaceX saying the most reliable part is no part at all!
- nativeit 3y ago
  Bumper sticker philosophies tend to have limited real-world utility.
  - atlanticaccent 3y ago
    I'm going to put this on a bumper sticker
  - rightbyte 3y ago
    Especially among programmers, who takes rule of thumbs way to literally.
flkenosad 3y ago
Is it the sheer volume of code that bothers you or is it poorly organized in some way?
- sam_bristow 3y ago
  One of my key metrics when adding code to a system is how easy it is to rip out later. It's served me well so far.

AnimalMuppet 3y ago

The functionality is an asset; the lines of code to produce the functionality can be considered a liability. But... if you do the same thing in fewer lines, by writing terser code, that may be harder to understand and therefore maintain, and that's also a liability - maybe more of a liability. If lines of code are a liability, some lines of code are much more so, because they are hard to understand, overengineered, badly designed, brittle, or probably several other reasons. Code is a liability; bad code is far more so. Get the most assets - functionality - with the least cost - lines of code plus "things that make code more expensive".

mkoubaa 3y ago
Code is a liability does not imply more lines of code is more liability. You can owe 1000 dollars to one neighbor and 1 dollar each to 100 neighbors. The number of neighbors you owe money to is not the right metric for how much liability you have. But it's still wrong to say that owing 13 cents to your best friend is not a liability
hamandcheese 3y ago
Think of lines of code as parts in a mechanical assembly. Not all parts are the same, obviously. But a design with fewer parts will probably be cheaper and more reliable than a design with more parts.

christophilus 3y ago

> lines of code If you measure cost by lines of code, you'll get programs like this: https://www.youtube.com/watch?v=a9xAKttWgP4&t=402s https://www.youtube.com/watch?v=a9xAKttWgP4&t=402s

PH95VuimJjqBqy 3y ago

one wonders when code will be thought of as ... code.

reactordev 3y ago

The problem is in the mis-characterization that lines of code somehow equal better. Lines of Code(tm) is nothing but a measurement of how much effort it was to do, not how complex or how valuable. Just throwing that out there for the Erlang folks who produce very little lines of code but tremendous business value.

JohnFen 3y ago
> Lines of Code(tm) is nothing but a measurement of how much effort it was to do It's not even that. There are certainly low-effort projects that take a lot of lines of code, and there are high-effort projects that take few.

globular-toast 3y ago

It's both! I like the garden analogy. We want a garden to be pleasant and nice, but we'd also like it to be easy to maintain. A successful garden is about finding that balance between plants that mostly take care of themselves and a few unique things that might take a bit more care but make the garden special. Daffodils require no maintenance at all but they only appear briefly and everyone has them. A garden full of daffodils isn't special. Software is there to be useful, to provide some business value. But it can't all be boring old daffodils. There has to be something your business is doing that is different from any other business, otherwise why are you even writing software? So, yes, there is a liability in the sense that you need to tend to whatever garden you decide to grow, but there is a definite asset in the sense that it is delivering value to the business. It's all about trying to manage the size of the liability given the size of the asset.

bayindirh 3y ago

> Isn't it more useful to think of code not as an asset but as a liability? Yes. I love to code and I love that metaphor. One day while browsing Reddit/TIFU, a post jumped at me: "TIFU by creating and releasing a Reddit plugin for Firefox/Chrome, because I'll have to maintain it for my whole life." It's so funny, true and enlightening at the same time. > most people use it as a synonym for "bad code" For me, "tech debt" is the suboptimal solution you shoehorned in the last minute because you don't have any alternative course at that moment (time, brain fog, etc.), which can boil to bad code, in general. Presence of code itself is not the technical debt itself.

ruszki 3y ago
As I became senior, I realised that you always have that alternative course. It’s definitely a skill to avoid technical debt, even when you don’t have the knowledge at a given time. For example, if you code something in Spring and it seems that something is against the “Spring mindset”, then it’s almost 100% that you introduce technical debt. There was only one single time when Spring utterly broke its own methodologies, and it was needed for my day-to-day job (ie Spring Security with multiple providers). Looking after such cases is way more beneficial, than that one case when it took me a deep inspection of Spring to figure out, that there is really no nice solution. Nowadays it’s even easier with LLMs, they can help you point to the right direction, then it’s easy to validate with some search engines.

butterisgood 3y ago

Yes and no. Sometimes people try to write a short implementation to be clever (code golf) and the result is another liability. Code should 1. Function as needed 2. Be clear to read and understand 3. Perform well enough Possibly even in the order listed. Performance is the trickiest one of course. Sometimes it's not negotiable and messes with #2. But one should always benchmark and profile to see what needs to actually be done before sacrificing clarity and cleanness.

deleted 3y ago
[deleted]

williamcotton 3y ago

Software is a depreciating asset which has maintenance costs. Rushing out poorly architected and implemented software systems means that the asset depreciates at a much greater rate than otherwise, just like a crappy vacuum cleaner. Since we’re mainly in the business of building a single self-updating vacuum cleaner per business we’re fully capable of taking a cheap design and a cheap implementation and making it better over time… at a cost!

williamcotton 3y ago
For the accounting nerds out there: We've got an asset account, and a couple of expense accounts, depreciation and maintenance. So the depreciation transactions are from some kind of assessment of the asset's value over the full lifetime (read: will anyone still use this Android app in 10 years?) while the maintenance transactions are from the actual costs to keep the asset operational. Depreciation isn't really about quality or value, rather lifetime expectation. As a consumer buying a cheap vacuum cleaner you are knowingly buying a product that depreciates at a higher rate. You can maintain that vacuum cleaner for a lifetime if you wish but those are separate expenses. So in terms of software, if you should be rushing something out the door in order to try and find product-market fit, do so with the knowledge that you are creating an asset with a shortened expected lifetime, ie, that depreciates at a higher rate. As you transition from prototype to a more robust system you adjust the rate the depreciation to match. You can choose to keep maintaining the prototype but the costs of doing so are probably more than the enhancement costs that are offset by increased capitalization. But again, do you expect anyone to be using your Android app in 10 years? The accounting practices in software are much different than thinking about a widget factory so I do get the sense we could using some innovation in the field.

hmottestad 3y ago

Equating technical debt to bad code does seem fairly common, but I think that that stems from what people think of as bad code. I feel that technical debt is commonly references in connection to writing some quick and dirty code that solves the immediate problem with little regard for the future. Code that is quick and dirty may feel like bad code, but it doesn't have to be. If your fix is good code though, doesn't that kinda mean that it's not quick and dirty and that it doesn't add any technical debt to a project? Architectural decisions may very well result in technical debt, but an architectural decision to go with a vertically scaling solution doesn't have to be a bad decision or bad code. It's only really a problem once you get enough users that you need to start scaling horizontally. At that point though it would very much be considered a technical debt since it was originally trading development time with future scalability.

layer8 3y ago
Technical debt is the difference between the actual code and how you would ideally write it with today’s knowledge and no time constraints. By that definition, bad code is a subset of technical debt, as you presumably wouldn’t write that bad code today unless maybe under time pressure. The other kind of technical debt is when you have in principle good code but the assumptions, requirements or external conditions have changed, and thus you wouldn’t write it that way today. Your second paragraph matches that case.
- hmottestad 3y ago
  That’s a good way of putting it :)

bregma 3y ago

> Isn't it more useful to think of code not as an asset but as a liability? In the same way a factory should be accounted for as a liability. You spend to build the factory, then it depreciates to zero value, so all you've done is lose your original capital. It's not possible to ever get ahead. That's just a very bad understanding of basic accounting. Code is a capital asset. Getting value from it over the long term requires maintenance and repairs, improvements and replacements. "Technical debt" is a complete misnomer in terms of accounting principles.

chaps 3y ago

I think of "technical debt" in the same way that I do construction scaffolding: it's essential, but if you focus only on your scaffolding then you won't build the building you're trying to build. If you never take the scaffolding down, then it becomes part of the whole project. If your scaffolding is poorly done, then your building (program) will crash or will take forever to build. Lots of potential to build proper scaffolding that vastly reduces the cost of a project. Can't be done without it, but it can definitely get in the way.

olejorgenb 3y ago

So the analogy become: Capabilities/functionality is "assets", code is "liability"? (or maybe "perfect" code is closer to equity) Just as "real" assets depreciate, capabilities/functionality can as well. Require both maintenance and has a operation cost (also beyond hardware cost).

brlewis 3y ago

>Isn't it more useful to think of code not as an asset but as a liability? No, it is not. For consistency, you'd have to start thinking of everything you own as a liability, and only use "asset" to refer to a problem solved by something you own. This would be confusing to everyone you talk with about assets and liabilities. On a day when you didn't drive anywhere, you'd point at your car and say "I got no assets from this liability today." (There would be some truth in that statement, but your listeners would definitely be confused.) EDIT: I should add, I believe Dijkstra was using hyperbole to make a point with the "lines spent" part of https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

karmakaze 3y ago
> The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. It doesn't sound like hyperbole to me. "lines of code" without context is a liability, more is not better. The correct side of the ledger is being stated as liability, if we're to consider lines of code at all.
- brlewis 3y ago
  If you were advising an airplane manufacturer where production was tracked by weight, you might admonish them that they were putting airplane parts on the wrong side of the ledger. But later, after they changed their practices to stop encouraging the production of useless parts, the remaining airplane parts would be counted as assets, not liabilities. You, and they, would look back on the ledger comment as hyperbole.

sorokod 3y ago

Teeth are liability in a similar way. Once we get the permanent set, they need to be maintained in various expensive and painful ways. On the plus side, they do provide value. Software rots too, if for no other reason then due to Lehman's 1st law [1]. Difference is that with code we have more choices. [1] https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_ev...

karmakaze 3y ago

All bad code is tech debt, but not in the sense that it was consciously chosen. We usually only talk about the cases that currently limit progress/quality. The interest rate varies on where that bad code lives and how cumbersome it is to work with. If it's in an area with frequent changes that are incidentally difficult to implement, then it's high on the tech debt list.

rightbyte 3y ago

> cost us Y lines of code I don't like these rules of thumb that when taking literally screws us. Some manager is going to want to minimize locs now. Code suckiness per feature is a qualitative measurement. I don't think there should be any allusion of absolute numerical scores for that property.

karmakaze 3y ago
This is where the distinction between essential/intrinsic and incidental/accidental complexity comes in. Any code in the solution but not required in the solution is excess. Usually though we don't measure this in lines, but rather in cognitive load (which can come in any number of inappropriate choices).
- rightbyte 3y ago
  Ye sure. I know good code when I see it. The scale is very fuzzy, and others might disagree with my taste and we both are right. "Cognitive load" has to be normalized by "stuff done". I mean the unit is something like: (stuff done by app) / (code stuff) where 'code stuff' is really really fuzzy. I mean dependencies count into that measure, even though they are zero loc written by you. Etc.
  - karmakaze 3y ago
    I agree that it's a fuzzy scale. What I usually pick out isn't the amounts of stuff but how much of it either goes against the grain or piles on abstractions without a simplifying payoff (reduced cognitive load). Basically it comes down to picking the right set of abstractions (choosing your chunks/seams) and good naming since the factors which are being separated aren't vague. Few things are 50/50--those cases rather tend to be "no one really knows yet". My phrasing is "you'll know good code when it's shown to you" where "you" is myself for my own work.
_v7gu 3y ago
That’s the kind of opportunity I’m looking for to introduce array languages to the codebase :^)

ActionHank 3y ago

Having worked on several large and complex codebases there is a very distinct difference in how the teams working on them saw the code based on whether or not it was unit tested. The teams who were fastidious with their unit and automation testing saw the code as an asset. It was generally reliable and not risky to change. The teams with little to no unit or automation testing saw their code as an ever growing liability as complexity increased ultimately culminating in the great rewrite every few years.

JohnFen 3y ago
> ultimately culminating in the great rewrite every few years. Damn! I'm fortunate to have never experienced this. In my entire career, only once have I seen a project suffer from a complete rewrite, even with projects that did no unit testing.

flkenosad 3y ago

I think I see the disconnect. People who can read code, don't see it as a liability, but an extremely valuable asset. People who can't read code, however, only see it as a liability. The value to them is in the compiled binary because that is what they know how to interface with.

taeric 3y ago

The biggest mind bend you can give yourself here is that the difference between asset and liability is largely perspective only. Consider your deposit in a bank. It is, by definition an asset. However, it is also, by definition, recorded as a liability for the bank. They both lend against it, as an asset, and they are required to pay it back, as a liability. That is, yes. Code is a liability. This does not keep it from being an asset, as well.

JohnFen 3y ago

> Isn't it more useful to think of code not as an asset but as a liability? If we're thinking in these terms, code is clearly both an asset and a liability. I don't think of code in those terms at all, though. I think of code in terms of change. Changing code brings risk and expense, and that's why the rule of thumb is to never touch an existing line of code without careful consideration and a very good reason to do so.

javier_e06 3y ago

The first time I heard the time 'technical debt' was during a discussion on software related activities to fixing something that is not a bug or a feature which are usually the two main categories that the product owner cares. You meet your deadlines and the customer is elated with the software/product, then 'technical debt' is the whatever bucket.