Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All code is technical debt

tokyodev.com

Post reply on HN
Print view View original

151–160 of 178 posts

Re: All code is technical debt

#151

Post by [deleted] »

mmcnl wrote: post #90
jrockway wrote: post #46

Code is inventory, not debt. Inventory is good and bad. If someone comes to your store and everything is out of stock, you will make $0. So you want some inventory. But if you have too much inventory and nobody is buying anything, then your inventory just rusts in storage and becomes worthless. Code is pretty much exactly the same. Most features are sitting in storage in the hopes that someone comes by to buy it. Som…

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

[deleted]

Re: All code is technical debt

#152

Post by MrJohz »

Jensson wrote: post #142
sowbug wrote: post #137

Earlier quoted context omitted.

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…

Unless you're deploying your code bare-metal on a machine with no OS, you've got software dependencies, and even in that situation you've got hardware dependencies. I think the idea of dependency-free code is a myth that we like to use based on the abstraction layers we're comfortable with - if I'm okay assuming that a given layer always Just Works™, then it magically stops being a dependency and becomes the new ground level.

That said, I agree that it's helpful to think of dependencies in terms of their potential liability as well as their benefit.

Re: All code is technical debt

#153

Post by randomdata »

postalrat wrote: post #125
mmcnl wrote: 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.

Gold bars in storage may not degrade, but code in storage doesn't degrade either. We know from context that we're talking about code put to use. Gold bars are quite prone to degradation when put to use as well.

Re: All code is technical debt

#155

Post by seanhunter »

Aeolun wrote: post #122
ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

> The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). This is the same for bog standard development though. Any code you add, regardless of whether it is termed technical debt or not, will make your future development slower. Like you say, that doesn’t mean it’s the wrong move, you want to build a product after all, but I think I…

That's not true at all. There are lots of circumstances where adding (good) code adds velocity.

Imagine I'm trying to do a bunch of graphics stuff. The code I write to integrate a 3rd party graphics library will make my future development faster. I am effectively creating a lever I will later use to increase my productivity.

Say I need to do a bunch of linear algebra. Code I write to calculate dot products, determinants etc (or better yet to use a library to do those things) will greatly accellerate progress later and enable me to think in terms of the linear transformations I'm trying to accomplish rather than the underlying primitive operations.

Re: All code is technical debt

#156

Post by 5350-uiop-1130 »

some devs really have their heads up their own arse

we seem to believe we are craftsmen sculpting some work of art

code is just shit you write, means to an end, be it closing a ticket or going home. soon deleted ("deprecated") and replaced with new trendier shit.

> "we need to ensure we’re working on valuable features"

yeah valuable features are what your boss's boss needs to get their promotion and/or bonus.

Re: All code is technical debt

#158

Post by mirekrusin »

ljm wrote: post #88
ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectl…

Isn't this line of reasoning a bit like saying "life causes death"?

Re: All code is technical debt

#159

Post by atoav »

anileated wrote: post #135
opportune wrote: post #97

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…

Tests are indeed not free. But neither is having to spend two days to debug a weird bug you would have cought if you had them. Depending on the worst thing your software could be doing if it had a edge case mistake, writing tests is also just another take on trying to prevent them when they happen.

Also: nothing prevents us from deleting tests and do as if they never existed, except the nagging voice of sunken cost.

Re: All code is technical debt

#160

Post by djur »

mmcnl wrote: post #87
ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

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…

In the contemporary tech industry, there's a pretty good chance that the managers who oversaw the decision to incur technical debt are not going to be the managers who make the call whether to "repay" it. It might not even be the same programmers. The "debt" metaphor makes a lot of sense when you're saying "you are asking for something that will incur a cost that we will later need to repay". It seems less effective when you're saying "your predecessor's predecessor asked my predecessor's predecessor for something that probably made sense at the time, but now we 'owe' some work on fixing the problem they left us".
Post reply on HN