Blog: Product Development

Technical Debt: The Good and the Bad

September 5, 2013 - by Synoptek

Imagine a software developer is presented with a problem to solve. The developer examines the problem and finds two ways to solve it. Solution A can be implemented quickly but results in a messy and potentially inflexible design. Solution B takes longer to implement, but in the end yields a much cleaner and understandable design. Choosing solution A might seem like a good idea at first; the problem is solved faster and the project could be completed slightly faster. However, caution should be exercised when making this decision as a solution A also carries with it some technical debt. Technical debt is a metaphor coined by Ward Cunningham in 1992. He used it to describe a similar situation.

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

–      Ward Cunningham

Sources of Debt

Technical debt can be accumulated through a myriad of sources ranging from business pressures to delayed refactoring. In some cases it may be prudent to take on some technical debt in order to meet a particular business deadline. For example, while the software is being built the client may want to give a demonstration to potential future customers. Taking on some debt may be a good decision in order to complete a feature faster so that it may be shown off sooner. However, delaying the refactorization of this potentially suboptimal implementation may result in many “interest payments” over time.

Being a Responsible Debtor

At Synoptek, our focus is on software craftsmanship. We design and develop the best solutions by being responsible debtors and using technical debt only as a tool throughout the life of the project. As the project progresses we use refactorization and peer reviews to ensure that our debts remain small and the principal is paid off as soon as possible.