Don't Place Unfinished Work On A Queue, Part 2
I have received a nice comment on my Don’t Place Unfinished Work On A Queue article. The thoughtful comment was by
, and I am very grateful to Dennis for taking the time to present his views on the topic. His objections inspired me to revisit my advice, and now I’m going to offer a more detailed response.I will do it by first quoting parts of Dennis’s comment and then providing my answer:
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.
My answer to this objection is that any finished work must not be kept on the shelf. If we have finished something, that means it has been shipped to our customers. What would be the point of keeping the remnants of that work in the same place where we are keeping the work in progress? Doing so only increases the bloat. Many contemporary platforms and tools offer comprehensive services to automate the archival of the artifacts associated with the finished work. We must strive to automate those services so that whenever we ship something, any residual artifacts get automatically archived or even deleted.
A good example is GitHub, which allows us to automatically delete a branch after it has been successfully merged to the trunk. There is no reason to bypass this useful automation process. Keeping merged branches around is only good for creating unnecessary complexity, bloat, and confusion.
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.
I have already answered this objection in my comment to Dennis’s comment, but let me reiterate here:
Not being in the position to predict the future is 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 mostly 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.
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.
I don’t see that as a problem. It is the customer’s prerogative to decide what they are willing to pay for. If they order some work from us, that means they have agreed to pay for that work. If they then change their mind midway through the process and decide not to proceed with the work, they have no right to ask us to return the money we have already earned by working on their order. The customer alone amortizes the risk in such scenarios.
My main point is that we, as professionals, should not cheat our customers by starting to work on something they asked us to do and then leaving that work item in an unfinished state, thus unnecessarily prolonging the wait time. But if the customers are explicitly asking us to abandon some item halfway through, that is solely their problem and it does not, and cannot, reflect badly on our professional ethics.
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.
I do not understand this principle. Any work costs money. We, the professionals, must be very careful with other people’s money. If we’re not, we quickly lose our bosses’ and our customers’ confidence, and with losing that, we risk losing their trust. Once lost, trust can hardly, if ever, be restored.
We must therefore think twice before starting to work on any new item. The goal is always to only work on something that would be worth some money to our customers. Would it make sense to them to pay for the work we’re about to do? If not, or if we’re not sure, then we must abstain from jumping in and just ploughing away.
So, in addition to your punch line, I think it’s important not to demonize “unfinished work” or “stale branches” per se.
I vehemently disagree with that. There is no way to look at something like “stale branches” and perceive anything of value there. Unfinished work is always, under any circumstances, a complete waste. And anyone who is intent on running a successful business operation should strive to minimize and if possible eliminate any and all waste.