Throwaway Work: The Loan Shark of Tech Debt

Technical debt is a designation that Ward Cunningham coined back in the 90s. It likens the additional work created by non-ideal software solutions to the interest paid on financial debt, which over time can become a crippling overhead.

Throwaway work means work which is done but which will need to be entirely re-worked at a later time. It is surprisingly commonplace that organizations are forced to knowingly undertake throwaway work as a consequence of existing technical debt. A new product need is discovered, and, correctly or not, the repayment of existing technical debt that would allow the correctly worked solution is determined to be impractical in the timeline.

This is painful, even beyond the immediately obvious. The re-work of the solution is, of course, an immense undertaking of itself. The associated morale impact on an organization should not be underestimated either; it is hard for developers to feel pride in something that is by intention going to become a dead branch in a code repository.

Beyond this are the unplanned consequences. Inevitably the coordination of pieces of functionality inside a product, integration points across a suite of products, and new unplanned features will all conspire to create further fallout. Sometimes this will come in the form of extra throwaway tendrils of code (hopefully with some judicious separation of concerns to mitigate the impact), but it can also adjust decisions towards duplication of effort, looser integration, and even worse, less acceptable user experiences.

Throwaway work becomes the worst-case consequence of deliberate technical debt - the equivalent of the out-of-control loan shark. - Julian Flaks

If this is something your organization is considering, it’s worth thinking of the reasons why throwaway work might be a calculated right decision.

1. The Bridge Loan

In organizations with highly complex product collections, either from the acquisition of individual products or just a very large scale development capability, timelines of desired (and in particular, market-driven) feature delivery may just not match between larger and smaller pieces. It can become imperative that product X ships with a certain feature even though the integration points with a larger product or platform will obviate that need a year later. This is a bridge loan situation, where if everything goes as planned, the end stage is so clearly in sight that the organization can be sure it is not adding further debt by a miscalculation. Throwaway code that never gets thrown away is itself a canonical source of technical debt.

2. The Greenfield – Venture Capital

An entirely new product or feature may at times be something that simply needs building before one can be sure it even needs building. Market and quantitative analysis, prototyping and many other parts of the designer's toolkit should render this situation something of a fringe one, but especially in the startup world, there are times when a solution needs to be given to the market and allowed to fail-fast or to find its wings. If this is a new feature and not a new product, be aware that it is unlikely it will be entirely removed from a product, even if the solution stops being a major marketing point. It is far likelier that it will remain as some amount of technical debt. Similarly in the case of a greenfield product, if that product does succeed, it becomes every bit as likely that the throwaway code is embellished rather than replaced. This is of course an inflection point of itself, and not an inevitable outcome, but the scenario is not uncommon and fits the classic pattern of all technical debt: putting off until tomorrow the refactor that should be done today.