The concept of being in debt of any kind is typically not attractive, so the term “technical debt” can sound intimidating. But in the same vein that monetary debt can be beneficial to building credit, a company’s technical debt can signal growth. And when tech debt is accrued and “paid back” intelligently, it can lead to some major wins for companies.
But what does tech debt look like from company to company? And how do different businesses leverage their debt to evolve? We asked a couple of Boston tech companies to find out.
Piaggio Fast Forward’s Lead Robotics Engineer Carlos Asmat said technical debt shouldn’t come as a surprise to anyone at a tech company. Accounting for this debt “is more of an art than a science,” he said, and is a necessary part of good business strategy.
What is technical debt and how does your team define it?
Any time corners are cut, a team acquires technical debt. On the software side, it might mean hardcoding a parameter that should be more readily configurable. Inevitably, someone will need to come back and redo the entirety of the work that was partially done. This saves time on a fraction of the task now, at the expense of needing to redo the entire task in the future. Just as with real debt, it is more expensive in the long term than working with the available budget.
Evaluating the consequences of debt, much like estimating the time a task takes, is more of an art than a science.”
When technical debt does occur, what process does your team use to measure and manage it?
Acquiring technical debt needs to be a conscious decision, as opposed to the result of someone getting lazy with a task. This is decided during planning sessions and the time for the work is accounted for in consequence. However, evaluating the consequences of debt, much like estimating the time a task takes, is more of an art than a science. It needs to be accounted for down the line in the overall schedule and not ignored, or else it creates more technical debt.
What proactive measures does your team take in minimizing technical debt?
When wanting to move fast and forward, acquiring technical debt is inevitable. An approach we take is to acquire debt in domains outside of our core competencies, like on tasks that will need to be outsourced. This uses the resulting work as a draft for the requirements of the tasks to be performed in the future. Ultimately, this allows us to be more impactful but invest time in the areas where the most value can be added.
Forward Financing’s VP Product Management Michael Kessleman, Senior Product Manager Ali Fawaz, and Software Engineer Team Lead Kelvin Ma provided insight into the merits of having some strategic technical debt at their fintech company. They said that the business has dedicated action plans on estimating, planning out and paying back technical debt built into its infrastructure.
What is technical debt and how does your team define it?
We define technical debt as the expected cost to rework existing features or components of a system to better support the longer-term needs of the organization. Technical debt is incurred when the business is facing either an opportunity or an immediate problem such as an unanticipated edge case that is disrupting the current system.
Sometimes, we build a feature fast, fully knowing that it may need to be replaced later. When features are built quickly to meet an immediate business need, we plan to incur some short-term technical debt. In this instance, a quick fix relieves pressure on the current business environment while giving the development team the time to more strategically “pay down” the technical debt later. The cost of the quick fix can be easily weighed against the benefit that the feature delivers to the business.
As we continue to grow, we are willing to take on technical debt in order to meet the changing landscape and needs of the business. When technical debt is incurred as a result of exploring a new opportunity, the strategy is to minimize the investment until the value of the feature is proven, ultimately avoiding the cost of over-engineering. In this respect, technical debt is a great counterbalance to over-engineering, particularly when the additional cost is high and the expected benefit is still unknown.
In both instances technical debt allows us to meet the needs of the business while making appropriate plans to go back and review the feature to make sure that it is built soundly, to scale and that it will perform optimally.
We consider technical debt as a sign of growth and a necessary tool in most software development.”
When technical debt does occur, what process does your team use to measure and manage it?
We consider technical debt as a sign of growth and a necessary tool in most software development. We’ve seen significant growth over the past few years, which requires us to take on technical debt and review some of our systems to be sure they can handle the requests, keep up with the velocity of business growth and continue to plan for future growth.
When the business requests a new feature or capability, our team will gather the requirements and estimate the effort. When the estimation is much higher than anticipated, it’s usually a clear sign of some outstanding debt on our technical “balance sheet.”
The reasons for reducing technical debt are usually to either increase the overall stability and flexibility of the existing system, or to improve the productivity of the development team. For our team, taking on technical debt is a responsible action plan which allows us to plan proactively.
However, technical debt can have some significant implications for any business if it is not effectively measured and managed. So, our development team goes through an assessment process and acts proactively to allocate time to “pay down” technical debt during sprint planning and backlog grooming.
What proactive measures does your team take in minimizing technical debt?
We have multiple processes set in place that will help us to proactively minimize technical debt including sprint planning, proper grooming of feature work before development begins and test coverage. There are velocity assessments — if our team is losing velocity, this is a good indicator that tech debt may exist. We have automated checks for things like test coverage and code smells that help us to uncover any problems that may implicate a deeper issue or uncover any weaknesses in design. We have a tech council — a meeting that includes our longest-tenured engineers who have historical knowledge of system architecture as well as some subject matter experts that are most familiar with particular features. This meeting allows us to assess technical debt at a macro level and helps us to collectively plan large initiatives.
