Tackling technical debt with Engineering Lead, Tooraj Helmi

Daily decisions are part of any job, but what if every workplace predicament proved to be a double edged sword, and you were in charge of making the call? For Builder's Engineering Lead Tooraj Helmi, this reality, a concept referred to as technical debt in the software development world, simply comes with the territory. For their article, "How 9 Software Engineering Teams Deal with Technical Debt," the Built In blog talked to Tooraj about the idea itself, his approach, and everything else audiences need to know.

What is technical debt and how does your team define it?

Technical debt refers to the prioritization of short-term gains despite the longer-term troubles that may arise. It’s the understood trade-off that results when our team decides to experiment and gather knowledge in support of immediate agility rather than plan and build with future efficiency top of mind. As a startup with global offices and engineering teams working together across the world, we are naturally prone to technical debt.Just recently, my team here in LA had a dependency on a product being designed and developed by our team in India. Their part of the project was going to take three months, so we had two choices: put things on hold and wait for them to complete it, or create a simplified version of the product to fill the gap and move things forward for the time being. After a cost and benefit analysis, we chose the second approach, prioritizing short-term progress even though we knew that the placeholder product would be disposed of in a few months.

When technical debt does occur, what process does your team use to measure and manage it?

If there is an understood long-term disadvantage involved, we always conduct a cost and benefit analysis to see if the short-term benefits outweigh the costs. We consider the cost of reintegrating with the new system, the cost of retraining employees and customers, and the cost of transitioning from the sub-optimal product. If it makes sense to move forward regardless, we then make sure the decision to increase the debt is communicated to stakeholders who might be impacted by it.

What proactive measures does your team take in minimizing technical debt?

We want to provide the best start-to-finish service to our customers, so our team plans for long-term optimization as much as we can. Rather than focusing on a client’s product in isolation, for example, we always try to look at the end-to-end production chain as a whole and consider what gaps may arise. If we spot something, we immediately gather the relevant stakeholders together, review our choices and come up with the optimal plan to minimize the technical debt.

In cases where technical debt can absolutely not be avoided, we build the short-term products with maximum reusable components. Using an architecture that allows for decoupling helps us easily eliminate the sub-optimal products as needed.