Introduction

There are three things that caused me to write this post.

1. I found this blog post.
2. I just added three features to my bc.
3. I’m about to write a post about professionalism in computing.

And this post is the one thing those three things have in common.

The Blog Post

“The Disproportionate Influence of Early Tech Decisions” basically says that decisions made early in a project lifecycle tend to stick, even if they were intended to be changed. In fact, as it says,

software has inertia.

This is an important point to remember.

But there is something else that people don’t seem to remember: software has inertia from the first written character.

Of course, people instinctively know this, but they forget because they call the principle by another name: technical debt.

So the blog post was just about technical debt.

However, at the end, he says that companies should maintain a balance between velocity and maintainability.

This is a common misconception, that velocity and maintainability are mutually exclusive. I honestly don’t know where it came from, but it’s completely wrong.

To illustrate…

New Features in My bc

I’ve written about my bc plenty, and that’s because I’m proud of it. It’s had very few memory bugs despite being written in C.

There are many reasons for this, but the biggest is that I am religious about removing technical debt. I remove technical debt before making any change.

This means that in a period of less than two hours, I managed to add both features, test them, commit them, and be confident that the features are not only bug-free, but that the feature did not add bugs elsewhere in the project.

The key word there is “confident”: confidence is my secret weapon.

Confidence is what allows me to program entirely in my limited free time, implementing my own software stack, in C. Confidence is what allows me to quickly add features to a piece of software. Confidence is what gives me velocity.

And to have confidence, I strive for the highest maintainability possible.

Professionalism in Computing

Isn’t that what we, as programmers, would do if we were professional?

Wouldn’t we strive to make our software be as maintainable as possible?

We should. Getting rid of technical debt also makes software cheaper in the long term.

The reason for this is because the “interest” of the debt, which is the extra work required to make a change, is exponential.

That’s why that, on legacy codebases, no one dares make a change, for fear that something will break. This is also why useful development on a new project over time until people have it in pure maintenance mode.

Take away the technical debt, and that goes away. Remember that I said I changed my bc with confidence that adding features did not add bugs elsewhere?

This means that, in the long term, getting rid of technical debt makes software cheaper.

Why does this work? Think of it this way: your software is trying to solve a problem, and every problem has an unknown shape because reality has a surprising amount of detail.

When you start building the software, you build it with a shape that does not match the problem.

Technical debt is every place where the software does not fit the problem, and eliminating technical debt means you learned more about the true shape of the problem and remolded the software to fit that understanding, making the software fit the problem better.

With enough time, your understanding of the problem becomes nearly perfect, and your software fits the problem nearly perfectly.

Then, when the problem changes, as is inevitable, you only have to change the software to match just that change.

It’s true that the “cost’ to eliminate technical debt seems high at first, but that’s because you have no idea how bad the future codebase could be when you start.

This is the greatest mindset change that managers and developers need: we see technical debt elimination as a cost to be worked around, when it is a requirement for the health of a project, and it is cheaper the earliest it is done.

After all, would you really want to skip your dentist visits until you either need invasive root canals or lose your teeth just because you don’t like sitting in that chair?

Enjoyment in Programming

There is a nice side effect to getting rid of technical debt: I enjoy programming more.

Technical debt is a heavy chain, and it only gets heavier.

Of course, I hate starting a new project because of the many refactors I do to get rid of technical debt, but once I get a project started, I really love it.

So if your new project is going to last longer than a few months, do eliminate technical debt. You will spend less of those expensive developer salaries, and your picky developers will probably be happier too.

My Process

While the Hacker News comment I made talked about my process in vague terms, I should talk about it in detail.

Here it is.

This process is in the form of a checklist because I’ve read The Checklist Manifesto, and I am a wannabe pilot.

I admit that I don’t follow this process religiously; I use it more as a checklist to know when my software is ready.

However, I do follow the design-first part of it. I do gather and document requirements. I do design work. And I do all of that before writing any code.

The end result is that the influence of my early tech decisions is good because if they weren’t, I changed them early so that bad early decisions were all replaced by good ones.

Conclusion

Seriously, spend the developer time to eliminate technical debt. Do you really need velocity for a quarter when you know that your codebase is so bad that your velocity barely matches that of a snail in molasses?

Pay the cost. If you can’t, you should probably look for a new job where you can start a new project with a team that will kill technical debt as passionately as when you first started programming.