The first version of a product can never be released soon enough. But that makes sense. As long as designers and developers are working on a product that isn't making money, it is 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 accumulation of technical debt.
Assume for a moment that you are 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. But 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 means dropping two features. But that is rarely something the client agrees to. Another option is cutting down development time of each feature by one or two days. This usually means 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, however, usually knows. 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.
But 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. Those 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 am 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 is 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 what it currently is. You plan ahead and anticipate how it can or could evolve over time.
How to Get Rid of Technical Debt
There is no miracle cure to rid a project of technical debt. But you need to take action if you want to avoid worse.
Refactoring
The least radical approach is refactoring the project, focusing on one problem at a time. If you are 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 are working on a large project with years of history, be prepared to spend weeks or months refactoring. That is 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. But if you have the opportunity to start with a clean slate, you are in luck.
Even though it means that you need to implement every feature from scratch, it is an opportunity many developers would grab with both hands. Learn from your mistakes, or those of your colleagues, and create an amazing product.
I have worked on several projects that would have cost less if the project was rebooted. But this is 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.
Conclusion
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.
