This person needs to make small git commits as they refactor, and use git bisect to find which one broke the test, then fix it and squash that fix into that commit with interactive rebase ...
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?
Using something like stgit[1] makes it trivial to break changes into small commits, pushing and popping your way up and down a stack of commits. I don't know why it's not more popular, it makes anyone reading your commit history think you must be some sort of genius who almost never makes mistakes.
That looks obviously inspired by Quilt, right down to command compatibility like refresh and what not.
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.
The answer to the last question is what the sunk cost fallacy is all about, the answer is it doesn't matter what you've already done, it only matters what is the optimal solution going forward.
My point is that in order to evaluate what is the optimal solution going forward you have to look at what's already been done. It matters.
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.
There is a distinct difference between using the past for evaluating your next move, and being attached to past experiences. The latter will get in the way of critical thinking and can lead to bad decisions.
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.
Nice article, fun to read, I nearly gave up at 3/4 but the sunk cost fallacy took me to the end and I’m glad it did as I enjoyed the reference back to poker. The gem in this article for me was the part about it being more valuable to wind back to the last green the more you have pressed on. I’ll take that thought with me!
When Kent recently gave a talk at Plato's Elevate Conference, he was asked: "What is the thing you enjoy where you completely lose track of time?" He said "Poker." without a second of hesitation. He clearly loves the game to come up in his writing.
Yes, I have to always remember the sink cost fallacy… but remember it can also motivate you to continue on when times are tough so that you do not give up
I agree with you on bathroom repairs. I was thinking more of things that years or decades to complete, like long term projects or relationships with people
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?