We spend a fair amount of time talking about technical debt. While there’s a fair bit of content to discuss around these issues, today I’d like to bring attention to the flip side of this issue. I call this concept, Technical Capital as it is effectively the inverse of technical debt. Think of Tech Cap as the accumulated value of your technology investments. An easy way to think about it is all the stuff you’d need to undo or redo if you were to implement a ground-up rebuild.
Superficially, this would be everything Joel Spolsky wrote about rewrites quite eloquently 18 years ago, https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/. Spolsky focused on the layers of bug fixes and domain knowledge that accrue into an application’s code base over time. But the full scale of technical capital extends significantly beyond the accumulated logic in your production application. In most organizations, the actual size of your technical capital extends into the 80% of your code that runs the business. This drives a tremendous amount of value for the company. This code runs your accounting, marketing, and logistics systems. It ties your HR and operations systems together and provides the full high altitude view of the company for executives.
Unfortunately, many people inside the tech org of a company are blind to most of the technical capital at work in the firm. Recently, I presented the Data Lake architecture to the product development teams within my organization. One senior dev who’d been with the company for over 2 years asked quite bluntly, “Why do we bother building a data lake.” He had no clue that over 70% of the code at work within the company existed outside of the primary application repository on GitHub. At the time, I was utterly blindsided by the question. The value of the Data Lake seemed well communicated within the org, but looking around the room, I realized that product development didn’t have a clue on the value. Since then, I did an analysis of lines of code committed in various languages across all of the corporate repositories in, and I’ve started including a slide in all of my roadmap and introduction presentations. Jaws drop when I demonstrate that the language of the production application is barely in second place for popularity behind Python and that R is almost equal in scale.
Another major issue when thinking about Technical Capital is how it maps into the company’s human capital. In a mature organization, especially in a sophisticated organization that embraces a self-service operating model, Many of the people with significant technical awareness don’t appear in a superficial glance at the org chart. Instead, they make up your organization's shadow dev org. This undocumented pool of expertise will need retraining if you ever engage in a significant rewrite.
I’m still working on my personal theory of technical capital, but I thought this would be an excellent introduction to the concept. This needs to be a factor in any significant technical decision. In my experience, most technologists are well aware of this to some degree. In particular, those with a technical background tend to be much less likely to cite “Sunk Costs” in arguments around pivoting from or otherwise abandoning previous technology investments. To be clear, I’m not saying to never discard technical capital in the name of innovation or technical debt refactoring, I’m just saying that you probably have significantly more investment to return to a steady state than you reasonably expect without a much more in-depth examination of your code and your Org.