Remember the old saying, “To make an omelet, you have to break some eggs”? It means that in order to achieve something, sacrifices must be made. Unfortunately for software developers, sacrifices often amount to something that nobody likes to face: technical debt.
Technical debt can insidiously eat away at time, money, usability, and a developer’s reputation. It is accrued when tradeoffs are made in the development process. For example, if a developer is running up against a hard deadline, they may be inclined to compromise on certain features in order to finish a solution on time. The idea of “I’ll finish it later” or “in the next update” is highly appealing.
In the meantime, that missing feature becomes debt to be paid later on, most likely when that developer is facing another deadline that may require additional sacrifices. Before you know it, corner-cutting practices are becoming commonplace, and debt is growing.
Like charging something on a credit card, debt can present short-term gain, but potentially devastating long-term effects. Look at it from the end user’s perspective: Organizations depend more on having a product delivered correctly as opposed to quickly.
Cutbacks on key features can cause downtime and loss of productivity. In a sense, the debt is being passed from the developer to the user. If this happens, organizations may call into question your reliability and hesitate to purchase future versions of your product. Do this too many times, and you’ll not only be saddled with debt and a solution that may be half-baked (or worse, doesn’t work at all), but also a rapidly declining market for your solutions.
While it can never be avoided entirely, there are several things development teams can do to get their arms around technical debt before it suffocates them and those who use their solutions:
1. Maintain a balance. Credit card balances are bad, but balance between agile and traditional development is good. Agile development calls for focusing on the now and not over-engineering for the future.
But, what if the product road map requires the software to deliver a specific feature or need at some point down the line, and it turns out that delivery is dependent on the work you are currently doing? Taking out a feature now could have serious consequences later on. It’s best to combine short-term and long-term development cycles. Agile development certainly has its place, but developers must always consider how a quick change today will impact future iterations of the software. In short: Keep your options open.