5 ms·

This strikes me as some sort of Orwellian contortion. It really is a matter of your point of view. Insofar as code is correlated with functionality (and it is a

This strikes me as some sort of Orwellian contortion. It really is a matter of your point of view. Insofar as code is correlated with functionality (and it is at least to some degree), code can be viewed as an asset. In addition, code can be sold for cash, and this makes it an asset from the strictly financial point of view. It may have maintenance costs associated with it -- and these certainly need to be taken into account -- but that is not the same as being a liability.

SonicSoul 11y ago
Unless you've heard of places paying per line of code you seem to have missed the point of code being a liability. It's what it does that's valuable, not the volume of it
- jsprogrammer 11y ago
  Code can only act through its volume. The fantasy of codeless functionality that is being propagated here is exactly that. Functionality only exists because of code. The two cannot be fully separated from each other in the way that some in this thread are implying.
  - Xixi 11y ago
    An airliner certainly is an asset (at least in the hand of a well run airline), but the lighter the frame the better: a lighter frame needs less fuel to fly, hence more money remains in the bank at the end. But without frame there's no plane, so you need some of it, just as little as feasible. It's the same for code: a running program can certainly be a huge asset, but the less code you have the lower the maintenance cost. The concept is just harder to grasp than paying a kerosene bill each time a plane takes off...
    - riskable 11y ago
      I totally agree with your sentiment but I do want to add that adding code can be useful and make it better even if you're not adding functionality. For example, while it may be "cool" to turn a straightforward loop into a complicated one-liner (which would be "removing code while retaining functionality") that wouldn't necessarily be a good thing. The longer, more straightforward code is likely to have a lower maintenance cost.
    - xj9 11y ago
      I think the issue is that you are conflating lines of code with complexity. I certainly think it is better to write short programs, but it is wrong to think that less LOC == better code. The most valuable kind of software IMO is the kind you don't think about because it never fails, and at that point your LOC measurements are irrelevant.
- yshklarov 11y ago
  I did not mean to imply that the volume of code was directly tied to its value. I understand that value stems from functionality and not from quantity of code. But functionality does stem from code, as jsprogrammer said. If your code does X, and X is valuable, then the code is valuable -- I don't see what's wrong with this line of reasoning.
- dragonwriter 11y ago
  that's no more true of code than of land or anything else; thats just the fundamental idea of what value of a thing is, what you can use it to do or get. So it's odd to say that value doesn't lie in code but in the functionality that code provides, without also saying that of everything else, and, to say it at all -- of code or more generally -- is just to use language in an atypical way (and,if its just of code, an inconsistent way as well.)
  - marrs 11y ago
    But the point is that you pay for the code in order to gain the functionality. Code is an expense. The application is the asset. If you want to add a feature to the application then you have to pay for it in developer time. The larger and more complicated the supporting code, the more time you will have to pay for.
    - dragonwriter 11y ago
      I pay for X because X provides valuable functionality is generally true of productive assets. And it's not unusual for productive assets to depreciate or have maintenance expenses that must be born to maintain their functionality -- usually both. So, while those are all valid observations about code, they don't make it a liability, they make it a fairly bog-standard productive asset.
      - msandford 11y ago
        So given the choice between having feature X written in 1,000 lines or 1,000,000 lines of code, you don't care which is which? I find that hard to believe. If code truly was an asset, it wouldn't really matter if it was 1000 lines or a 1,000,000 lines as they're functionally equivalent right? Or perhaps the million line program would be worth more, wouldn't it? Code is an asset. But the amount of code directly influences the maintenance cost, doesn't it? And maintenance cost is a liability, no? It's something that you're obligated to pay if you want to keep the asset productive. And an obligation to pay is a debt, isn't it? Yes this is all stretching a bit, but it's not entirely wrong either.
- robrenaud 11y ago
  Unless you are willing to pay me to rm -rf your source tree, you are contorting the definition of liability.
  - nulagrithom 11y ago
    If you can remove lines of code and retain functionality, then yes, I will pay you to remove code. Conversely, adding lines of code but NOT adding functionality isn't worth a cent.
    - meric 11y ago
      Arguably, programming class teachers charge students indirectly for adding lines of code without adding valuable[1] functionality. The market value for code without valuable functionality is negative. [1] Value as determined by how much anyone is willing to pay to use the software.
    - Karunamon 11y ago
      Tests and comments.
      - eru 11y ago
        Comments are useful, if they provide insight. They are not useful, if they do not. Tests can provide a number of things: they can serve as API examples, assure functionality, speed up implementing new functionality and debugging. If you tests don't do these things, they are not worth keeping, either.
    - prof_hobart 11y ago
      Depends if it adds anything else - readability, maintainability, flexibility, portability etc. The "code as liability" argument seems, unless I'm mistaken, to be based on the idea that less code for the same level of functionality means less cruft, and therefore better support for the NFRs that I mentioned above. That's often true, but not always. If you're including those NFRs in what you mean by same functionality, then the number of lines of code is utterly irrelevant.

SonicSoul 11y ago

Unless you've heard of places paying per line of code you seem to have missed the point of code being a liability. It's what it does that's valuable, not the volume of it

jsprogrammer 11y ago
Code can only act through its volume. The fantasy of codeless functionality that is being propagated here is exactly that. Functionality only exists because of code. The two cannot be fully separated from each other in the way that some in this thread are implying.
- Xixi 11y ago
  An airliner certainly is an asset (at least in the hand of a well run airline), but the lighter the frame the better: a lighter frame needs less fuel to fly, hence more money remains in the bank at the end. But without frame there's no plane, so you need some of it, just as little as feasible. It's the same for code: a running program can certainly be a huge asset, but the less code you have the lower the maintenance cost. The concept is just harder to grasp than paying a kerosene bill each time a plane takes off...
  - riskable 11y ago
    I totally agree with your sentiment but I do want to add that adding code can be useful and make it better even if you're not adding functionality. For example, while it may be "cool" to turn a straightforward loop into a complicated one-liner (which would be "removing code while retaining functionality") that wouldn't necessarily be a good thing. The longer, more straightforward code is likely to have a lower maintenance cost.
  - xj9 11y ago
    I think the issue is that you are conflating lines of code with complexity. I certainly think it is better to write short programs, but it is wrong to think that less LOC == better code. The most valuable kind of software IMO is the kind you don't think about because it never fails, and at that point your LOC measurements are irrelevant.
yshklarov 11y ago
I did not mean to imply that the volume of code was directly tied to its value. I understand that value stems from functionality and not from quantity of code. But functionality does stem from code, as jsprogrammer said. If your code does X, and X is valuable, then the code is valuable -- I don't see what's wrong with this line of reasoning.
dragonwriter 11y ago
that's no more true of code than of land or anything else; thats just the fundamental idea of what value of a thing is, what you can use it to do or get. So it's odd to say that value doesn't lie in code but in the functionality that code provides, without also saying that of everything else, and, to say it at all -- of code or more generally -- is just to use language in an atypical way (and,if its just of code, an inconsistent way as well.)
- marrs 11y ago
  But the point is that you pay for the code in order to gain the functionality. Code is an expense. The application is the asset. If you want to add a feature to the application then you have to pay for it in developer time. The larger and more complicated the supporting code, the more time you will have to pay for.
  - dragonwriter 11y ago
    I pay for X because X provides valuable functionality is generally true of productive assets. And it's not unusual for productive assets to depreciate or have maintenance expenses that must be born to maintain their functionality -- usually both. So, while those are all valid observations about code, they don't make it a liability, they make it a fairly bog-standard productive asset.
    - msandford 11y ago
      So given the choice between having feature X written in 1,000 lines or 1,000,000 lines of code, you don't care which is which? I find that hard to believe. If code truly was an asset, it wouldn't really matter if it was 1000 lines or a 1,000,000 lines as they're functionally equivalent right? Or perhaps the million line program would be worth more, wouldn't it? Code is an asset. But the amount of code directly influences the maintenance cost, doesn't it? And maintenance cost is a liability, no? It's something that you're obligated to pay if you want to keep the asset productive. And an obligation to pay is a debt, isn't it? Yes this is all stretching a bit, but it's not entirely wrong either.
robrenaud 11y ago
Unless you are willing to pay me to rm -rf your source tree, you are contorting the definition of liability.
- nulagrithom 11y ago
  If you can remove lines of code and retain functionality, then yes, I will pay you to remove code. Conversely, adding lines of code but NOT adding functionality isn't worth a cent.
  - meric 11y ago
    Arguably, programming class teachers charge students indirectly for adding lines of code without adding valuable[1] functionality. The market value for code without valuable functionality is negative. [1] Value as determined by how much anyone is willing to pay to use the software.
  - Karunamon 11y ago
    Tests and comments.
    - eru 11y ago
      Comments are useful, if they provide insight. They are not useful, if they do not. Tests can provide a number of things: they can serve as API examples, assure functionality, speed up implementing new functionality and debugging. If you tests don't do these things, they are not worth keeping, either.
  - prof_hobart 11y ago
    Depends if it adds anything else - readability, maintainability, flexibility, portability etc. The "code as liability" argument seems, unless I'm mistaken, to be based on the idea that less code for the same level of functionality means less cruft, and therefore better support for the NFRs that I mentioned above. That's often true, but not always. If you're including those NFRs in what you mean by same functionality, then the number of lines of code is utterly irrelevant.