Act with Prudence - Seb Rose
"whatever you undertake, act with prudence and consider the consequences" Anon
NO MATTER HOW COMFORTABLE A SCHEDULE LOOKS at the beginning of an iteration, you can't being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick." it is often appealing to "do it quick" with the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often, the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt in his taxonomy of technical debt, and it should not be confused with inadvertent technical debt.
Technical debt is like a loan: you benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder ot add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix, there may be a whole stack of not-quite-right design choices layered on top of the original problem, making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix the original problem, that you actually do go back to fix it. And by then, it is often so hard to fix that you really can't afford the time or the risk.
There are times when you must uncur technical debt to meet a deadline or implement a thin slice of a feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big but) you must track technical debt and pay it back quickly, or things go rapidly downhill. As soon as you make the decision to compromise, write a tack card or log it in your issue-tracking system to ensure that it dose not get forgotten.
If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest, and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must.
Pay off technical debt as soon as possible. It would be imprudent to do otherwise.
맞습니다.
급한 프로젝트일정때문에 가끔은 "제대로하기"(doing it right) 보다는 "빨리하기"(doing it quick)를 선택해야될 경우가 많다.
그러지 않기 위해서 노력해야겠지만 어쩔수 없는 경우에는
빠른 주기로 재대로 고치를 작업을 해야한다.
그렇지 않고 놔두다보면 나중엔 정말 일이커져서 엄청난 위기에 봉착할수 있다.
