4 ms·

No there is not. A line of code takes no resources, has no overhead, requires no upkeep. I think you may be referring to the drag complexity imposes in future d

No there is not. A line of code takes no resources, has no overhead, requires no upkeep. I think you may be referring to the drag complexity imposes in future development. That I agree with, but LOC is a poor proxy for complexity, and code that is static costs nothing.

fragmede 3y ago
Every line of code has an overhead; has a chance of bugs, and demands upkeep just for existing. Having class A, class B, and class C, that do almost the same, but slightly different thing means that when the business rules change, that you have to be sure that similar, but slightly different changes to class B and class C, which aren't neatly going to be self-contained in B.cpp and C.cpp (or .py, .rs, .rb; you get the point) have to be made, and then you can't ever be sure that A.cpp doesn't also have some long-forgotten but similar and crucial bit of functionality that this one customer relies on (because that was written before TDD became popular). --- LoC itself is a bad proxy for complexity, but I think taking the log of the number of LoC tells you enough to build some expectations. A codebase where log LoC is ~6 (so in the neighborhood of ~1M LoC) is different enough from one where log LOC is ~3 (so ~1,000 LoC) that you have an idea of what you're getting into if someone asks you to make a change to either one of those.
- delusional 3y ago
  The key to understanding our (apparent) disagreement is: > that when the business rules change Yes, when things change complexity has a cost. The inverse is also true however, if nothing changes, it has no cost. If class A, B, and C do almost the same thing, then nobody cares because the computer will gladly execute almost the same thing in different locations in memory. The modern computer built today is essentially perfect. It will execute the same thing every time, it will not suddenly require changes because there was some degradation in an adder, and no cogs need changing. All the maintenance is stuff we make up because we want it to do something it never did before.
  - Supermancho 3y ago
    > Yes, when things change complexity has a cost. Things always change. Software does not perform in a vacuum. It's subject to the inexorable progression of hardware decay and business knowledge loss, at the very least.
  - fragmede 3y ago
    A friend's friend's company absolutely relies on this bespoke computer program running on an un-networked desktop computer running Windows XP from the 2000s. There will be a degradation in its hard drive, its power supply, its fan; something. All the lines of code that comprise that program (which are lost to the sands of time) are a liability because that code has been lost. All we can do now is virtualize the application and move it to newer hardware that isn't on the verge of failing. Rewriting the app is out of everyone's budget so that's all we can do, and hope for the best. The lower the log LoC of their Visual Basic app, the easier it should be to replace and rewrite atop a modern tech stack. If it ain't broke... you point out. It's old and creaky, and everyone's just afraid of the thing. There's no real backup (working on that!), there's no accessibility to it from the Internet - looking up info on that computer via a smartphone or tablet would be a boon to the company. It's absolutely load bearing, but it's like a bridge that's too small for the city that's grown around it. The world moves forwards around software that's sat in place, so the software wants to move as well. We're not "making up" maintenance stuff just for the hell of it. Unless you work on the same chair and desk you used when you were 5. I don't fit in mine, and they were lost to a move anyway.
klodolph 3y ago
Saying “a line of code requires no resources” can only be true under a particular set of assumptions and particular system for accounting. It’s not a useful or interesting argument by itself, because it doesn’t explain the assumptions and accounting system that it implies.

fragmede 3y ago

Every line of code has an overhead; has a chance of bugs, and demands upkeep just for existing. Having class A, class B, and class C, that do almost the same, but slightly different thing means that when the business rules change, that you have to be sure that similar, but slightly different changes to class B and class C, which aren't neatly going to be self-contained in B.cpp and C.cpp (or .py, .rs, .rb; you get the point) have to be made, and then you can't ever be sure that A.cpp doesn't also have some long-forgotten but similar and crucial bit of functionality that this one customer relies on (because that was written before TDD became popular). --- LoC itself is a bad proxy for complexity, but I think taking the log of the number of LoC tells you enough to build some expectations. A codebase where log LoC is ~6 (so in the neighborhood of ~1M LoC) is different enough from one where log LOC is ~3 (so ~1,000 LoC) that you have an idea of what you're getting into if someone asks you to make a change to either one of those.

delusional 3y ago
The key to understanding our (apparent) disagreement is: > that when the business rules change Yes, when things change complexity has a cost. The inverse is also true however, if nothing changes, it has no cost. If class A, B, and C do almost the same thing, then nobody cares because the computer will gladly execute almost the same thing in different locations in memory. The modern computer built today is essentially perfect. It will execute the same thing every time, it will not suddenly require changes because there was some degradation in an adder, and no cogs need changing. All the maintenance is stuff we make up because we want it to do something it never did before.
- Supermancho 3y ago
  > Yes, when things change complexity has a cost. Things always change. Software does not perform in a vacuum. It's subject to the inexorable progression of hardware decay and business knowledge loss, at the very least.
- fragmede 3y ago
  A friend's friend's company absolutely relies on this bespoke computer program running on an un-networked desktop computer running Windows XP from the 2000s. There will be a degradation in its hard drive, its power supply, its fan; something. All the lines of code that comprise that program (which are lost to the sands of time) are a liability because that code has been lost. All we can do now is virtualize the application and move it to newer hardware that isn't on the verge of failing. Rewriting the app is out of everyone's budget so that's all we can do, and hope for the best. The lower the log LoC of their Visual Basic app, the easier it should be to replace and rewrite atop a modern tech stack. If it ain't broke... you point out. It's old and creaky, and everyone's just afraid of the thing. There's no real backup (working on that!), there's no accessibility to it from the Internet - looking up info on that computer via a smartphone or tablet would be a boon to the company. It's absolutely load bearing, but it's like a bridge that's too small for the city that's grown around it. The world moves forwards around software that's sat in place, so the software wants to move as well. We're not "making up" maintenance stuff just for the hell of it. Unless you work on the same chair and desk you used when you were 5. I don't fit in mine, and they were lost to a move anyway.

klodolph 3y ago

Saying “a line of code requires no resources” can only be true under a particular set of assumptions and particular system for accounting. It’s not a useful or interesting argument by itself, because it doesn’t explain the assumptions and accounting system that it implies.