A couple of months ago when I attended a TDD coding dojo I managed to annoy most of the other participants. The reason was that I stubbornly argued that no refactoring should take more than three minutes.

Here's the reason for my stubbornness:
I have never been able to finish a 10-minute refactoring in less than half-an-hour.
Refactorings are really difficult to estimate. What feels to be a five-minute fix often ends up lasting 20 minutes. This is not only me: I've seen the same behavior in other developers when pair-programming.

My general rule says that a refactoring takes about four times longer than estimated. A one minute refactoring usually takes around four minutes. A two week Refactoring takes about two months. A total rewrite of the application estimated to half-a-year takes about two years.

So my stubbornness about staying below three minutes was actually an attempt not to be in the red zone for more than 10 to 15 minutes. The others thought that 10 minutes was ok. I disagreed because I knew that such a refactoring would last most of the remaining time of the kata.

Why is it so bad to do a long refactoring? There are many reasons.

There is a big chance that you over-design. When doing a "big" rewrite lasting 20 minutes you might, by accident, add some new functionality that you don't have a test for. One of the biggest advantages of TDD is that you have the simplest possible design. Staying in the red for a long time jeopardizes this.

Another problem is that you get no sense of progress. When will you finish? If you estimated a refactoring to 10 minutes you will probably estimate the remaining part to 10 minutes after working with it for 15...

Last but certainly not least: you don't get any feedback. If the tests are red after a 30-minute refactoring, how will you know what caused the problem? Is it something you just did or was it that other thing you did 25 minutes ago? How long will it take you to find out? It might take hours.

The Three Minute Red rule does not only apply to refactorings, but goes for when writing tests as well: If you estimate the time to add production code of a newly added test to more than three minutes you should either do some refactoring before adding the test or come up with a better test.