Time is not like money in that no time that elapses is ever yours to get back. Whereas sometimes money that leaves your hands is actually still yours.
Giving up on a refactoring because of some failed tests could be wasteful.
How much time you put into the refactoring already should enter into your decision making because if you throw it away, you may have to put in a comparable amount of time to redo the job.
If you've sprayed 15 coats of lacquer on a piano and a fly lands into your 16th one, do you strip it and start again, or just sand out the blemish and keep going? What if it's half a coat on a ukulele?
Why it's not more popular because:
1. It's impossible to get anyone's attention to anything worthwhile anymore. The modern Internet is structured against it, and there is just too much going on in general.
2. People who are good with Git don't really need it; they can get their commit ducks lined up in a row with interactive rebase. That doesn't have a push/pop discipline, only "waves of push", but it's good enough.
Quilt is still worth knowing about and learning, by the way.
And "this person" is https://en.wikipedia.org/wiki/Kent_Beck btw.
If you're asked to take over the completion of a project it matters whether it's 20% done or 80% done.
The sunk cost fallacy isn't about it not mattering what has been done.
Sunk cost reasoning typically applies to a situation where some cost has been spent or effort made which was largely or entirely a waste. We continue to be emotionally attached to the effort or cost even though most of it was wasted. The cost or effort are irrecoverable and have not resulted in any benefit so which means we're emotionally it has to nothing real at all, only a memory of the past.
In order to go forward you have to look at what's been done. But that means looking at the actual effect or result, the state of it, and not the effort or cost.
If you're thinking about throwing away some result but you actually need it then the effort to recover that result is relevant and should factor into your reasoning. That's a future effort, not necessarily the same as the past one, but the password could be a good estimate for it.
If you've been refactoring all day and one test is broken, should you scrap it? Don't look at the "all day" sunk costs, but a realistic estimate. Having done the refactoring once already, maybe you could re-do a very similar refactoring in two hours. So that's what it is.
In a word, don't confuse replacement cost with sunk cost.
But humanity is in a stage of evolution such that we are very attached to past experiences, I can see them influencing everything I do, even on things such as whether or not I'll continue a code refactoring.
I think the author's Poker example is good. If you are attached to your loss from your last game, you won't be able to play the next game in a good mental shape for winning. With technical problems I think this means: don't get attached to your frustration when things are going wrong. Maybe the right thing is to stop the refactoring altogether because you have other priorities, it doesn't matter, as long as you are able to let it go.
... or was it, "Watch me sink this company?"
