[kazinator]

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?

[smcameron]

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.

1. https://stacked-git.github.io/

[kazinator]

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.

[svachalek]

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.

And "this person" is https://en.wikipedia.org/wiki/Kent_Beck btw.

[kazinator]

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.