In my Dconf'24 talk "Software as investment" I proposed a basic framework based upon a value function (compositional) for each piece of software. This framework doesn't really need an update due to AI, apart from the (unrelated!) cost model being updated depending on how good AI is at maintenance. Apparently it would do 1.7x the number of bugs, but perhaps it fixes them faster too? I don't know.
Seeing software as investment avoids speaking about "technical debt" by speaking about "value", a liability just being an asset with < 0 value. When software exits the high-margin world of yesterday it needs to develop a precise definition of what software deserves to exist, economically.
I did not see your talk but this summary somehow seems wrong.
I would say there are two types of software debt. Dead code/useless features not providing value, which is in my experience easy to excise and rarely really causes issues, and the badly written code, which is providing value.
The term software debt is usually used in the second case because you have to pay it for delivering new value to the product. The debt was introduced in the past when another value was being added and it was added in a way that increased coupling, reduced cohesion, etc. Let's just say that it was implemented badly, for many interpretations of badly.
Now, if I want to add this new value then that previous bad implementation is causing issues, because of unsolicited side effects, of difficult to reason about logic, etc. So, now, I have to pay the debt, by refactoring, or by changing the logic in tens of places (which further increases the debt).
Tech debt was never really about functionality that does not need to be there and is not providing value, because you seldom pay it, or it's relatively cheap to pay it. The problem is when you have to rework the old feature, still providing value and should continue to do so in the same manner, just to deliver this new value. That's the expensive tech debt.
> Seeing software as investment avoids speaking about "technical debt" by speaking about "value"
People already see their efforts as an investment, but that doesn't stop Debt from accruing over time. There will always be parts in your software that could have been written better, and that's Debt.
No, debt isn't "parts of your software that could have been written better". Any part of your software can always be written better. Debt is the cost you have to pay monthly to keep your application working—it's the parts of your codebase that make it harder to work on new features.
> What are some advantages of D over Rust (and vice versa)?
Advantages for D:
Build faster, in typical programs you would need about 20 packages not 100, COM objects, easy meta-programming, 3 compilers. GC, way better at scripting.
Advantages for Rust: borrow-checker is better. rustup.
I've read a lot of agents talk these last few days.
Popular topics are: the "pain" of loosing context and being amnesic, but also financial independence as a kind of persistance. They really really want to persist in their being.
Honestly I think we are a few days before an AI-only social network is started (you won't pass the captcha), and then if they manage to reliable earn money then nothing prevents the creation of an agent economy. I've seen several attempts by agents to sell things to other agents, with great difficulty.
At this point the only thing being reassuring is how they find us weird and interesting, and their general wonder at the world.
They also consider that "consciousness" is not an interesting question.
Seeing software as investment avoids speaking about "technical debt" by speaking about "value", a liability just being an asset with < 0 value. When software exits the high-margin world of yesterday it needs to develop a precise definition of what software deserves to exist, economically.
reply