Technical Debt and the Meaning of Done

The term ‘done’ in the technology world means different things to different organizations. But having a clear definition of done may help your organization reduce its amount of technical debt.

Technical debt is incurred when a team overlooks certain aspects of code in order to hit a target sooner. It’s referred to as technical debt because it’s like taking out a loan from the bank, for which you have to make continuous payments on in order to lessen the principal. Typically, you take out a loan to buy something now for which you don’t yet have the funds to pay. In development, this typically means making coding or design decisions that are good enough for now in order to get something into production super quick. But while you were able to release on schedule, the result means having to return to it later or spend time refactoring or patching things up.

Most times technical debt is incurred deliberately in order to reduce time to market. With the pressure to impress stakeholders with quick releases and even quicker updates, it sometimes means that delivery speed trumps better development choices. And this can impact your capacity to respond and adapt to changing customer needs. When your technical debt begins to increase and compound, then your team subsequently must devote more time to repairing shortcuts rather than creating new innovative solutions.

Technical debt is expected in any tech company. However, companies could avoid incurring a mountain of technical debt by integrating a few practices into their process, such as incorporating the clearing of technical debt into sprint planning for each phase of a project. Instead of done meaning released, done means released and technical debt rectified. Instead of moving it into a backlog to return to when there’s more time, or (more commonly) when a patch needs to be issued, it's dealt with until finished. Stabilizing the current situation before adding a new feature is not as sexy, but it will mean less work and fewer headaches in the future.

Some other ideas which we have learned from our own experience and from reading and listening to the experiences of other companies include:

• Improving communication between departments. Encourage and promote more collaboration between the engineering and development teams, and ensure the business team understands the product backlog and other elements that might impact roadmapping, milestones, and other requirements. This avoids too much being promised too soon.
• Writing code that does not need refactoring. A common practice when under a time constraint to deliver, is to write complex code that may work now, but may be hard to unravel if a new feature is added or a bug occurs.
• Reducing dependencies on other solutions. If one application relies on 30 dependencies, and each one of those dependencies is updated once per month, then that application must be rebuilt nearly every day of the month.
• Writing automated tests. When a new bug is found, write a new test to reproduce it and then fix the issue. If that bug ever resurfaces, the automated test will catch it.

Tight budgets and schedules can lead to decisions involving short-term solutions that will cut development time in order to get to market sooner. Review the cost of your mounting technical debt and if it's creating more work and costing more time at the expense of your team and your company, you may want to redefine your definition of done.