What are Technical Debts and Assets?

Technical debt is not just about missing features, it includes problems that you know you must solve, like known bugs and errors in your code, code readability, and any bloat you might carry. Slowness in build and execution time also needs consideration. Being honest with yourself about your technical debt ahead of time is crucial. The more problems you have to solve, the less you get to work on problems you want to solve. Therefore, treating technical debt the same way as financial debt is necessary, paying it down while avoiding more.

The rule of thumb should always be to pay off your debts first, then start accumulating assets. This is because you don’t want to try to pay for assets when you have debts holding you down. The accumulation of technical debt may cause the developer that comes after you to pay it off, which is a perverse incentive and why debt can be dangerous in any setting. As the old Levantine Proverb says, “The Debtor is slave to the Lender,” meaning you will lose power over your code.

The popular mantra “Move fast and break things” is more akin to “Put it on the credit card” in technical terms because it implies fixing problems later. Every break has a cost that needs payment, and the more you break it, the more you pay for it. Humans also have a tendency to overestimate their abilities and underestimate risks, which is why they procrastinate on solving problems. Putting off problems we need to solve for later makes us assume that we can solve those problems later, and it makes us assume we can solve those problems in a much more limited timeframe than if we had done it sooner.

Investing in technical assets upfront gives you the freedom to code without the fear of regression and choose what problems you want to solve. Technical assets are not about future-proofing or building a feature early, but rather an early problem solved. They are an investment into a known problem that from experience, you know that you, or those that come after you, will have. In the same way, experience will tell you whether a financial asset will make you money.

As a Startup you want to become an asset building business. The process of finding technical assets to invest in requires planning and discussion like investors. Presenting a prospectus about what the investment would look like and the tradeoffs is crucial. Building out automated CI/CD and managed deploys ensures less pain for your company long term.

Remembering the Lindy Effect, choosing implementations that have proven themselves sturdy over time may be the best approach, even if it may be counterintuitive in the software industry to choose things that have been around for a while. Just like any bad real-world investment might force companies and organizations out of the market entirely, a bad technical investment might do the same for tech companies. Therefore, you have to pick the processes that have been proven effective over time and across companies. Adopting those successful processes as technical assets allows you to accrue them for yourselves but not at the expense of paying off your technical debts beforehand. This discipline helps you avoid the “put it on the credit card” mindset earlier in your process, giving you the freedoms you need to work on code you want to work on instead of stuff you know you have to.