NO MATTER HOW COMFORTABLE A SCHEDULE LOOKS at the beginning of

an iteration, you can’t avoid 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 prob-

lems and you become focused on them. This sort of deferred work is known

as technical debt, and it is not your friend. Specifically, Martin Fowler calls this

deliberate 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 to 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 incur technical debt to meet a deadline or

implement a thin slice of a feature. Try not to be in this position, but if the situ-

ation 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 task card or log it in

your issue-tracking system to ensure that it does not get forgotten.

(Source: )

“What do you get out of code review?

There’s the obvious: having a second set of eyes look over code before it gets checked in catches bugs. This is the most widely cited, widely recognized benefit of code review. But in my experience, it’s the least valuable one. People do find bugs in code review. But the overwhelming majority of bugs that are caught in code review are, frankly, trivial bugs which would have taken the author a couple of minutes to find. The bugs that actually take time to find don’t get caught in review.

The biggest advantage of code review is purely social. If you’re programming and you know that your coworkers are going to look at your code, you program differently. You’ll write code that’s neater, better documented, and better organized — because you’ll know that people who’s opinions you care about will be looking at your code. Without review, you know that people will look at code eventually. But because it’s not immediate, it doesn’t have the same sense of urgency, and it doesn’t have the same feeling of personal judgement.

There’s one more big benefit. Code reviews spread knowledge. In a lot of development groups, each person has a core component that they’re responsible for, and each person is very focused on their own component. As long as their coworkers components don’t break their code, they don’t look at it. The effect of this is that for each component, only one person has any familiarity with the code. If that person takes time off or - god forbid - leaves the company, no one knows anything about it. With code review, you have at least two people who are familiar with code - the author, and the reviewer. The reviewer doesn’t know as much about the code as the author - but they’re familiar with the design and the structure of it, which is incredibly valuable.”

(Source: scientopia.org)