Why technical debt is key to building better software?

Debt. What does it evoke for you?

Greece begging on its knees for another bailout? The Everest-size mountain of the United States national debt? The horror of losing your home and car to creditors?

Most people think debt is bad. But that’s not always true.

Properly managed, technical debt is a hallmark of optimal software development.

It is something everyone ought to be familiar with.

The tug-of-war between features and maintenance

At the heart of every software publisher, there is a conflict between the need for new features to sell and the need to make sure the software works.

If you’ve been working for some time, you’ve probably come across two types of companies.

In a commercially dominated firm, the sales team sells tomorrow’s features and the engineering team is playing catch-up. As code maintenance falls behind, quality deteriorates, exposing the product to performance, scalability or security issues.

In a technically focused company, everyone dreams of creating the next Facebook. The engineering team won’t release the software until it meets lofty technical goals. With no product to sell, the company risks running out of money before its first release.

Thankfully, it is possible to find a happy medium. And this is where technical debt comes into play.

The mechanism of technical debt in agile development

Agile methods consist of short sprints that produce working software to show customers.

In a sprint of, say, a couple of weeks, there isn’t time to introduce new features and tie up all the loose ends. Corners must be cut.

Technical debt is the concerted decision to cut those corners and the documented number of “story points” required to fix the software.

For example, the sales team may ask to include a new feature in the next sprint in order to win a customer. The engineering team responds by building the feature in a fraction of the time it requires.

Once the new customer is on board, the engineering team can spend time rewriting the feature correctly and repaying the technical debt.

Conversely, the engineering team may devote an entire sprint to repaying accumulated debt to avoid serious issues down the line.

Because the consequences of ignoring the debt are clearly explained in the sprint backlog, the sales team can accept the absence of new features in the current release cycle.

As we can see, technical debt is flexible and constantly evolving. Small amounts of debt are accepted in the current sprint and eliminated in the next.

It’s up to the company to decide how to allocate development time. For example, 40% may be invested in new features, 20% in customer-specific requirements and the balance to repay technical debt.

Benefits of technical debt

Technical debt acknowledges the company’s need to satisfy customers. It also encourages the engineering team to explain in layman’s terms the reasons why the debt should be repaid.

Instead of a tug-of-war between conflicting interests, technical debt brings transparency and consensus to the software development process.

The engineering team gains in respect—and job satisfaction—because others in the company see the value of its work.

How about you?

Are you familiar with technical debt? Do you think it could help your company work better?

Let us know in the comments below.