This is a “when you think about it” argument.
As in “humans are just tubes, when you think about it”.
Technical debt is a thorny issue already. Arguments like this don’t help.
All code is technical debt
71–80 of 178 posts
Re: All code is technical debt
#72Earlier quoted context omitted.
I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch…
> Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today [...] Oh I suspect Ward's context was even more idealistic. That there was a problem to be solved, and there were few to no moving targets, the only differences over time were in the programmer's heads as they…
> This is not the only factor in software development today,
I suspect it is a mistake to think that software development today is fundamentally different from how it was practised when he first wrote that. Possible application of recency bias..
Re: All code is technical debt
#73I 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…
Completely agreed. The idea that "all code is technical debt" because all requirements could hypothetically change someday, makes as much sense as saying "all currencies have no value" because 1,000 years from now we might not be using any of them. Technical debt is not defined in terms of possible future requirements, it is defined in terms of current requirements. Code that elegantly and concisely expresses current…
But dept can only recognized if you're trying to implement something new, and notice that you have to pay interest. Poorly written code makes it very hard to implement new features & debug existing one, while well written code makes it easy. So the current dept can only be estimated with respect of features you are implementing in the future.
Re: All code is technical debt
#74I 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 don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a…
I disagree. Scaling things up has a cost, but not all costs are debt financed. I think the distinction is worth drawing.
Re: All code is technical debt
#75[dead]
Re: All code is technical debt
#76Code is best reasoned about as a depreciating asset, not technical debt.
Re: All code is technical debt
#77Earlier quoted context omitted.
I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a…
I disagree. Scaling things up has a cost, but not all costs are debt financed. I think the distinction is worth drawing.
That's a good response. I can buy a house cash, I can buy a house with a 5% mortgage, or I could buy a house with a 20+% loan.
Rushing out features with known bugs, poor architecture, no test and no documentation is akin to buying a house with a 20+% loan. You'll get your house sooner but you'll spend most of your resources servicing that debt until you can pay it down.
Re: All code is technical debt
#78I 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 don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a…
> I don't think the analogy breaks down per-say.
Sorry for being "that guy", but I think you meant "per se".
Re: All code is technical debt
#79I 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…
My brother coined a term that I really love: "feature karma". He's an actual Buddhist, so he used the term "karma" not to mean a simple score with only positive connotations, but as something you're chained to and must work off should you at some point want to move past it.
I often try to explain the concept of Technical Wealth as the other side of the spectrum from Technical Debt.
Technical Wealth pays dividends; Tech Debt charges interest on which the payments will eventually become unwieldy.
That doesn't mean you shouldn't take on Technical Debt, like many startups do with real money you can and should go into debt in order to get your business off the ground. But just like irresponsible financial management can kill your company, so can irresponsible technical management.
Re: All code is technical debt
#80Earlier quoted context omitted.
I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch…
> there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things…
To generalize that idea a little, I think about technical debt being the accumulation of less-than-perfect decisions, if you consider the decision you made against the best possible decision that could have been made in hindsight.
Sometimes that's not making things flexible enough, or too flexible, or not having all the requirements captured, or making technical bets that didn't pan out.