<p>Mon, Nov 30, 2020<br /> Complexity in software, whether it’s a programming languages, an API, or a user<br /> interface, is generally regarded as a vice. And yet complexity is exceptionally<br /> common, even though no one ever sets out to build something complex. For people<br /> interested in building easy to use software, understanding the causes of<br /> complexity is critical. Fortunately, I believe there is a straightforward<br /> explanation.<br /> The most natural implementation of any feature request is additive, attempting<br /> to leave all other elements of the design in place and simply inserting one<br /> new component: a new button in a UI or a new parameter to a function. As this<br /> process is repeated, the simplicity of a system is lost and complexity takes<br /> its place. This pattern is often particularly obvious in enterprise software,<br /> where it’s clear that each new feature was written for one particularly large<br /> customer, adding complexity for all the others.<br /> Every feature request has a constituency – some group who wants it<br /> implemented, because they benefit from it. Simplicity does not have a<br /> constituency in the same way, it’s what economists call a non-excludable good<br /> – everyone benefits from it. This means that supporters can always point to<br /> concrete benefits to their specific use cases, while detractors claim far more<br /> abstract drawbacks. The result is that objectors to any given feature adition<br /> tend to be smaller in number and more easily ignored. Leading to constant<br /> addition of features, and subtraction of simplicity.<br /> Escaping this viscious cycle is not easy. One can easily say, “so reject all<br /> feature requests”, but a project that does so will eventually find itself<br /> unable to serve its users’ needs at all! Our approach must be more measured: we<br /> need to spend as much time thinking about how a new feature will burden all of<br /> our users, as we spend thinking about how it will benefit some of our users. We<br /> should also spend time thinking about how to design new features in a way that<br /> maintains what Fred Brooks’ called the “conceptual integrity” of a system,<br /> rather than by merely tacking something new on. </p> <p>Let&#8217;s block ads! (Why?)</p>