A theory on why defaults for tunable parameters stay unchanged
July 10, 2012
Despite my grumblings about tunable parameters with stupid old defaults, I've decided that I actually have a reasonable amount of sympathy for kernel engineers and other developers who are in this situation and wind up leaving the defaults untouched. The following is only a theory, because I have never been in this situation, but I think it's a plausible one.
The problem with the defaults for tunable parameters in any long-lived project is that leaving them unchanged takes no work at all while changing them is probably going to require a bunch of your time. In an ideal world you could just set good values as the new defaults, and here we run into the first problem: what are good default values now? Worse, how do you know that these are good default values? Have you measured this or done analytic work to defend your numbers?
In a long-lived project, there's going to be someone who will ask you these questions if you propose new default values. You're proposing a change, so it's up to you to justify it. In fact it's probably up to you to argue people into accepting your new values (or formula) even in the face of people who disagree with it or think that it's possible to come up with better default values or who worry about corner cases that they think you haven't considered.
All of this is a bunch of work and a pain in the rear. As an OS developer (or any sort of developer) there's a lot of other things you could be doing with your time, things that are more obviously productive and less annoying. So, really, who wants to stir up the anthill? Better to leave those old defaults unchanged. Besides, these days everyone changes them anyways (except not really, but don't think about that).
(If you want to you can see this as another example of the perfect being the enemy of the good, or at least the enemy of the 'better than it currently is'.)
Written on 10 July 2012.
* * *
Atom feeds are available; see the bottom of most pages.