Published 2025-05-05
This post might sound like a "hot take," but I promise it's not -- it's backed by over a decade of working across startups and some of the biggest engineering organizations on the planet.
The only solution to maintainability is the default, from upstream or otherwise.
Whenever I get a new phone or laptop, I like to customize the system. I
change the wallpaper, the colors, sometimes switch the theme to
dark/light/custom. Then I start customizing the terminal/shell, adding a
different font, usually using something like git to clone my
dotfiles repo, and then I start adding packages for utilities I
prefer over the posix shell.
All of this customization is contained to my personal system. It's not something you, the reader, have to deal with. It's not something anyone who's not hands-on-keyboard or remotely shelled-in to my system has to care about.
I want to emphasize this point:
The customizations only affect me
This is why defaults matter. From a platform engineering and SRE perspective, you may want to offer customizations for those "rare" exceptions to the default, but a supermajority (the higher, the better) of customers must be satisfied with the defaults.
This leads us to two axioms:
If a setting captures a supermajority of users but is not a default, it must be made a default.
If a default cannot capture a supermajority of use-cases, you must remove the concept of a default entirely, forcing each user to specify the setting each time.
We now have two key points:
This type of exercise is often done once and then forever left alone. When it comes to "release to the public" utilities and services, then that type of one-off decision making is acceptable, if only because trying to "fix it" with the global population of users can be impossible. (See OpenSSL and default ciphers versus libressl/boringssl.)
When corporations build their own internal platforms, utilities, and software for corporate consumption, one-off decision making is a terrible design decision which leads to unmitigable tech-debt, increasing development and maintenance costs across all sectors which use said tool.
Take an example of a certificate management platform. Let's say you have
two runtime targets, A and B, and you can generate certificate types of
X, Y, and Z. Among those six possible combination options, if a majority
are A:X and B:Y, you're in a position to say "All runtime on A by
default uses Certificate Type X and all runtime on B by default uses
Certificate Type Y."
If, however, you're not able to provide a single solution for those environments, any kind of default will need to be constantly overridden by your users. If you provide a default that matches only 20% of environments, why is that the default and not "nothing"?
Defaults make a decision that the user either has to accept or modify for their particular use case. If you don't choose a default, the user must make the decision each time. Defaults save time only for those to whom the default applies. This ends up being a penalty for everyone to whom the default does not apply.
Teams building solutions for a company need to make decisions that affect that solution for its entire lifetime. Defining a default means establishing an invariant in the code.
When a different team, or a different engineer, starts using the service or system, they're going to expect the unconfigured system to meet their needs. People don't immediately sit down and try to customize and configure a system they are entirely unfamiliar with; they will try the defaults first and then customize as they go.
Yuo've got a service or a system with defaults already shipped. Well, that's going to be nearly impossible to change user habits if it's already in-use. If you have the authority to do so, suggest removing defaults in favor of "required options" or change the default to meet the true majority of users (whatever that aligns to).
If you are building a new service, please don't specify a default. If you do know exactly what your users want and can show it with data, feel free to establish a default.