I really like your punch line: “Never begin the work on a new item if we’re not very sure that we will be able to deliver it without having to place it in a waiting queue.”
However, I’d like to challenge you a bit on this.
Firstly, not all stale branches represent unfinished work. Some may simply have been forgotten, or are duplicates or residual artifacts—like completed spikes—that should have been cleaned up.
More importantly, though, there’s a significant issue in your argument: it overlooks the sunk cost fallacy. I understand your advice to “only work on completable stuff,” but your solution somewhat requires us to predict the future—which isn’t always feasible. Work is often initiated at the customer’s request, and if a customer changes their mind midway, the time and resources already invested become sunk costs and shouldn’t influence our decision on what to do next.
In personal productivity, I refer to this principle as “not all work has to be completed,” emphasizing that we shouldn’t become slaves to our to-do lists. I believe this concept also holds true within a software engineering team.
So, in addition to your punch line, I think it’s important not to demonize “unfinished work” or “stale branches” per se.
Thank you for the criticism, Dennis. It's good to disagree -- it gives us a chance to examine the issue at hand.
I agree with your statements with the proviso that they are applicable to work that is done in large batches. When it comes to software development, however, large batches are undesirable. Planning to do work in large batches is proving detrimental to software development. My advice only applies to work done in small batches. When we work in small batches, our horizon of planning is tiny, which means there is not much challenge in predicting the future. If we start working on a tiny batch, our intention is to get it done and placed in the hands of the customers in a matter of hours. No work should spill over into the next day.
Well said. So we found the missing distinction that resulted in the disagreement in scale and work scopes. For small scopes we don't need as much prediction and the sunk costs argument is weakend by orders of magnitude. In light of this, I guess we are mostly on the same page after all.
Hey Alex,
I really like your punch line: “Never begin the work on a new item if we’re not very sure that we will be able to deliver it without having to place it in a waiting queue.”
However, I’d like to challenge you a bit on this.
Firstly, not all stale branches represent unfinished work. Some may simply have been forgotten, or are duplicates or residual artifacts—like completed spikes—that should have been cleaned up.
More importantly, though, there’s a significant issue in your argument: it overlooks the sunk cost fallacy. I understand your advice to “only work on completable stuff,” but your solution somewhat requires us to predict the future—which isn’t always feasible. Work is often initiated at the customer’s request, and if a customer changes their mind midway, the time and resources already invested become sunk costs and shouldn’t influence our decision on what to do next.
In personal productivity, I refer to this principle as “not all work has to be completed,” emphasizing that we shouldn’t become slaves to our to-do lists. I believe this concept also holds true within a software engineering team.
So, in addition to your punch line, I think it’s important not to demonize “unfinished work” or “stale branches” per se.
Thank you for the criticism, Dennis. It's good to disagree -- it gives us a chance to examine the issue at hand.
I agree with your statements with the proviso that they are applicable to work that is done in large batches. When it comes to software development, however, large batches are undesirable. Planning to do work in large batches is proving detrimental to software development. My advice only applies to work done in small batches. When we work in small batches, our horizon of planning is tiny, which means there is not much challenge in predicting the future. If we start working on a tiny batch, our intention is to get it done and placed in the hands of the customers in a matter of hours. No work should spill over into the next day.
Well said. So we found the missing distinction that resulted in the disagreement in scale and work scopes. For small scopes we don't need as much prediction and the sunk costs argument is weakend by orders of magnitude. In light of this, I guess we are mostly on the same page after all.