Pay down Your Technical debt

?

Pay down Your Technical debt

Burkhardt Hufnagel

On any PRojECT this is in pRoduCTion (i.e., it had customers that was using it), there would come a time when a change must be made; Either a bug needs fixing, or a new feature must be added. At this point there is the pos-sible choices:you can take the time needed to ' do it right, ' or you can take one or more "Shortcuts" and try to get the door sooner.
Generally, the business people (sales/marketing and customers) would want the change made as quickly as possible, while the Developers and testers would be more interested in taking the time-to-properly design, implement, and test the change befo Re delivering it to the customers.
As the project ' s architect, you'll have a to decide which makes more sense and then convince the decision makers R advice; And, as with the most architectural issues, there is a tradeoff involved. If you believe the system was reasonably stable, then it could make sense to go the "quick and dirty" route and get the Chang e into production quickly. That's fine, but you need to know that's doing so your project was incurring some "technical debt" that must be repaid lat Er. means going back and making the "repayment" in the the the "the" and "would" Ces to doing it right the first time.
So, the concern over making changes properly now versus later? It's because there ' s a hidden cost to making these quick and dirty fixes. For financial debts The hidden cost was called "interest," and most anyone with a credit card knows
?
?? How expensive just paying the interest in a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the Hacke D-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must was made until the original debt is repaid.
Now so you understand a bit more on the true cost of technical debt, you might decide the price are too high and you C A ' t afford the cost. But when it ' s a choice between have the developers get the fix out as quickly as pos-sible or taking a severe financial Hit, it generally makes sense to get the fix out quickly. So, take the "hit" and get the change to production ASAP, but don ' t stop there.
Once The fix is in production, with the developers go back and fix it properly so it can be included in the next Sche Duled release. The equivalent of charging something on your credit card and then paying off the balance at the end of the month s O you don ' t get charged interest. This is the provide the fast changes the business needs, while keeping your project out of debtor ' s prison.
Burk Hufnagel have been creating positive user experiences since 1978 and is a leads software architect at LexisNexis.

Pay down Your Technical debt