Pay Down Your Technical Debt
2015-09-05 09:11
561 查看

on Any pRojECT THAT iS in pRoduCTion (i.e., it has customers that are using it), there will come a time when a change must be made; either a bug needs fixing, or a new feature must be added. At that point there are two 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 change out the door sooner.
Generally, the business people (sales/marketing and customers) will want the change made as quickly as possible, while the developers and testers will be more interested in taking the time to properly design, implement, and test the change before delivering it to the customers.
As the project’s architect, you’ll have to decide which makes more sense and then convince the decision makers to take your advice; and, as with most architectural issues, there is a tradeoff involved. If you believe the system is reasonably stable, then it may make sense to go the “quick and dirty” route and get the change into production quickly. That’s fine, but you need to know that in doing so your project is incurring some “technical debt” that must be repaid later. Repayment, in this case, means going back and making the change in the way you would have if you’d had the time and resources to do it right the first time.
So why 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 is called “interest,” and most anyone with a credit card knows

how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid.
Now that you understand a bit more about the true cost of technical debt, you might decide the price is too high and you can’t afford the cost. But when it’s a choice between having 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 into production ASAP, but don’t stop there.
Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release. This is the equivalent of charging something on your credit card and then paying off the balance at the end of the month so you don’t get charged interest. This way you can provide the fast changes the business needs, while keeping your project out of debtor’s prison.
Burk Hufnagel has been creating positive user experiences since 1978 and is a lead software architect at LexisNexis.
Pay Down Your Technical Debt
Burkhardt Hufnagelon Any pRojECT THAT iS in pRoduCTion (i.e., it has customers that are using it), there will come a time when a change must be made; either a bug needs fixing, or a new feature must be added. At that point there are two 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 change out the door sooner.
Generally, the business people (sales/marketing and customers) will want the change made as quickly as possible, while the developers and testers will be more interested in taking the time to properly design, implement, and test the change before delivering it to the customers.
As the project’s architect, you’ll have to decide which makes more sense and then convince the decision makers to take your advice; and, as with most architectural issues, there is a tradeoff involved. If you believe the system is reasonably stable, then it may make sense to go the “quick and dirty” route and get the change into production quickly. That’s fine, but you need to know that in doing so your project is incurring some “technical debt” that must be repaid later. Repayment, in this case, means going back and making the change in the way you would have if you’d had the time and resources to do it right the first time.
So why 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 is called “interest,” and most anyone with a credit card knows

how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid.
Now that you understand a bit more about the true cost of technical debt, you might decide the price is too high and you can’t afford the cost. But when it’s a choice between having 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 into production ASAP, but don’t stop there.
Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release. This is the equivalent of charging something on your credit card and then paying off the balance at the end of the month so you don’t get charged interest. This way you can provide the fast changes the business needs, while keeping your project out of debtor’s prison.
Burk Hufnagel has been creating positive user experiences since 1978 and is a lead software architect at LexisNexis.
相关文章推荐
- Control the Data, Not Just the Code
- Java集合
- Win10/Win8.1/WP8.1开发者现在能公开回应用户评论
- Make a Strong Business Case
- Dialog 调用getWindows()函数进行系统设置 背光问题
- 如何面对客户评价Oracle EBS界面难看,不符合操作习惯
- 查看某个路径文件夹下是否有文件
- std::map
- Linux 常用命令
- 嵌入式linux之hotplug_uevent驱动(热拔插)
- java并发编程第六章(9)使用原子数组
- 逻辑地址到物理地址的转换
- 代理模式之cglib动态代理
- Android中activity间数据传递方式
- POJ2230 Watchcow(欧拉回路 + dfs)
- 设计模式(九)外观模式Facade(结构型)
- HDU 5240 Exam
- [转] Mybatis 示例之 SelectKey
- [Embeded--SW_分层]C代码分层
- 剑指offer之丑数