Customer-Driven Knob

Yesterday I was in a meeting talking about a feature in our product. One of the things that we were discussing was where to set the queue depth. For this particular queue, anything from 64 to 1024 would function just fine and would fit within the resource budgets we had. The trick of this queue was it's effect: setting the queue depth higher let us handle more volume; setting the queue depth lower made throughput faster. So what number to choose?

Someone said, "Let's just let the customer set this. We can make it a knob."

Okay, yes, we could do that. But how on earth is the customer going to know what value to choose? This is a knob driven by the internal implementation and design choices the team has made. We could explain the rough effects of various settings to customers, but really, they're going to be cranking it to the "more volume!" or to the "faster faster!" end.... and it'll pretty much be a guess from there.

I'm not anti-knob. Not at all. Letting customers flex the system to their needs is very important. But the customer should drive the knob. After all, more things than just the queue depth affect the throughput versus total volume optimization. If we're going to give the customer a throughput vs performance knob, we should flex all of those things under the covers.

Put knobs in your software when there are choices the customer could reasonably make. Just make sure the knobs come from the customer's perspective, not from the internal implementation decisions of the software.