A lot of assets require regular maintenance to keep working well, but that doesn't make them a liability.
I think the main point (written again and again) is that more code = more liability, and since AI generates a lot of code, it generates a lot of liability. It might have been better to lean on the AI thing in the title.
But it's kind of a weird thing to say that code is not an asset unless you're leaning heavily into pulling that AI rant into the mix.
This isn't a particularly new idea. The main thing being that you should consider the amount of code written to achieve something to be part of the cost of having that capability, and minimizing that cost is valuable. The mark of an effective system to me is how much capability it gives its users for how much burden it places on those maintaining it, and burden correlates well with the amount of code in the system.
(This is mainly something that's useful to consider in organizations which a lot of programming resource, as a way to counter the tendancy for them to consider the amount of code they are producing as a measure of their productivity, when often they could be better served by reducing the amount of code they write and focusing on producing better code or even removing existing code. AI tends to make this problem worse, but it's not the original cause of it)
But that's literally not how assets or liabilities work, so it's a weird statement to make and an even weirder title for a post on essentially AI coding.
Sure, counting your productivity by lines of code is stupid, but that doesn't mean all code is liability. Good code and products are always assets and, like most assets, require maintenance to keep running.
You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code? Or machinery at a plant? Or jets owned by an airline?
I get the point they're trying to make, but it's very poorly made and uses broad metaphors that do not align with reality.
> You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code?
Wouldn't I? If I have to keep my car maintained, insured etc, but I don't get enough value out of it to offset that, then it's a liability.
The conceptual difference you can make with code is that code contains all the liability and none of the value. It is only in the capabilities of the system the code manifests that value is achieved. In the same way the perfect car simply teleports you to your destination without need to maintain all that metal and rubber, the most desirable software delivers behaviors without the need to maintain any code.
There are two things being blurred together here that we need to separate:
1. Maintenance tasks needed to ensure continued original behavior and capability.
2. Renovations and alterations needed to maintain enough utility as environments and needs change.
A big truck that carries thousands of pounds of cargo is an asset, even if you have to replace the oil... But what happens when the water rises and you have to choose between junking it entirely versus welding on pontoons to make it float? Now all those strong welds of heavy steel start to seem like a liability.
Trucks mainly have problem #1, while software mainly has problem #2.
Some of the analogies are a bit strained, but I'm in agreement.
Every line of code is technical debt - all of it. The engineering responsibility is to minimize the rate you pay on the debt, and to make its eventual renegotiation cheaper.
It's a liability management exercise that goes on as long as you want to use your system as a working asset.
Bang on. We'll start seeing the AI story become increasingly about addressing this particular issue in the coming year. I expect the mainstream talking point will be around codebases that can be rewritten instantly when the world changes under them, thus making code ephemeral and not a liability.
Code requires maintenance, so it's not an asset?
That makes little sense.
A lot of assets require regular maintenance to keep working well, but that doesn't make them a liability.
I think the main point (written again and again) is that more code = more liability, and since AI generates a lot of code, it generates a lot of liability. It might have been better to lean on the AI thing in the title.
But it's kind of a weird thing to say that code is not an asset unless you're leaning heavily into pulling that AI rant into the mix.
This isn't a particularly new idea. The main thing being that you should consider the amount of code written to achieve something to be part of the cost of having that capability, and minimizing that cost is valuable. The mark of an effective system to me is how much capability it gives its users for how much burden it places on those maintaining it, and burden correlates well with the amount of code in the system.
(This is mainly something that's useful to consider in organizations which a lot of programming resource, as a way to counter the tendancy for them to consider the amount of code they are producing as a measure of their productivity, when often they could be better served by reducing the amount of code they write and focusing on producing better code or even removing existing code. AI tends to make this problem worse, but it's not the original cause of it)
But that's literally not how assets or liabilities work, so it's a weird statement to make and an even weirder title for a post on essentially AI coding.
Sure, counting your productivity by lines of code is stupid, but that doesn't mean all code is liability. Good code and products are always assets and, like most assets, require maintenance to keep running.
You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code? Or machinery at a plant? Or jets owned by an airline?
I get the point they're trying to make, but it's very poorly made and uses broad metaphors that do not align with reality.
> You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code?
Wouldn't I? If I have to keep my car maintained, insured etc, but I don't get enough value out of it to offset that, then it's a liability.
The conceptual difference you can make with code is that code contains all the liability and none of the value. It is only in the capabilities of the system the code manifests that value is achieved. In the same way the perfect car simply teleports you to your destination without need to maintain all that metal and rubber, the most desirable software delivers behaviors without the need to maintain any code.
There are two things being blurred together here that we need to separate:
1. Maintenance tasks needed to ensure continued original behavior and capability.
2. Renovations and alterations needed to maintain enough utility as environments and needs change.
A big truck that carries thousands of pounds of cargo is an asset, even if you have to replace the oil... But what happens when the water rises and you have to choose between junking it entirely versus welding on pontoons to make it float? Now all those strong welds of heavy steel start to seem like a liability.
Trucks mainly have problem #1, while software mainly has problem #2.
Some of the analogies are a bit strained, but I'm in agreement.
Every line of code is technical debt - all of it. The engineering responsibility is to minimize the rate you pay on the debt, and to make its eventual renegotiation cheaper.
It's a liability management exercise that goes on as long as you want to use your system as a working asset.
Bang on. We'll start seeing the AI story become increasingly about addressing this particular issue in the coming year. I expect the mainstream talking point will be around codebases that can be rewritten instantly when the world changes under them, thus making code ephemeral and not a liability.