Technical debt is a very common phenomenon; in fact it occurs with virtually every line of code whether you want it or not. Although unoptimized coding due to the rush presented by management pressure may be one of the major reasons for technical debt, it occurs in various flavors based on the nature of execution. Sometimes, even the best written code may run into debt by introducing a minimalistic change in the business definitions, e.g.: a variable name that makes no sense anymore.
This debt cause and effect is exponentiated when scaled teams come into play. In many cases these teams are distributed and an optimized code for one team may become a debt for another. These debt dependencies between teams is what creates the “Valley of Debt”. Unfortunately these cannot be avoided but good engineering practices coupled with lean principles may keep them confined for long enough in order to push the validity of software applications.
Sooner or later, the cost of change will outweigh the benefit of an application and turn it into legacy; the challenge is to keep it as far as possible by slowing down the fall into the valley of debt. In this interactive workshop, we will witness first hand how debts are introduced and how these can be confined by utilizing good engineering practices coupled with lean principles.