We tend to believe that every new feature is a good and valuable addition to a product. Quite often, it can be hard to not implement a feature, especially when you’re constantly hearing good ideas for new features every week.
The problem is that every new feature adds debt or creates a placeholder for future debt. You deliver more and more features, accumulating more and more debt. Most people don’t know how to work with debts. I don’t. Everyone knows about technical debt, but there are few more types of debt in software development:
Any new feature in a product may become a source of all these kinds of debt.
The image below shows several features in a product. Every feature adds some debts. In reality, it is extremely hard to add a feature with zero current and future debt.
Several Features with various level of debt.
Every Feature needs maintenance: functional, UI, quality, technical, documentation, localization. What if you have 100 features in a product? What about 1000? Can your software read emails already?
When should you add a new feature, and when should you pay back some debts? Let’s check the product lifecycle. Imagine you are running a very young startup. You don’t care about debts at this stage. You care about market expansion, new features, and growth. Now imagine the product is dying, it is too late to focus on debts, it’s over.
Product life-cycle and debt. When to focus on debts?
It seems the right time to focus on debts is when a product has proven its success on the market and is about to enter the “mature” phase. For a typical SaaS B2B product, this may be after 4–8 years. The chart above is valid for our SaaS product, Targetprocess. In my opinion, we started to focus on debts about 2–3 years late. We’re finally coming over the hill, but it will take some more time to re-energize development.
Ideally, some part of your resources should be dedicated to debt payment at all times, but after 6–8 years it may even be a good idea to have a “Debt Return Year” or something. At this point, development speed decreases due to technical problems: UI consistency degrades, many features are outdated, bugs and performance issues annoy customers.
Moreover, you’ve accumulated enough customer feedback and now understand your domain much better. Mistakes you made and new opportunities became more clear. You need an ultimate clean-up to prepare a launching pad for a powerful push.
It is extremely hard to slow down and clean up the mess in a product. You are always afraid to lose market share and functional edge. I don’t want to be extreme here, just want you to think about every new feature you add from a debt perspective.
There are several obvious consequences.
I want to finalize my post with a quote:
One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking. — Rob Pike & Brian W. Kernighan