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.
Thank you! Giving customers a set of (for the customer) arbitrary values and asking them to pick within the set is silly, and best practices don't cover the information gap. You must be able to explain what the set means, or do without it (auto tuning, hard set stops that are easier to define, etc..)
ReplyDeleteThis was funny.
ReplyDeleteWorking with web I read this as displaying the knob to the visitors of the site, customers, before I realized it's an administration setting (kind of...).
My imagination ran wild with the implications of letting the collective chose the setting!