Why do so many declarative systems cause more pain than relief? 3 reasons why I think many declarative systems make the wrong tradeoffs for the majority of users.

Reproducibility over velocity. Bazel is the open-source version of Google's internal declarative build system. It requires you to declare all of your build dependencies before the build begins, with no dynamic dependencies. This ensures that for a given set of inputs, you get the same outputs every time. In theory, it is "reproducible", but in practice, is its nearly impossible to get byte-for-byte reproducibility – it is a spectrum. Inside Google, all external sources are copied in, in the real world, we deal with thousands of nested and dynamic dependencies and external code over the network. Declaring each of them is a painful task. (what about security?)

Verbosity over convention. Determining state can often be more complex than the imperative commands to generate the same state. Verbosity runs wild in declarative configuration like Kubernetes. Engineers end up writing thousands of lines of configuration, or writing code to generate configuration. Convention is difficult to embed into declarative system – the more a system assumes, the more it either becomes rigid or imperative.

Correctness over intention. NixOS uses a declarative package manager that stores packages in a content-addressable way. In many ways this solves some of the issues of dependency hell. Nix packages are written to be "correct", but often don't follow what the intention of the author or user is. Installing a package or setting up an environment can be difficult and complex, even if it is reproducible.

What's the fix? Declarative systems tend to be built in a world that's binary: correct or incorrect, reproducible or not, verbose or bespoke. In reality, each of these trade-offs lies on a spectrum. The answer is somewhere in between.

Clayton Christensen famously proved the Innovator's Dilemma by using data from the hard drive industry in the 1980s. At every point, companies failed to make the switch from 8-inch drives, to 5-inch drives, to 3.5 inch drives. Capacity and speed increased exponentially every year. Many of these companies faced strong downward pricing pressure and slim margins.

But cloud storage is different. AWS S3 is the fundamental cloud storage service. So popular that its API has become a de facto standard that other clouds have adopted. Massively complex, it sits behind a simple (simple storage solution) API. Store files. Retrieve files. Delete files.

Yet, AWS S3 pricing hasn't decreased as fast as the underlying storage costs. This doesn't include the additional fees like egress. Of course, prices vary by storage tier and region, but this seems to be a general trend. It follows that AWS has strong pricing power when it comes to storage, even with API-compatible competitors from Google and Microsoft. S3 seems simple on the surface, but is not a commodity. Two months after Cloudflare announced their free egress storage solution, R2, AWS cut prices on certain S3 products.

Another blog post analyzes the same theory for compute and finds a similar story using pricing data from AWS EC2. It's hard to come to a firm conclusion, since pricing data is held very secretly (AWS quickly deletes announcements of historical price decreases). Even with a slowdown of Moore's Law, it seems like AWS has a healthy margin to continue to offer strategic price cuts only when necessary.

Prioritizing the right features to build in your product is one of the most important parts of product management. Some features create more customer value than others.

But can picking the wrong features actually make your product less valuable to your customers? Odds are that most features are negative value features.

Features can have a negative value to users: they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are harder to produce than designs that assemble long lists of features.
-- Douglas Crockford, JavaScript: The Good Parts

It's not only the obvious negative value features: ones that are annoying, redundant, or broken for users, but also good-willed ones that work and solve a real problem – just not your customers'. The mismatch between perceived and actual customer value shows up in pricing and marketing – products priced too high and segmentation pitfalls to name a few.

Keep Your API Surface Small with any sort of product, technical or not. Experiment on willingness-to-pay.