Product and engineering need to see each other as co-signers on technical debt. The idea isn’t to say “no” to all technical debt, as you will definitely have to take some on. Rather, we need to have open and honest discussions about the state of the code and why certain design elements need to be fixed now and which ones can be deferred. Collectively balancing the need to deliver in the short vs long term.

The Metaphor

Technical debt was originally created as a metaphor to help illustrate the risk incurred by not addressing certain design elements in the code. When the old elements are left in place they accrue risk at a compound rate, just like debt. Ultimately, the debt could grow so much that the ability of engineers to use this code to deliver value to users would be too expense. The result is a kind of default, a complete rewrite or engineers leaving. It’s important to point out that this is just a metaphor. Since metaphors are made up, we should not take them very seriously instead we should focus on understanding quality of our system.

Deadlines

Deadlines are usually the chief cause of such risk. When put in place they shift focus onto fixed time and scope, over product quality. Engineers usually succumb to this demand to sacrifice quality, as they don’t see their role as advocates for the code.

The product team is in a difficult place as well, the quality of the product is completely invisible to them. Unlike a car, when something is wrong, the software cannot shake, make strange noises or smell bad. The only way they can get a sense of quality is to ask engineers. This makes it doubly important for us as engineers to advocate for code quality.

Conclusion

Quality is what allows the business to keep delivering value to users. While their are many heuristics for quality, I believe the best one is the changeability of the code. We need to work with our product team to make sure they understand the risks but more importantly not sign up for debt we can’t pay off.

Photo by Cytonn Photography on Unsplash

• process