Live data from Hacker News

All code is technical debt

tokyodev.com

141–150 of 178 posts

Re: All code is technical debt

#141
I only skimmed through the article so I might have missed this part, but did the author consider picking up a few books about domain design or search some examples how do others implement such event organizing systems?

Because based on what I read, that seems to be his problem. He started implementing a system without having a good understanding of the domain's inherent problems and their common solutions. Not everything needs to be re-invented.

Even though I have never worked in this domain (event organizing) but still I could from the top of my head pull out one such example where a team went into great detail how to design and implement an event organizing system which answers most of not all the problems that the author faced: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/...

Re: All code is technical debt

#142
post #137
post #134

Earlier quoted context omitted.

> working code requires ongoing maintenance I don't love this either because working code needs no maintenance whatsoever. After all it's already working. There's also no notion of "repairing" code because it isn't something that can just break suddenly. So really what we're talking about is that necessary changes to the codebase can arise from not just the stakeholders as we typically define them but also because th…

Changes to the platform or dependencies break working code. This is increasingly hard to ignore when app stores stop vending your product to older versions of a platform, even if it's working fine. And working code, no matter how well it works, imposes a cost to implementing new features. A new feature might be a cinch to implement in a new app. But it can easily take much longer to implement the same feature in an e…

> Changes to the platform or dependencies break working code

Not all code. You have platform dependent code and then code that doesn't depend on anything outside of your own code. The code with no outside dependencies can easily stay around unchanged for decades and is not a liability.

"All dependencies are liabilities" I could agree with. Dependencies are technical debt that will continue to demand interest from you, they are often worth it but they are the main source of maintenance burden. Some are unavoidable if you need to interface with an API, but many are not.

Re: All code is technical debt

#143
post #87

Earlier quoted context omitted.

What I don't like about "technical debt" is that it's usually interpreted as "technical" debt: it's only a problem for the developers, the techies. You immediately lose the business stakeholders once you start talking about technical debt. But the problem of technical debt if a problem for everyone, not just the devs, because it is reflected in quality and time-to-market. I feel having that conversation about time-to…

unless its a perfect shining jewel - every piece of existing code constrains future development, until progress asymptotically approaches zero and development cost asymptotically approaches infinity

> every piece of existing code constrains future development

If that were literally true, then every new development would rationally necessitate a total rewrite of the codebase.

You might have meant that parts of the existing codebase would need to be changed to adapt to the new development, but as long as you've made a rational decision to keep using parts of the existing codebase, it must have been a net positive otherwise you'd just throw it all away.

Re: All code is technical debt

#144
post #90

Earlier quoted context omitted.

Code is an asset. Assets need to be managed, maintained, or else they will degrade. Assets have costs.

Gold bars don't need to be maintained and don't degrade. They just exist. That's the type of asset to own. A white elephant needs a living are, food, elephant experts, vets, etc. That's much closer to the type of asset most code is.

I understand what you’re trying to say with this analogy, but even gold bars have related costs, known as the cost of carry.

Re: All code is technical debt

#145

Earlier quoted context omitted.

And all code is an asset. Have we just reduced the conversation to: everything has a cost, and everything has a benefit?

> And all code is an asset. No - runnable programs are an asset. The code to produce those runnable programs is a liability. It's a necessary liability for a sustainable software business, as without the code fixing bugs is nigh-impossible (though not theoretically impossible - long-ago programmers wrote and read raw machine code). But, the code itself is not what produces value. That's the code's output. (Yes, you c…

> No - runnable programs are an asset.

> The code to produce those runnable programs is a liability.

That is total nonsense. So you throw away all your code after you built the program binary to avoid the liability? Don't think so, that code is a massive asset and throwing it away would make continuing the project unfeasible most of the time.

> It's a necessary liability for a sustainable software business, as without the code fixing bugs is nigh-impossible

Ok, so you agree with me, the code is a massive asset since it is the code that lets you change the program. Code is there to help programmers do their work, that is valuable as you say.

> But, the code itself is not what produces value. That's the code's output.

Both produces value. The code is valuable since it makes it easier to inspect and change the program. That is value. It isn't uncommon to sell source code access for products, why would anyone pay for that if seeing the source code is a liability? No, of course it is an asset, people arguing otherwise have just gotten too hooked on the "code is bad" mantra and try to argue all code is bad even though code obviously is very valuable.

Edit: And to be even more clear, throwing away the code and trying to work directly with a program binary creates technical debt, that is way worse debt than keeping the source code around. Code isn't inherently technical debt.

Re: All code is technical debt

#146

Earlier quoted context omitted.

No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later. Here, heed Wa…

That's certainly not how most people understand the term.

I mean that is the guy who invented it should we just go "ah well the uneducated masses really wish for a term that excuses bad programming so let's twist this nice metaphor into something we can sell to management to that effect", or instead just get the quote and correct people whenever we can until there's no more shadow under which to hide bad code.

Re: All code is technical debt

#147

Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.

Code isn't a product, code is the blueprint for the product. Have you heard mechanical engineers say "no blueprint is the best blueprint"?

Re: All code is technical debt

#148

Earlier quoted context omitted.

Agreed, or similarly: all software has a carrying (maintenance, but I think that has connotations of not including full ongoing TCO) cost. Code is a liability in the sense that it has a non-zero carrying cost. The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs. One of the appeals of SAAS is that th…

> Code is a liability in the sense that it has a non-zero carrying cost. The under-appreciated corollary to that: tests are code, hence tests have non-zero carrying cost as well. > The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs. You understress the complexity point. Higher quantity of code with…

Hear hear!!

Re: All code is technical debt

#149
without reading the article, the title is basically the thesis of every CIO/CTO who's drunk the koolaid and thinks moving to AWS somehow removes complexity. It trades complexity of code for grey problems and complex infrastructure/terraform/builds. Just a note - all extra AWS infrastructure over a simplistic minimum is technical debt.

Re: All code is technical debt

#150

I think code / coding is overrated. Coding is debt. If we look at math / category theory we have functorial semantics, which means semantics (code) is auto-generated from syntax (design): https://www.algebraicjulia.org/assets/slides/nist-workshop-2... If we look in another direction we see LLMs which (will one day) generate code from design. If I look back those years in my career, I was always paid to write the same…

Do you really believe no-code applications mean there’s 0 code? You’re just relying on someone else’s code at that point, and have no ability to customize business logic.
Post reply on HN