[gen220]

I'd like to share a related theory I've been thinking about lately, which applies some of the ideas latent in this article to software engineering.

1. Code is a liability.

2. Therefore, adding new code to your codebase is adding liability to your codebase, at the margins.

3. Refining/documenting code at the leaves transforms some of those leaves liabilities into assets.

4. Refining/documenting code in the branch/trunk transforms some of that branch's liability into an asset, but usually undoes any progress made in the leaves.

5. We are paid to (a) create liabilities and (b) transform liabilities into assets. If you do too much of (a) and not enough of (b), you are a bad engineer.

The fun thing is that you can analyze a software program like this (module A is a leaf to module B). You can also analyze the whole stack like this (Redux is a leaf to React, is a leaf to JS, is a leaf to Chromium, is a leaf to Intel, is a leaf to the Van Neumann model).

This ties into the article, because engineers don't "just" solve problems (unless you're Van Neumann?). Usually, we first create a problem (which is usually the dual of problem we are nominally paid to solve), and then we very slowly and iteratively "solve" that newly-created problem over time.

It sounds somewhat Sisyphean, but that's life/evolution! It's a joy to see things slowly crystallize into highly-functional, specialized components. Even if those components will inevitably become obsolete one day, they will still make for interesting fossils (see Zork's source code, dinosaurs, etc.).

[la_barba]

Hmm, but how do you establish whether a piece of code is a liability? Do you account for QA finding no issues, or do you weigh it against the number of years its been used in production, or do you consider that it was written by expert rather than a novice, do you take into account the fact that it was purposefully designed, as opposed to organically etc. I think your theory is nice, but a bit too reductionist to be applicable in the real world..

[gen220]

I agree that my theory is reductionist, but on the flip side, that also keeps it simple and interesting to talk about, like we are now :)

I start with the very debatable axiom that all new code begins its life as liability. I've argued this in the past by deduction:

You type a single character into your editor, and (depending on the change, and your language's execution story), you've probably broken your code. Type a few more characters, and it is now less of a liability, because it compiles. A few words more, and it is less of a liability, because it accomplishes some small task (imperfectly). By the time you have committed some set of changes into version control, you've hopefully ironed out the liabilities. But, it's entirely possible that you've created more liabilities than assets. Code review hopefully refines it further, but things still sneak through. I could keep going, but I think this is clear?

Measuring the liability:asset ratio for a given piece of code is a challenge, and is more qualitative than quantitative. I believe that this is also an argument in favor of "new code is a liability", otherwise code review should catch all of our mistakes.

But yeah, I have found it to be useful "in the real world" as a heuristic for thinking about how code bases evolve over time. I do not think that it translates into a hard-and-fast rule to weaponize in code reviews. However, it does temper your expectations about the fallibility of code, and it is also a convincing argument for code review as a quality-control process.

[la_barba]

Sure, but there are several arguments for doing code reviews/QA/etc that are already convincing. Its interesting.. but I guess I don't see how we can use this new way of looking at code transformations to our benefit.

[Grimm1]

The thing is even if QA and testing is fine now as the business or domain needs evolve over the years just the fact the context has changed can lead that code to be a liability. I'm kind of tired from work so I hope I can make my point: As an example, let's say you have a billing system that allows anonymous payment that works fine it has thus far been an asset, but new legislation is released that states that all purchases must have legal identity associated. Orwellian thought aside, some or all of that code has transformed into a liability depending on how deeply ingrained anonymous payment is and whether or no you can extend the existing code or you have to rip it out. Your code can be perfectly functional but a change to the domain need rendered it a liability.

[gen220]

Interesting. I like this a lot.

All Code implements a process. If the requirements for that process change (due to shifting regulation, for example), the process is a liability until it adapts to those requirements, at which point it can again become an asset.

If a process has no artifacts for implementing it, it can’t be a liability.

That’s why we see so many companies offering regulatory compliance as a service, in the healthcare space for example (AHIP, NIPR). Because if every insurer had to write code that integrated with regulation, they would be writing a lot liability. Using a vendor allows them to offset that liability to a third party, whose whole purpose in existence is to maintain a nice liability:asset ratio.

Perhaps we’ve found a utility for my theory, in contributing to the build vs buy discussion :)