Intro
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 for your own money or use credit, generating debt? Of course, it seems safer not to have any debt and don't pay bank 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 dept, solve your problem and pay the debt in the nearest future.
It works exactly the same way with the 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.
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 5 days or clear the code first, wasting 5 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 will top management 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 5 days, not in 8.
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 5 days, not in 8. 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 not 6 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 asking other CTOs a couple of questions. Here are the tech-rockstars who kindly agreed to help me:
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 to release a new feature quickly and not pay enough attention to its integration in the overall architecture? In what cases can this be done?
In my opinion, it is worth releasing a new feature quickly for demo / MVP purposes, only to add customers to the pipeline of the business.
One can also pay less attention to integration if the overall design is reasonably distributed, with the right microservices / serverless components.
Otherwise, if the business relies on the happiness of one or two customers - you do based on what they need.
- Manish Jain, Co-founder, CTO at Avata Intelligence
Very few times. You'll either break something, or require much more rework which can be disruptive. However, if there's no implications to a data model, or it's stand-alone, and it makes the users happy, do it!
It's all about the users.
- John Gwinner, CTO at CareLabs Healthcare
3) Is it true that sometimes the fact of a product deployment is more important than it's quality? Why?
Never. Crap will ruin you. You must be obsessed with customers and only deliver quality or deliver nothing.
- Mark Anthony Morris, CEO/CTO at Hempchain
Yes, if the overall design is reasonably distributed, with the right microservices / serverless components.
- Manish Jain, Co-founder, CTO at Avata Intelligence
Rarely - but possibly for a proof of concept.
- John Gwinner, CTO at CareLabs Healthcare
4) Who should be responsible for a low-quality product if the company has set the task to complete at the exact time, but developers have warned that the deadline is too soon?
This should never be the case and is a symptom of a doomed and diseased company--fix the root cause for this, be it replacing management or the systems and processes utilized.
- Mark Anthony Morris, CEO/CTO at Hempchain
As the CTO, I have visibility both in the development and the management. I think the buck stops at me for I am the only one with the role that needs to understand both sides.
- Manish Jain, Co-founder, CTO at Avata Intelligence
Management. Often the developers are blamed, however.
- John Gwinner, CTO at CareLabs Healthcare
5) Is it possible to change the practice of uninterrupted completion of new features, and concentrate on a high-quality and minimalistic list of functions instead?
Yes, advanced CI/CD pipelines and product teams can push a continuous flow of features and facilitate outcomes via advanced integrated AI agents that control the transmission, reception, quality, effectiveness. and efficiency of the elements be it page layout, color, content, logic, or any other functional or non-functional aspect of the customer experience and company goals.
- Mark Anthony Morris, CEO/CTO at Hempchain
After receiving those answers I want to make my conclusions:
First of all, we can see that the problem is absolutely natural.
The company wants to have more clients to survive. Nobody knows how many clients will come tomorrow. That is why gripping for more features is natural.
As a result - the whole team has less time to make sure everything works smoothly. Moreover, the company wants to be kind to every client because you never know what satisfies users most. That's why you try to make everything that the client wants. Every stupid feature in the shortest time.
I believe that the company must establish partner relations from the very beginning. When you are a startup - you have less to lose. At that moment try to explain to every client that sometimes you know better. Just because it is your work. You will see, that it is absolutely ok.
Fast but not too fast
Rapid development is good. Try to implement new features fast especially it is a demo or beta version. Customers must be aware that it is not perfect yet.
After that, you will have some time to make a stable version. It is a good idea of how to find a balance between market needs and technical possibilities.
Also, you have to develop a proper product vision. Because making software is always about satisfying users' needs and winning the market.
There is no versatile answer
The third question is the most contradictory. The answer would be obvious for one person, but it is not obvious in general. In my opinion, one has to rely on their own experience at this point.
As my fourth question was also a little bit provocative, I become very different answers. Nevertheless, my conclusion is simple.
If you see that something is going wrong - figure it out. Your work must be done perfectly. If the result is bad - both sides must solve the problem. The worst situation is when the management blames developers because it has the power to blame.
Summary
As a business, you have to be client-oriented. Moreover, you have to make profits.
Try to implement everything your client wants. Try to do it fast.
However, make sure you have enough time to make your product sustainable and not be afraid to explain users that you need additional time when you really need it.
Finally, be natural. Remember that the client is very important. But your work is also important. The company is important, but every employee is important too. If you will keep it in mind, it will be easier to find a balance between everyone's needs.
Go ahead and good luck!