Working with both external companies and internal developer teams is always difficult when code quality is concerned.
Since technical debt is the most straightforward way to measure software quality, in this article I will try to explain what technical debt is and discuss the best ways to manage it.
What is technical debt?
As a startup founder/leader, you have to know that features can be implemented in at least two ways:
Fast and cheap
developers focus only on solving this particular problem.
As God commands
each feature is in 100% tested using automated tests, there are no duplications in the code (similar features are coupled) and architecture tries to predict future requirements.
Don’t get me wrong - those two approaches don’t make much difference from your users’ point of view. The difference merely lies in maintenance, as it’s expensive to manage more complicated code.
Technical debt, put simply, is the difference between those two ways. It says how much time/money you have to spend to convert each feature to "As God commands".
So where is the problem?
You are probably thinking now: so, where is the catch? - You will just write in your contract with an outsourcing company that each feature has to be tested in 100% without duplications and so on, problem solved.
Unfortunately, the Fast and cheap approach is sometimes the better one. Let's say you have a working product and you just want to check new feature that you think your customers will love.
Implementing this feature in the first (i.e. fast and cheap) approach will cost you just a single day of work, whereas the other way will take as many as 4 days. There is no reasonable need to spend so much time on it, since there is a risk that a week after the implementation of the feature it turns out people don't like it as much as you do, essentially forcing you to remove it.
That being said, it is key to be aware of technical debt and manage it.
How to measure technical debt?
There are a couple of online tools which help to you to manage technical debt. Which of them to choose depends on the programming language your app is written in.
There are two important things regarding the tool:
since you are working with an external team, the tool should be available online.
the tool should tell you at least about: duplications, test coverage and general complexity.
When working with an outsourcing company, please don’t forget to:
- connect code repository with an external tool for controlling technical debt - discuss each feature with your team regarding way they are going to implement it - if both parties choose to use Fast and cheap approach, don’t forget that in the future your team will have to improve quality As God commands.
Remember: Fast and cheap and As God commands are not technical terms. I just use them for convenience.