Code Is Not Technical Debt

The Introduction

So I noticed a put up at present, and it’s so incorrect I used to be about to put up a ranty missive on
Hacker Information.

However my ranty missives get lengthy, so right here’s a weblog put up as a substitute.

The Submit

The put up is “All Code Is Technical Debt” written by Paul McMahon.

And the whole lot is simply barely incorrect, ranging from the title.

So let’s break it down.

The Thesis

Paul’s thesis is on the finish of his introduction:

Because the extra code you add to an utility, the slower growth turns into, I
view all code as technical debt.

However is that this true? Does growth velocity at all times get slower in case you add code?

Let’s have a look at the corollary: does growth velocity at all times get quicker in case you
take away code?

That’s false on its face!

One of many causes folks don’t like C (apart from memory bugs) is its paltry
normal library! C is principally the acute of “take away code,” and I can inform
you from expertise that its tiny normal library slows growth.

So if the corollary just isn’t true, is the thesis?

It’s completely not true.

Take this commit from my most famous project.

In that commit, I’m including three, three!, new key phrases and instructions to bc
and dc.

For that commit, I deleted 7 traces and added 108.

Meaning I deleted a median of 1 line per key phrase per program, and added
a median of 18 traces per key phrase per program.

Okay, let’s see how a lot of that code exists 537 commits later.

I ran blames and took out whitespace-only code type fixes. Of the 108 traces,
77 nonetheless exist. That’s 71.2%.

And many of the ones that modified had been numbers or different knowledge that acquired modified
once I added different key phrases.

However the different secret is how simple it was so as to add these options; even when we depend
each applications collectively, including a key phrase took me 36 traces. That’s simple to
assessment, simple to check, and straightforward to alter. It’s like technical debt doesn’t
exist.

“Okay, Gavin, however what does that must do with Paul’s thesis?”

Paul’s level is that including code is at all times extra technical debt. He mentioned,

Whenever you’re first constructing out an utility, you possibly can develop new options at
unbelievable velocity. There’s no want to fret in regards to the influence on present customers.
You may simply give attention to implementing new options.

Nonetheless, as an utility matures, growth velocity will inevitably sluggish
down. On a poorly applied product, growth velocity slows down shortly.
However even on a fantastically applied one, growth velocity nonetheless slows down
over time.

However that was not the case for these three options. They took me about two hours
whole, together with testing!

This was not the case once I began; I may take weeks so as to add simply one
new function!

So my growth velocity has elevated though my code has grown!

How a lot has it grown? This a lot:

And that picture solely counts information in embrace/, src/, and gen/. It additionally
excludes textual content information in gen/.

When you had been to plot the survival charges of code in bc, it might appear to be this:

And once more, that solely counts information in the identical directories as above. When you plot
the survival charge for your complete repo, you’ll get this:

Discover that the primary 40% disappeared in six months, however the subsequent 40% is nonetheless
not gone greater than 5 years later.

Additionally, do you see these small cliffs at varied factors? These are the place I did a
refactor to scale back tech debt.

There was a big cliff originally as a result of I used to be exploring and refactoring
as I went. I lastly settled into one thing good after six months, however I didn’t
relaxation on my laurels; once I noticed an issue, I mounted it.

Actually, I typically added code to scale back tech debt.

An instance is once I applied my very own file I/O in bc.

“Oh, Gavin…”

No I’m not.

You see, I’ve a built-in command-line historical past implementation, and that wants
uncooked entry to the terminal for apparent causes.

If I used the common file I/O, it might have “labored,” however I’d cope with
sticky points between it and historical past.

However by implementing my very own, I removed the sticky points and decreased my tech
debt.

Including code decreased my tech debt.

Paul is correct by rule of thumb, however I’d moderately not be dominated by
thumbs.

So let’s discover a extra exact “rule.”

The Rule

I already came up with one:

Your software program is making an attempt to unravel an issue, and each drawback has an unknown
form as a result of reality has a surprising amount of detail…

Technical debt is each place the place the software program doesn’t match the
drawback.

(Emphasis added.)

And it’s that straightforward: tech debt is when your software program (and the mannequin behind it)
don’t match the issue it’s making an attempt to unravel.

Properly, not fairly…

“Okay, Gavin, so what about our metaphor? Ought to we would like extra code or much less?
As a result of it positive sounds such as you’re advocating for extra code.”

Nah, much less code is higher, all else being equal. However “all else equal” is
lottery-rare.

I wish to suggest a unique metaphor: code/software program is an asset.

“Properly, what’s tech debt, then?”

Endurance.

If I’m going to go all in on monetary phrases, let’s add liabilities:

Legal responsibility

The amount of worth {that a}[n]…entity owes.

As a programmer, you owe the flexibility to unravel an issue. Something within the code
that doesn’t clear up the issue is a part of that legal responsibility.

So technical debt is admittedly code legal responsibility.

“That’s silly, Gavin; belongings can’t be liabilities, so your metaphor is incorrect.”

True, belongings can’t be liabilities, however they can have liabilities hooked up to
them.

For instance, say I purchase a automobile with financing; that debt is a legal responsibility even
although the automobile itself is an asset, and that legal responsibility is hooked up to the automobile.

In like method, code as an asset can have a legal responsibility hooked up that lessens the
worth of the asset.

It goes additional: you will be “underwater” on an asset. Because of this your
asset could also be value much less than the legal responsibility hooked up to it.

You may expertise this with code as effectively; when growth slows to a crawl,
you’ve gone underneath.

It could actually occur in two methods: the issue adjustments (your legal responsibility will increase) or
your software program turns into much less helpful (your asset depreciates).

“How can software program depreciate, Gavin? It’s simply code.”

node_modules enters the chat

If its surroundings adjustments, it could not run. And software program that gained’t run has
depreciated to nothing.

“However that doesn’t clarify your supposed ‘zero’ code legal responsibility, Gavin.”

You’re partially proper. I do hold updated on the issue, and I do replace my
software program to suit the issue.

The Interfaces

However that’s not the one cause I’ve nigh nil code legal responsibility and why you do
not.

Paul says, “Adding new assumptions increases debt,” and on this, he’s
appropriate.

However he’s assuming that including options requires including assumptions. When you
create and use interfaces correctly, few to no new assumptions are mandatory.

Don’t imagine me?

Do not forget that I added key phrases to my bc; all three wanted zero further
assumptions.

The parsing adopted the prevailing assumptions of the parser (parse as much as the
character you want and no extra) and the prevailing assumption of the digital
machine (take away operands from the outcomes stack and change them with the
outcome).

“However that’s simply since you had been making a programming language and will make
simple assumptions!”

Uh, this programming language is Turing-complete! That’s the very
definition of laborious in programming. It’s additionally laborious to creating a programming
language match the issue it’s made to unravel.

To wit: your interfaces ought to decrease assumptions.

I do that by:

• By no means programming previous my restricted potential.
• Strictly documenting interfaces, together with preconditions and postconditions.
• Strictly programming to these interfaces, adjusting one or the opposite as
  mandatory.
• Iterating till the interfaces are near good.

I do know I’ve succeeded when these interfaces make it simple so as to add stuff with out
intefering with different options.

The Mannequin

And but, that’s nonetheless not sufficient.

The final approach software program can have a legal responsibility is that it doesn’t match the mannequin.

The psychological mannequin.

“Programming as Theory Building” (original) is a well-known essay (which
it’s best to go learn proper now!) that makes use of the phrase idea for this idea,
however it’s the similar idea.

Regardless of the time period, the mannequin/idea is the software program because it exists within the minds of
those that create and use it.

After all, the psychological mannequin will probably be inaccurate; if it wasn’t, we might by no means
have bugs, so the different type of code legal responsibility is when the software program is
completely different from the psychological mannequin.

I repair this by testing, testing, testing. I fuzz with a crash-happy construct, and I
repair each bug.

“However how does that enhance your psychological mannequin?”

As a result of for me, one of many definitions of a bug is a mismatch between my psychological
mannequin and the truth of the software program.

So once I repair a bug, I’m carry my mannequin and the truth nearer collectively. And I
do that till they’re in concord.

The Prevention

I additionally do yet another factor that just about no developer does: I really design my
code earlier than I ever begin coding.

In different phrases, I construct a psychological mannequin, together with the issue that the software program
solves, earlier than I begin.

This retains my coding laser-focused on its goal and helps me stop
divergence between actuality and mannequin.

After all, I do must replace the preliminary mannequin, however an oz. of prevention is
value a pound of remedy.

And that is how I smash code legal responsibility.

The Different Factors

I suppose I ought to reply to Paul’s different factors.

Sure, that’s true, and that matches with my metaphor.

A function that doesn’t match the issue has destructive worth, however it’s nonetheless
an asset, only a dangerous one, like a junker automobile.

Sure, that’s true.

Code that doesn’t match the issue has destructive worth.

You heard that proper: that is only a restatement of of “Options can have
destructive worth.”

That is additionally principally true.

That is why I’m bullish on preserving code legal responsibility to a minimal from the beginning;
if I ruthlessly prune options earlier than they’ll entrench themselves, this
horrible reality just isn’t a reality for me.

I counsel you do the identical in case you can whereas nonetheless assembly your enterprise targets.

Properly, sure, however that is additionally like saying “to keep away from lacking in basketball, don’t
shoot.”

Code is an asset, however you want belongings to do stuff.

Simply do not forget that belongings want upkeep to stay above water. Write code to
clear up issues, and make it possible for code matches the issue. Keep it to maintain
it that approach.

Sure, that is nice recommendation; it’s the similar recommendation I gave above about assumptions,
though it’s best to change dangerous assumptions in case you can.

The Conclusion

Tech debt and code legal responsibility are hotly debated, so let me throw out my opinion:

• Code is an asset.
• Code can have a legal responsibility hooked up, which will be a number of of:
  • When the code doesn’t match the issue.
  • When the code’s inside mannequin doesn’t match the issue.
  • When the code’s inside mannequin doesn’t match the psychological mannequin of customers
    and programmers.
  • When the code’s inside mannequin doesn’t match the code’s inside
    interfaces.
  • And sure, when there’s extra code than essential to match the issue.
• You will be underwater on code; that is when growth stalls.
• Thus, code should be maintained, similar to another asset.

Am I proper? Properly, I’ll go away that so that you can resolve.

Let the debate rage on!