9 Speed, Quality, and Technical Debt

The first version of a product can never be released soon enough. That makes sense. As long as designers and developers are working on a product that isn’t making money, it’s costing money.

But speed can come at a cost. To gain speed, you need to make sacrifices. And very often speed is traded for quality, resulting in technical debt.

Speed and Quality

In product development, speed and quality are almost always irreconcilable. Increasing the velocity of a project means compromising on quality. From a development perspective, this usually results in the creation or accumulation of technical debt.

Assume for a moment that you’re the product owner of a software project. The first version of the product needs to include five major features. Each of these features takes a week to develop. The problem is that the client wants to ship the first version of the product in three weeks. What do you do?

You have several options. The most obvious one is dropping two features. Unfortunately, that’s rarely something the client agrees to. Another option is cutting down development time of each feature by one or two days. This usually translates to removing anything that doesn’t involve the implementation of the feature, such as code reviews, quality assurance, and testing.

Technical Debt

Technical debt can creep into a project without the product owner knowing about it. The development team usually knows, though. If the team is led by a senior developer and code reviews are baked into the company’s culture, technical debt is easy to spot.

A fast approaching deadline can cause even the best to ignore technical debt. The symptoms start to appear when new features take longer to build than expected and regressions make their way into the product. These are the early symptoms of technical debt.

In advanced stages, technical debt takes a project hostage. Nobody wants to touch the project anymore. Features take ages to complete and are often compromised by technical limitations caused by technical debt. Days, weeks, or months of bug fixing are needed to stabilize the project. I’m not exaggerating.

In the meantime, the product itself evolves at a snail’s pace. The speedy start that was once so important for the project’s success has long been forgotten and, looking back, wasn’t that important after all. It rarely is.

Focus

If the client wants to ship in three weeks, the correct answer is removing features. For projects with a long shelf life, you want to avoid technical debt at any cost. Technical debt is very much like a virus. It’s hard to eradicate and, if it isn’t treated in its early stages, it spreads out rapidly across the project’s codebase.

Focus is essential to avoid technical debt. Instead of rushing out a feature, you take the time to craft something that stands out. This doesn’t only relate to the final product; it also involves the development aspect of the feature.

You don’t need to overengineer the solution, but you need to make sure the feature can grow beyond its current scope. You plan and anticipate how it can or could evolve.

How to Get Rid of Technical Debt

There’s no miracle cure to rid a project of technical debt. You need to take action, though, if you want to avoid worse.

Refactoring

The least radical approach is refactoring the project, focusing on one problem at a time. If you’re in luck, one round of refactoring is sufficient. However, most projects suffering from technical debt have many problems that need fixing.

As I mentioned earlier, technical debt spreads like a virus and that means many areas of the codebase are infected. I strongly advise against a single round of refactoring. Map the problems you plan to attack and spread the refactoring over several releases. This ensures the release cycle isn’t blocked as long as the refactoring is ongoing.

In the meantime, make sure you don’t introduce new problems. Hold off on new features if possible. Don’t make the same mistake twice.

If you’re working on a large project with years of history, be prepared to spend weeks or months refactoring. That’s the price you pay for technical debt.

Clean Slate

The most radical approach is starting anew. This means you don’t need to spend months refactoring. This isn’t an option for every project. If you have the opportunity to start with a clean slate, though, you’re in luck.

While it means that you need to implement every feature from scratch, it’s an opportunity many developers would grab with both hands. Learn from your mistakes, or those of your colleagues, and create an amazing product.

I’ve worked on several projects that would have cost less if the project was rebooted. But that’s often a very hard sell. The client doesn’t see the problems the developer sees. They only start to see the symptoms of technical debt when deadlines are missed or features become very expensive.

Taking Shortcuts

Taking shortcuts rarely pays off in software development and most developers know this. But deadlines are often more important and developers rarely have the authority to make decisions about the feature set of the product.