The metaphorical technical debt concept has become a buzzword in the business environment. This concept is one of the most common reasons for CTOs’ resignation from the most prominent tech companies. To properly understand the phenomena of technical debt, we would need to use the economic definition of debt.
What is debt?
So, what is better: buy something from your own money or use credit, generating debt? Of course, it seems safer not to have any debt and not pay banks their interest.
However, if you want to make a more significant investment — you would need to crack your budget. At that moment, you need to make the right decision. Is the investment worth it? If positive, then you can generate a debt, solve your problem, and pay the debt in the nearest future.
It works exactly the same way with technical debt. You have a goal to generate a certain product. You deploy it quickly, include all the necessary features, and the result is ready.
However, the module structure in a codebase is confusing. That’s where it all begins.
The question is how to deal with this cruft?
Cleaning up the modular structure, removing that cruft, will take a few days.
So, maybe you shouldn’t waste additional time. If the crew will have a new task to add some features, you could make the product more appealing for the user.
Should we add this feature to existing, unclear code and waste five days or clear the code first, wasting five days, just to be able to add the new feature properly?
Pretty much every CTO would insist on the fact that it is crucial to clear up the structure first.
Yet, time is money. Often a company needs to finish work as soon as possible. Guess what decision top management will make? (Considering that their initial goal is to grow profits).
Exactly! In most cases, they want a crew to finish up the new feature in five days, not in eight.
On the other hand, we must understand that the whole company is paying the debt. The company pays for its debt by releasing its product in five days, not in eight. Right after that, management created a plan for the deployment of new features in the nearest future.
At this point, the modular structure of the code will have even more problems. Now, adding new features will take six days without fixing the problem.
Sacred circle
We’re facing the old problems again. And the company must make a decision again. Waste some time to clear the code? Or just add a feature instantly?
Technical debt grows. Maybe we can pay for it by realizing our product as soon as possible? Maybe.
The truth is that short-term benefits from early deployment will be insignificant, comparing to the resources waste to fix the whole structure at the end of the day.
The situation would have been absolutely different if we invested those few additional days at the very beginning.
CTO vs. CEO: The truth is in the middle
I’m a CEO and of course, my motivation is to generate profits. However, I definitely want to do a long-run. I realize that the company is not just a business. It is a team of professionals, and they should have a proper environment to do their job.
That’s why I want to research the problem better and ask other CTOs a couple of questions. Here are the tech-rockstars who kindly agreed to help me:
Mark Anthony Morris, CEO/CTO at Hempchain.
1. Mark Anthony Morris, CEO/CTO at Hempchain.
2. Manish Jain, Co-founder, CTO at Avata Intelligence.
3. John Gwinner, CTO at CareLabs Healthcare.
Here’s what I got as a result of these interviews
1. How do you find the balance between the needs of your business and the capacity of the development team? What is the biggest problem?
“Outsourcing. Maintaining customer obsession and quality of output.” — Mark Anthony Morris, CEO/CTO at Hempchain
Often times when we face this issue, it is because the business needs are conflicting.
To make a customer happy, they want to say yes to the custom features (i.e. more development). Then, the business needs are to have multiple customers, and less time to deployment (i.e. platform-esque COTS solutions).
When we face these issues, it is about discussing the focus, short-term vs. medium-term requirements and then making a decision.
"The biggest problem is uncertainty — we don’t know how many customers we will get, or how critical the happiness of one customer is to the cash-flow, and that creates stress and conflict." — Manish Jain, Co-founder, CTO at Avata Intelligence
"Business usually thinks development is easy. Had one guy say: “Are you finally done?” I asked them how long it would take them to do it. “I can’t do that”. I asked why they thought they could estimate it. They were finally thoughtful." — John Gwinner, CTO at CareLabs Healthcare
2. Is it worth releasing a new feature quickly and not paying enough attention to its integration in the overall architecture? In what cases can this be done?
