A Drop in the Bucket
How do you fill a bucket? One drop at a time.
A time honored rallying cry of a man with no argument is to counter an objection by proclaiming it’s just a drop in the bucket. Everyone intuitively knows this is a nonsensical response, because it isn’t even really a response. When this expression is offered, it is prefixed explicitly or implicitly by that’s true, but. That’s the biggest issue with this line of thinking. It isn’t just that it leads us to bad conclusions, it’s that it endorses the idea we shouldn’t even be attempting to make rational decisions in the first place.
When I’m at my best, I begin my reply by pausing the conversation and forcing them to make this concession. This can be an unpleasant interaction, but it’s important any time someone is making a bad faith argument of any kind or making such a critical mistake that their reasoning could be deployed by a bad faith actor. If someone isn’t actually addressing the argument or can’t summarize it, you shouldn’t advance. Don’t be worried about being “rude”. If someone mischaracterizes you or ignores your position, they’re being the rude one!
Afterwards, I always respond to this line with one of my own making. I ask well how do you fill a bucket? One drop at a time! When they’re invoking this argument, they’re saying the problem you’ve identified is already present and is in a bad state. That might make some skittish, as it’s generally verboten to criticize the current state of things at work. However, if you think about this it’s always the case. It’s most obvious with issues external to the people who are debating. A common example is debating if newly proposed government spending would be wasteful. Rather than addressing the actual criticism, which is that the spending is wasteful, the argument is well there’s already so much wasteful spending so who cares? I believe that if you’re honest, whenever you hear this you know that’s really what’s being said.
As a brief aside, I think it’s fine to point out things are in a bad state as part of a decision making process. In fact it’s not just ok, it’s necessary to acknowledge when things are in a bad place even if that means we’re criticizing the work of our colleagues and predecessors. The first step is admitting you have problem, so we need to be willing to call a spade a spade. You don’t need to be a jerk about it, and generally you don’t want to blame individuals either (or at least not solely). It’s a team sport, and it takes a team to fail at scale. But if you’re too fragile to self reflect, take constructive criticism, or receive an accurate assessment of your work, you’re the problem.
Understood this way, we get to make a rare absolute statement. This argument is never acceptable. We can’t justify further contributing to a problem just because it’s only a small addition to an existing problem. If your dog knocks over your trash can and spills refuse all over the floor you would never say “well, I’m going to toss what’s left of my lunch on the ground because it’s just a drop in bucket”. While it may be an “extreme” example of the logic at play, it’s certainly analogous. After all, the crust from your sandwich is but a drop in the literal bucket of trash.
The Real Argument
So then, what’s the right way to point out that a negative consequence is inconsequential when taken in consideration of the full context, and in which situations is it appropriate to deploy this line of reasoning? There are a few principal factors to get right to be able to reasonably deploy this line of reasoning:
- You must actually acknowledge and concede the argument OR you must note that you disagree or are unsure, but that we can take it as granted because it won’t change the outcome. In other words, you can skip the disagreement about the initial facts because no matter what the answer is, your next objection would still come.
- There must be a benefit that comes with the negative that isn’t derived from the goal itself. For example, if I’m going to slow down an operation from 0.052 seconds to 0.058 seconds to enable output sorting I can’t cite but now things are sorted as a rebuttal. The real rebuttal would be to point out it’s an imperceivable amount of time, and trying to optimize would actually harm the business and customer because of opportunity cost. It would be better for us to move on to the next item.
- The small portion that this negative element adds to the overall measurement must be an overall measurement that isn’t negative. For example, if I wanted to write code in a way that’s slower, but the performance penalty is a negligible percentage of the overall operation time, it’s fine to give that argument so long as the overall performance is in an acceptable state. If it isn’t, you can’t actively contribute to making the problem worse as others are trying to improve it.
- Any exception needs to be carefully considered, have a mitigation plan with committed investment, and most importantly must be coordinated with and approved by those responsible for fixing the actual issue. This can relate to the opportunity cost example above. If you’re adding a new feature that slows things down slightly, and not doing so isn’t worth the cost, it’s completely valid to make that argument so long as you’re actually using the savings to optimize a different area with a higher return. If you give that reason, but don’t actually allocate the time to make the other improvement, then you’ve invalidated your argument.