Ousterhout's law

Back in the day, everyone was using Winamp. It is a music player with the user interface of a mixing console. The bloody thing had an equalizer on the front page!

As an amateur music producer, I know that EQ is a powerful tool but making changes that sound good is difficult, to say the least. Mixing engineers spend considerable effort with the artist to balance the frequency ranges to arrive at the desired musical outcome. I bet the 15-year-old me butchered a lot of songs with the thing.

Now we are using Spotify, a player with basically a search bar and a play button.

I ran into something called Ousterhout's Law on the Operating Systems: Three Easy Pieces book. Here is a quote from the book

TIP: AVOID VOO-DOO CONSTANTS (OUSTERHOUT’S LAW) Avoiding voo-doo constants is a good idea whenever possible. Unfortunately, as in the example above, it is often difficult. One could try to make the system learn a good value, but that too is not straightforward. The frequent result: a configuration file filled with default parameter values that a seasoned administrator can tweak when something isn’t quite working correctly. As you can imagine, these are often left unmodified, and thus we are left to hope that the defaults work well in the field. This tip brought to you by our old OS professor, John Ousterhout, and hence we call it Ousterhout’s Law.

A classic example of this kind of configuration is the JVM GC parameters. Firstly, you have to pick your garbage collector and after that, there are dozens of parameters. The number of possible permutations can overwhelm humans and has forced some of the big boys like Netflix and Twitter to create tools that by empirical methods make adjustments automatically based on the measured results. 

I'm sure all of them are needed when you want to squeeze the last millisecond out from the trading algorithm behemoth. Yet most users are like me with Spotify, I really want just to press play. The one-knob tuner in the go garbage collector is enough for me!

I often wonder which way a knob or a setting should pointed at in the pieces of software I make. If I do this, the app is faster but may produce incorrect results - sometimes. Should I add a user setting that reduces the amount of visible stuff to help performance at the cost of reduced information density?

The answer is mostly no. I really can't force the decision on the user. As the product designer, I have to make the decisions and based on how the users behave and feel, hide the configuration file under the hood.