All code is technical debt
tokyodev.com
All code is technical debt
1–10 of 178 posts
Re: All code is technical debt
#2Hang out with mechanical engineers and it won't be long until you hear, "best part is no part".
Best code is no code.
Re: All code is technical debt
#3Sure I sometimes say features are assets but code is a liability. Usually as part of an argument against complexity that some engineers favor to be ready for speculative future circumstances.
Re: All code is technical debt
#4I work with a FOSS product that has millions of lines of C. As a student, I would have been wowed by seeing these FOSS contributors each with +100,000 LOC in a single project. Now that I am more familiar how barely-functional the software is, with glaring architectural mistakes papered over by literally millions of LOC, I am more cynical.
"Contributing" 100K LOC by implementing a bespoke http.c and mysql_client.c in 2020 is almost never something to be proud of from a SWE and product perspective. Great for ego/NIH and job security though.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry
Re: All code is technical debt
#5> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development.
No! Ward's blog post linked in this very paragraph [0] describes the original definition quite clearly, and it's not this.
The term was originally intended to describe the delta between a programmer's current understanding acquired through the process of developing the software, and the accumulated implementation which is based upon a combination of past understanding. Because writing a program is often a process of discovery and learning about the problem and solution space, it's not usually possible to write the ideal implementation up front.
It's quite clear In Ward's 2nd paragraph where he describes the correction of this debt:
> it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk.
What the author is describing is the modern definition that it has acquired independently, where by programmers knowingly take shortcuts... this is an entirely different phenomenon, intentionally writing code in a way that is less than ideal even based on current understanding. I find the original definition far more interesting and insightful, but the modern one is perhaps more reflective of the more common realities of the pressure developing software in a business today.
[0] https://wiki.c2.com/?WardExplainsDebtMetaphor
[edit]
Despite this error, I do agree with the sentiment of the article, that too much code is a liability, that features can cost more than they are worth.
Ward's definition of technical debt affects the cohesion and correctness of the code, the idea that if you could tear it all up every day and re-write it from scratch that it would always reflect the most up to date understanding, and for moving targets the most up to date problem, that it be absent of the weight of past misconceptions or solutions to past problems... aiming for minimal code makes achieving that state far more viable - these are complementary insights, so it's a shame the nuance of the original definition was lost.
Re: All code is technical debt
#6Living is dying.
Re: All code is technical debt
#7Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.
this is why deleting code is so great. a lot easier time than the MEs too
Re: All code is technical debt
#8Don't you just love clickbait blog articles that make no sense? HN sure does!
Re: All code is technical debt
#9More code means more opportunities for things to go wrong, but I wouldn't go quite as far as saying that all code is tech debt, even though it makes for a good blog post title. Looking at all code in such a pessimistic light doesn't actually seem that useful. It might be one thing if there were adequate measures for "good code", but those hardly exist, or are dwarfed by inadequate measures that are entirely opinion-based. Less code than more might be as good as it gets, but I would rephrase the author's "To avoid technical debt, don’t write code" as "To avoid technical debt, write less code" (though perhaps "fewer codes" may be more grammatically accurate). Code is not bad, and tech debt isn't necessarily bad either. We code to accomplish things, and as much as I despise shitty codebases, even companies with a lot of tech debt often provide a lot of value to both customers and employees. In fact, I would say that tech debt in and of itself is no more a problem than monetary debt in real life, except when it's not being paid off and is collecting interest. We could not only write less code but actually pay off our tech debts, yet the structure of incentives and most companies hardly facilitates that.
Re: All code is technical debt
#10Hang out with mechanical engineers and it won't be long until you hear, "best part is no part". Best code is no code.
The code without code is the eternal code.
All other code requires updating dependencies.