Posted On: 2023-06-05
Cutting (or canceling) work is always difficult, not only because the Sunk Cost Fallacy makes it feel like the cut work was waste, but also because there is usually some kind of gap or vacuum in its place. To deal with that, one often commits to new or different work, to fill in the gap or smooth over the edges. Yet, there's no guarantee that this new work won't itself need to be later cut - a potentially endless loop that can doom otherwise healthy projects.
Broadly speaking, there are three main approaches to dealing with this problem. The first is to compromise quality - in this approach, one will commit to using or delivering something even if it fundamentally fails to perform the expected task or actively makes things worse. For better or worse, this is the approach used by most software publishers, often leaving a project with a reputation as an unusable, buggy mess.
The second approach is to compromise the schedule - to commit to delivering, no matter the cost. This isn't necessarily giving in to the Sunk Cost Fallacy, as one may still discard all work and start completely over. Rather, it is an explicit commitment to quality - an approach that states that even if it goes past the schedule or over the budget, the promised thing will be delivered. This approach is fairly rare in software, though companies that consistently use it often build a brand around it (ie. Blizzard, prior to the merger with Activision.)
The third approach is to just leave the hole. Take out what doesn't work, and do nothing to repair or smooth over the gap. This, of course, makes the gap stand out, and, even more than the other two, can lead to a reputation for breaking promises. Interestingly, of the three approaches, this is the least expensive and most effective, but the adverse effects (ie. harming the rest of the product, or the brand image overall) often means that there are non-financial costs to using it. As such, it's often used when a project or product has no future - typically in the form of completely abandoning the whole project (and potentially shuttering the division making it.)
In writing today's post, I found myself facing this precise problem. After twelve hours and three complete rewrites, I still had nothing suitable to post. Facing that problem, I had to decide which of the three approaches to use - to simply take one of the three failures and submit that (approach #1), to keep trying, even if I run out of time (approach #2), or admit defeat, and simply skip the post altogether (perhaps with a nominal "nothing today, sorry" post). As you can see, I took the risk and tried once again, creating this (my fourth attempt at a post this week.) Regardless of whether or not it was the right approach, I think my choice to do so is a reflection of a larger pattern in my work style - a pattern which promises that my main project, despite being in progress for over four years, will continue forward.