Introduction

We’re all familiar with the idea of technical debt in software, where the velocity of development is hampered by code not being ideally suited for the task at hand. Maybe the task changed, maybe an engineer had an idea that didn’t turn out so well, maybe the data model forced an unnatural shape. for more on technical debt O’reilly has a good article on it

This technical debt has costs in reducing project velocity, or making features harder to implement. In financial terms you’ll probably ending up paying off the original debt along with interest (the drag on the project).

This entire metaphor works around things like mortgages or credit card debt. I borrow money from the bank and have to repay that money plus extra (interest).

However, at the bank I also have a checking and savings account that pays interest to me for keeping my money at the bank. Or dividends earned on a stock purchase: when you sell off your stock purchase you’ll have both your profit from the sale and the dividend money.

We don’t think about this other side of the financial equation that much: what about code, designs, or tools so good they give a team velocity?

This “technical interest” or “technical earned interest” pays off at an individual codebase level, but especially pays off - in a compound interest type scenario - when applied in an “economy of scope” fashion.

And Economies of scope

Economies of scope (https://www.investopedia.com/ask/answers/042215/what-difference-between-economies-scope-and-economies-scale.asp) says that when an item is used by multiple products that means the average cost of producing that item goes down.

One simple way to think about economy of scope is to imagine that it is cheaper for two products to share the same resource inputs (if possible) than for each of them to have separate inputs.

So how does this apply to software?

One time I was brought on to rescue a Rails project, written by a relative Rails newbie (who of course went MIA), with no tests. Lots of duplicate code, logic where it maybe shouldn’t have been, etc. And the business owner wanted to do a re-theming of the whole site. So first thing I was was to identify an area with the most duplicated code (in the “generating the HTML” part of the application), then wrote unit tests around that code. I then extracted the code into a common library and called the library from all of those places. Because of my previous investment in unit tests I validated that my refactoring worked. I then had a single, common, place to start my redesign efforts, compounding my earned interest (instead of doing that work 8 times I did it once!). Because of my automated tests I knew that my code continued to work in all eight spots, even though I changed the internals of exactly what HTML was generated.

The cost of that common library in that Rails re-theme project has an economy of scope. There are likely other places in a codebase (or even microservice herd!) where common libraries, patterns, etc can be extracted for potential “change it once, reap the benefits everywhere” technical earned interest.

More examples of technical earned interest

Technical interest isn’t only something created by code reuse. In fact, earlier versions of this blog entry called it “technical solution earned interest” because architectural patterns, tools, standards or DevSecSREOps practices could also pay interest.

An example is bringing some new software into the business. Even a license to Microsoft Excel has massive technical interest returns: I’ve seen people not just crunch numbers with Excel but keep meeting notes in it, draw arbitrary diagrams by filling in cells, use it as a simple list maker, or an interface for a low-code solution. Multiple uses for the same tool.

When evaluating software solutions to bring into my projects I tend to prefer bringing in small, lowest common denominator tools that be reused multiple places in creative ways with simple APIs, vs monolithic tools that can be configured to do anything with a bit of learning. I find that I personally get more compound interest out of these small solutions loosely coupled together and only used for what they do best, than with some massive “do everything” tool. Excel is not really a good tool for making simple lists after all.

Ideally after a project’s initial foundational growth planes, where everything is so new, we have a common set of libraries/tools/standards etc with a high economy of scope and thus changes or enhancements around those products will return technical solution interest: potentially compounded by choices made earlier in the project.

Some projects call this common set of libraries etc a “software engineering platform” or “developer experience”.

The larger your microservice herd is likely the more you’ll want this software engineering platform. The end of my Herds of Microservices article talks about the feature capacity of a microservice herd. Changes to the developer experience for the developers on the project pay interest almost immediately, across the herd.

Take a project with 50 developers on it. Make an investment that turns common, weekly, two hour long process that every developer has to do every week into a one hour process. = 50 * 2 = 100 hours reduced to 50 hours per week. Fifty hours a week feature capacity increase! (An extra developer per week in feature capacity, at least on paper!)

What’s even better is “hey we’ve made this one change in a common place, you can get it for free”. That’s both great developer experience, and makes everyone happy especially if it increases the feature capacity of the team(s)!

Technical Earned Interest, but in other industries

You find this idea of technical earned interest elsewhere on the web. Will Larson author of An Elegant Puzzle uses the word “technical leverage”.

Range: Why Generalists Triumph in a Specialized World calls this “empowering leverage”.

In fact, we can see this concept of technical earned interest in sales (sales asset productivity)

Conclusion

Your engineers likely know where there’s places for economies of scope in your project. A refactoring initiative is sometimes to clear up technical debt and sometimes to enable technical earned interest in the future.

For example, adding automated tests to a codebase that has none is an example of both technical debt at the start and technical earned interest at the end. Automated tests are something that probably should have been done in the first place but wasn’t for whatever reason (a technical debt tradeoff). Once tests are added it pays interest back in the ability to reduce defects (because you caught them while still writing the code!), ensure things worth together, etc.

Likewise, establishing patterns of architecture, how to get help from subject matter experts, common build / release / deployment patterns all are investments that will likely pay interest back, especially in an “economies of scope” situation or building one good thing on top of the other in a compounding earned interest scenario.

Yes, as the environment changes what felt like a good decision at the time becomes technical debt to clean up. Code reflects both the organization that created it and the business environment it’s desiged to support. Change either of those things and you have code that no longer reflects the ecosystem well. (Contrarywise sometimes people do their best they can with the knowledge and constraints they had at the time, but sometimes those initial decisions are outgrown).

Yet the often-forget corollary to debt is investment: decisions so good they enable faster, better, easier software development. That’s technical investments earning technical interest.