What is technical debt? Technical debt falls into a few main categories: coding something quick and dirty often to increase time to market; an outdated design; spaghetti code or bit rot where code has been added to repeatedly often by multiple developers.
In all cases the only solution is to refactor the code to both simplify and modernize it. The problem is refactoring code does not introduce new features and so it can be difficult to convince a product owner or management of the importance of refactoring, as there is no obvious or immediate value. Hence it often is left unaddressed and carried forward as debt, that becomes difficult to “pay off” over time.
It is important for the whole team including the product owner to understand that this debt is owned by the whole team. Like any debt that must be paid, there are really only two ways to accomplish this: either by paying it down in small increments or paying it off all at once. The advantage to paying it off over time in small increments is that it hurts less in any given Sprint or Release. This is much akin to paying down a financial debt, meaning you can make regular payments while still being able to make other purchases (in this case additional features). The alternative is to pay it off all at once, which while hurting for the next Sprint or Release allows the team to immediately reap the benefits, reduce their risks and them frees up future capacity that would have otherwise been focused on paying the debt slowly.
If the technical debt is not addressed, it will become harder and harder to maintain the code, and more overhead will be spent working around poor design. The risk of introducing bugs increases and the likelihood of a bug escaping becomes inevitable. At that point the team will be faced with no other option than to refactor only now they are doing it under stress to fix the issue, and the quantity of refactoring is likely greater than if they had worked on it sooner.
Ultimately it is the product owner’s decision as to when to pay down the technical debt, however the rest of the team should be prepared to explain why carrying the debt forward is actually costing the team more in the long run. Only poor product managers will continue developing products with such a shaky foundation without negating the risks it brings.
New Poker Room opens inside Caesars Palace in
ReplyDeleteCaesars Palace Poker Room inside Caesars Palace in Las Vegas. By 양주 출장샵 KAY W. | 경기도 출장안마 Mar 11, 인천광역 출장샵 2021 at 1:00 pm EST. A poker 논산 출장안마 room at the 울산광역 출장안마 casino on the
I think this is an informative post and it is very useful and knowledgeable. therefore, I would like to thank you for the efforts you have made in writing this article. custom built gaming pc
ReplyDeleteAs you take care of the mortgage, you're imbuing value in the house and are more improbable to see the property go into negative value under the Reimbursement Mortgage.
ReplyDeletetoprankinmortgages