
All Code Is Technical Debt - bhalp1
https://dev.to/pbeekums/all-code-is-technical-debt
======
eesmith
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.

