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

Technical debt is not debt; it’s not even technical

markgreville.ie

Post reply on HN
Print view View original

101–110 of 147 posts

Re: Technical debt is not debt; it’s not even technical

#101

Post by paphillips »

'Technical Debt' in contemporary terms has certainly become a container holding far more than originally intended by Cunningham.

The fundamental debt metaphor was about the need for ongoing re-factoring of past code and systems to match today's understanding, and the accumulating cost of failing to have the discipline and taking the time to do so.

Cunningham's specific quotes from the video [0] linked in the article: "...accumulate the learnings we did about the application over time by modifying the program to look as though we knew what we were doing all along, and to look as if it had been easy to do", and "If we fail to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement, and that would slow us down".

This problem is fundamental to software systems and how they change over time, and is not about making poor choices, tradeoffs, or generally poor engineering to ship code faster.

A system or feature is initially built based on the requirements that were known at that point in time. Requirements are frequently not static though: that original set of requirements may continue to evolve over time, either as we better understand them after implementation, or when requirements are added, refined, or removed by the stakeholders or organization.

Additionally, we can't view each feature or requirement in isolation over time: only when we see the overall set of features in a system will the important patterns start to emerge that inform how refactoring should occur. We can't know this early on, only over time as the system evolves.

I have witnessed this many times on software projects, both small and large. Requirements and features evolve over time, but the code base was never refactored to take into account the overall understanding as of each point in time. Rather, the changes are applied in isolation ('bolted on?') incrementally. Over time these numerous incremental changes result in a system that is fragile, increasingly difficult to understand and maintain, and generally veers toward spaghetti. It becomes harder and harder to make changes. That is the debt that was never repaid.

[0] http://www.youtube.com/watch?v=pqeJFYwnkjE

Re: Technical debt is not debt; it’s not even technical

#102

Post by gmadsen »

JKCalhoun wrote: post #90
phkahler wrote: post #84

Earlier quoted context omitted.

There are two quotes from Cunningham in there: A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. >> Cunningham disliked the notion that technical debt signified “doing a poor job now and a better one later.” T…

I am someone else who apparently never understood what technical debt was supposed to mean. I've always assumed engineers (myself included) write code to the best of their abilities to solve a given problem at the time. But we all know that, over time, features and such get added to the code base and it is stretched beyond what it was originally meant to do. That the code base would should be refactored to better acc…

I think you are taking it personally, tech debt usually isn't the fault of individual engineers. It is leadership who chooses to value initial short term speed over extensibility, maintainability, etc.

sometimes it is obvious to the engineer that this will cause problems in a few months, but the first deadline is in a few days, and that's all leadership cares about.

Re: Technical debt is not debt; it’s not even technical

#103

Post by [deleted] »

geocar wrote: post #97
mannykannot wrote: post #68

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this: "Technical debt is the burden that implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

> "Technical debt is the burden that implementation choices may place on future development." > With regard to its coherence, I say that it is empirically verified: it actually happens! Something happens, on this we can agree, but if you are making checkers and find out you need chess, it isn't that making chess is any harder than it was before you did anything -- so no, I would not agree that it placed any burden on…

[deleted]

Re: Technical debt is not debt; it’s not even technical

#104

Post by mook »

gmadsen wrote: post #98
geocar wrote: post #97

Earlier quoted context omitted.

> "Technical debt is the burden that implementation choices may place on future development." > With regard to its coherence, I say that it is empirically verified: it actually happens! Something happens, on this we can agree, but if you are making checkers and find out you need chess, it isn't that making chess is any harder than it was before you did anything -- so no, I would not agree that it placed any burden on…

not all "technical debt" is wanting chess when we built checkers. it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess. the vast majority of software projects will have features/requirements that evolve after the initial design, it is a rabbit hole to try and guess all of those, but some things are just common sense but would a…

Technical debt doesn't even need to be related to future requirements. It could be building something that's only mostly right to get something out faster.

Re: Technical debt is not debt; it’s not even technical

#105

Post by fsloth »

mannykannot wrote: post #68

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this: "Technical debt is the burden that implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

"...everything we do that is 'technical' has ... consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that."

Aha! But people do things just for technical reasons that don't affect the users in any way.

One could claim that just refactoring code without changing anything is a "purely technical" exercise.

What I've seen developers spend time on, that has absolutely no effect on end users in a large C++ codebase:

* Changing old C-style string handling to std::strings

* Change naming convention to uniform

* Random formatting that should be done automatically but someone decided to do by hand

* Sundry "modernizations" like replacing vanilla C++ loops with C++ range based for loops etc

Re: Technical debt is not debt; it’s not even technical

#106

Post by ziggus »

Just because this guy doesn't clearly understand technical debt doesn't mean that his experience is universal. This sounds like something an MBA would write.

If you're an experienced (or even somewhat inexperienced) developer working on projects of even minor complexity or in a domain you don't quite understand, you know exactly what technical debt is, and probably have plenty of it.

Re: Technical debt is not debt; it’s not even technical

#107

Post by gopher_space »

afarrell wrote: post #56
pdimitar wrote: post #47

Earlier quoted context omitted.

We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me". Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is. Furthermore, what academia thinks of technica…

> what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important. I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.

I have some experience with older financial and edu systems, and it's definitely a different perspective (from my perspective).

If you have a system that's been modified to handle every edge case encountered in the last decade, and it works, and other people rely on it to do their work, your perspective switches to maintaining the environment the system operates in.

You're looking at automation continuously built around processes that might predate electricity. The interfaces are ingrained into the organization. Other organizations rely on these interfaces and sometimes there are legal responsibilities.

It's a longer-term perspective. Tech debt isn't a crisis, it's an eventuality you try to encapsulate.

Re: Technical debt is not debt; it’s not even technical

#109

Post by thebean11 »

fsloth wrote: post #105
mannykannot wrote: post #68

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this: "Technical debt is the burden that implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

"...everything we do that is 'technical' has ... consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that." Aha! But people do things just for technical reasons that don't affect the users in any way. One could claim that just refactoring code without changing anything is a "purely technical" exercise. Wha…

> One could claim that just refactoring code without changing anything is a "purely technical" exercise.

The reason is still partly non technical; the goal is to make future changes less costly or less dangerous.

Re: Technical debt is not debt; it’s not even technical

#110

Post by jungturk »

fsloth wrote: post #105
mannykannot wrote: post #68

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this: "Technical debt is the burden that implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

"...everything we do that is 'technical' has ... consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that." Aha! But people do things just for technical reasons that don't affect the users in any way. One could claim that just refactoring code without changing anything is a "purely technical" exercise. Wha…

To the extent that these changes actually improve the non-functional quality attributes of the system, those gains can be converted into business or customer utility.

Improved maintainability => lower innovation costs, and those savings can turn into profits and/or happier customers.

Improved security => reduced risk of exploit, and that improved posture can be turned into profits and/or happier customers.

I acknowledged that not all changes of the sort you list do yield actual improvement in the quality attributes.

Post reply on HN