3 ms·

All Code Is Technical Debt

2 points by bhalp1 9y ago

eesmith 9y ago
I don't see the connection. I think it comes back to the author's definition of "technical debt", that being: > Technical debt is when the code written is not as good as it could be. However, what defines “as good as it could be”? I don't think of it that way, precisely because that definition is impossible to achieve, making the definition meaningless. Technical debt is based on an estimate of expected value. Such estimates are necessarily imprecise, and sometimes they can only be determined retrospectively. Technical debt can occur if a programmer's timeframe for the estimate is shorter than the project's expected timeframe. This can be considered an inadvertent debt, to use Fowler's terminology. As an example of deliberate debt, a group may decide to implement a prototype solution because the improved estimates of expected value may justify the need to spend time rewriting the prototype code. The author also writes: > No matter how much care a developer puts into writing their code, they should WANT to be unhappy with it eventually. That is the mark of learning. Many developers, including myself, have spent too much time early on in their careers trying to make things “perfect”. This is a seriously bad suggestion. You should judge your work based on the resources you have, not against some abstract "if-I-knew-then-what-know-now" future world. Nor should you criticize the past for them not having the same resources as you do now. I wrote a web app in the 1990s. It was a bunch of perl CGI scripts, and I created my own mini-template language for it. If I did it now I would use Django, and be able to build off more existing libraries, including an open source project I helped start as a result that project. I am not at all unhappy with that 20 year old program. Going now back to this essay, the author writes "That’s because all code is technical debt. Every single line of it." We can test that by looking at extremes. The program /bin/true can be written in zero lines of code. (And zero bytes.) It works because the kernel thinks its a shell script, passes it to /bin/sh, which in turn does nothing, and reports that it successfully did nothing. If there are no lines of code, is there technical debt? Absolutely! And we can look at the variation of /usr/bin/true implementations to get some idea. On some unix variants, the code is "exit 0". Perhaps they didn't like the support debt of explaining why there was a 0 byte program. Or they wanted it to match /usr/bin/false. On some of these, there was an SCCS version string and copyright statement. Perhaps their lawyers had a requirement that all programs needed this information. On some systems, /usr/bin/true is an executable. This executes faster than starting /bin/sh just to get an exit value of 0. Technical debt can therefore exist independent of having any code at all. That doesn't many that any of these show signs of technical debt for what the project needed. You have to judge debt with respect to the project lifetime and its historical context, not some abstract view of perfection.

2 points by bhalp1 9y ago

I don't see the connection. I think it comes back to the author's definition of "technical debt", that being: > Technical debt is when the code written is not as good as it could be. However, what defines “as good as it could be”? I don't think of it that way, precisely because that definition is impossible to achieve, making the definition meaningless. Technical debt is based on an estimate of expected value. Such estimates are necessarily imprecise, and sometimes they can only be determined retrospectively. Technical debt can occur if a programmer's timeframe for the estimate is shorter than the project's expected timeframe. This can be considered an inadvertent debt, to use Fowler's terminology. As an example of deliberate debt, a group may decide to implement a prototype solution because the improved estimates of expected value may justify the need to spend time rewriting the prototype code. The author also writes: > No matter how much care a developer puts into writing their code, they should WANT to be unhappy with it eventually. That is the mark of learning. Many developers, including myself, have spent too much time early on in their careers trying to make things “perfect”. This is a seriously bad suggestion. You should judge your work based on the resources you have, not against some abstract "if-I-knew-then-what-know-now" future world. Nor should you criticize the past for them not having the same resources as you do now. I wrote a web app in the 1990s. It was a bunch of perl CGI scripts, and I created my own mini-template language for it. If I did it now I would use Django, and be able to build off more existing libraries, including an open source project I helped start as a result that project. I am not at all unhappy with that 20 year old program. Going now back to this essay, the author writes "That’s because all code is technical debt. Every single line of it." We can test that by looking at extremes. The program /bin/true can be written in zero lines of code. (And zero bytes.) It works because the kernel thinks its a shell script, passes it to /bin/sh, which in turn does nothing, and reports that it successfully did nothing. If there are no lines of code, is there technical debt? Absolutely! And we can look at the variation of /usr/bin/true implementations to get some idea. On some unix variants, the code is "exit 0". Perhaps they didn't like the support debt of explaining why there was a 0 byte program. Or they wanted it to match /usr/bin/false. On some of these, there was an SCCS version string and copyright statement. Perhaps their lawyers had a requirement that all programs needed this information. On some systems, /usr/bin/true is an executable. This executes faster than starting /bin/sh just to get an exit value of 0. Technical debt can therefore exist independent of having any code at all. That doesn't many that any of these show signs of technical debt for what the project needed. You have to judge debt with respect to the project lifetime and its historical context, not some abstract view of perfection.