Technical Surplus

Much ink has been spilt on the subject of “technical debt,” roughly, the difference between the code that we have now and the code that we would like to write if starting over. For the most part, the idea seems… unproductive? The most common nostrum for technical debt is to create a list of issues categorized as technical debt, with the intention of addressing them sometime in the future. Empirically, the fate of these lists seems to be to grow continuously until they are abandoned. There are some problems with this whole train of thought:

1. Explaining the idea to management is awkward. “How about we spend half a quarter actually finishing up the work that we claimed credit for last year?” Not a fun conversation.
2. It assumes that we will have more time in the future. The future is a busy place. To whatever extent we succeed, we will have more customers and they will want more stuff. We will never have more time than right now.
3. It assumes that we will actually be able to create a technical surplus in the future. And this, is the elephant in the room.

Seeing a better solution to a problem that you can actually implement is a skill; in fact, the fundamental skill of computer programming. It takes a surprising amount of skill and effort to make software which “just works.” When you add something to the list of technical debt you are simultaneously declining to practice this skill and making a type of judgement known to be fragile: “I could do a better job!” If you don’t want to be an armchair quarterback, you need to be throwing the football. This is the crux of what Fred Brooks dubbed “the second system syndrome,” a common pattern in which the team which built the first system decides that all technical debt must now be repaid in a “second system” and the rewrite then fails. Which proved that what they actually had was not some exotic disease, but a common case of the “first system syndrome.” The same people doing the same things will yield the same results.

Unless you are actually gaining skill at producing a technical surplus by producing one right now, there’s no reason to believe that you will be able to reduce technical debt sometime in the future. So, let’s talk about “technical surplus,” that pleasant surprise that you get when some sketchy, edge-case laden expression “just works” or you find that the function that you need has already been written.

Who is going to pay for technical surplus? Nobody! It is a surplus. The market is paying for median quality industrial computer programming, “good enough.” What produces a technical surplus is “best.”  In any given month, you can do “good enough” or “best” and collect exactly the same paycheck.  A company can’t tell the difference - there’s no metric.  However, as an investment in yourself, “best” is dramatically better.  Best compounds, 1.04 x 1.02 x 1.01 x... Next week’s best is better than this week’s best. A decade of doing your best will take you surprisingly far. “Good enough” also compounds, 0.83 x 0.72 x 0.92 x... but not in a nice way.  A decade of good enough is a recipe for burn-out: feeling that you are somehow accomplishing 20% of what you are capable of while watching that aspiration become less and less plausible with every passing day. The older you get, the more prominent the interview question: “Tell me about a technical accomplishment that you are proud of?”

If “good enough” is what a company can discern, no alarm bells are going to ring if you happen to hand in “best,” right?  There’s a wonderful story about this from Amar Bose. The whole farewell lecture is worth listening to, but the ten minutes following the link bear exactly on this question. The philosophical underpinning here is stoicism. With the freedom to act that you do have, what are you going to do?  What if you took an extra 20% of your time and spent it on “best?” Nobody has to give you 20% time.  No employer does everything twice so they can fire the slow guy.

Suppose you debug a problem and arrive at a change like this as the fix:

123c123
< Foo(..., true);
---
> Foo(..., false);        

Fantastic! Unit test. Commit. Deploy. Mark the Jira as “fixed.” Done! Well, that is “good enough.” What does “best” look like? Here are some thoughts to explore:

1. The fix, a 1-bit change, is not improving quality.  Suppose that you actually got the fix wrong.  The next person would have exactly the same debugging experience that you did.
2. The API in question is error-prone. It is highly likely that the boolean value is a cheap stand-in for a two-item enumeration like, “LEGACY, NEW_HOTNESS”. Using an enumeration saves the reader having to visit the implementation of Foo to see what true means.  Now, you have improved quality.
3. How was this error detected? Unhandled null pointer exception? But there are about a thousand of those per hour so nobody noticed this one. That original “silent failure” allowed data corruption to propagate until it caused a “loud failure” that somebody noticed. The longer the chain, the harder to debug. Can you fix the error handling? Can you add assertion checking to consumers of the corrupt data? These changes are improving quality.
4. Did anyone else make the same mistake? Survey all the call sites. This sort of thing is why naively managing to the “time to fix” metric is counter-productive.  Fixing the same copy-pasted mistake as 19 individual bugs with each with fast TTF is a travesty.
5. How did this error make it into production? Clearly, the code in question wasn’t exercised by integration testing. Fix that. One happy outcome of integration testing can be the discovery that Foo was hard to test because it isn’t actually necessary. Maybe you can delete some code? Code deletion is actually a key signal of software health.
6. What about this creates value for the customer? Your attention to this problem is one of the best signals that somebody cares about what the code is doing. And, that this area of the code is low quality.

If this reads as “do a mini post-mortem” for every change, that is exactly the intent. It is difficult to improve your own code without some external stimulus. Everyone tends to debug the compiler rather than the code that they just checked in.  However, once you’re in the mode of fixing a problem it is relatively easy to exploit the crisis for improvements to the surrounding code. “The Errors of TEX” is an early example of one of the greats creating technical surplus.

While there are a lot of happy old stoics, everyone does need to get paid. While it is the case that companies can’t distinguish between good enough and best, they do seem to be able to tell the difference between people who have been doing their best for ten years and those that have been doing good enough. And, other people can certainly tell the difference. Best inspires and attracts both followers and mentors.