The siren song of infinite flexibility
Many companies have lived and died trying to offer a product with infinite flexibility.
Actually, it’s not just a product - it’s an extensible platform with huge customizability. It integrates with, well, everything! If there’s something it doesn’t do yet, you can even write some custom code for an extension, or a scripting feature, or plug-in, or a webhook, or…
And the only problem is that people don’t want everything.
You need to solve a specific problem
As Gordon Brander writes:
People don’t want “anything at all”. They want something specific. To succeed, you need to solve a specific problem for a specific user and find specific product-market fit.
Sure, Amazon is the everything store, but first it had to be the book store.
[…] Spreadsheets are used by everyone for everything, but first they had to be used by someone for something specific. Spreadsheets had to find a first best customer [...] business owners and accountants.
Gordon Brander via Squishy Computer: The Zombocom Problem
It’s easy to forget the path-dependence of these companies. Even though they do everything now, they didn’t start that way. Dan Bricklin, the creator of the first spreadsheet program VisiCalc, is around and we can just ask him about the early design decisions influenced by serving those business owners and accountants (transcript edited for clarity):
(3:05)
What I was competing against was paper and a calculator. You have to understand that was what people would use. And if anything I did would be slower or more tedious to use than the calculator, people would say - hey, I’m going to do it by hand, I don’t need recalc [automatic recalculation, a core feature of VisiCalc]. And of course they would need recalc later, but we wouldn’t get over the hump [for them to try it]. So it had to be no harder than doing it with a calculator, a pencil, and paper.
(17:10)
Unlike VisiCalc, later programs like Excel required an equals sign to start a formula. It made the parsing easier. I didn’t want to do that because I wanted to minimize keystrokes - to be just as easy as doing it by hand.
(35:45)
If I type, say, 1 + 2 * 3, VisiCalc gives you 9, which is 3 * 3. Why? Because there’s no precedence. It goes in the same order as this cheap kind of calculator. Remember, I was going after calculators. People were not used to typing expressions into a computer. So to make it the same, there was no precedence, though you could force it with parentheses just like the calculator.
Dan Bricklin (creator of the first spreadsheet program, VisiCalc): Guest lecture at Carnegie Mellon University on February 20, 2019
Here’s the calculator:
Spreadsheets today are used for everything, but at the start VisiCalc was for accounting, and it needed to beat the calculator-and-paper experience. It was so successful that forty years later, many of the VisiCalc keyboard shortcuts still work in Microsoft Excel.
And a personal anecdote: when we were first building out Anjuna Northstar (note: my writing here is always my own, not my employer’s), I thought that the ability to “run any code” would be a bigger differentiator - infinite flexibility and power! But in early interviews, I got a lot of shrugs about “run any code”. Customers wanted to know more about policy and security controls, as well as interactive workflows, so we doubled down there instead.
As I learned, the ability to run any code is not an advantage, especially for technical or developer-focused products. Programmers can already run any code! Why would they bother to run it on your platform, instead of in their existing code-running platforms?
Even those platforms that look like “run any code” have killer features for developers:
Docker (containerization) ensures that code that “works on my machine” also works in the production environment, avoiding deployment headaches.
Heroku (orchestration platform) provides a happy path for various operational tasks and makes it easy to scale.
Lambda (serverless) is an operational and billing innovation: just pay by the function invocation instead of worrying about infrastructure or state, and AWS will take care of the rest.
So why do people still chase flexibility?
Solving specific problems requires less powerful tools
We often assume more power is better, more flexibility is better - why wouldn’t we want it? But it’s actually easier to solve specific problems with tools that are constrained. Surprising? Maybe not.
In the physical world, there are plenty of colorful idioms about using a tool too powerful for the job: using a sledgehammer to crack a nut, killing a fly with a cannon, cutting butter with a chainsaw. There are real and obvious downsides to using a too-powerful tool. Power comes at the cost of precision or ease-of-use.
But in the digital world, software engineers almost always write powerful, flexible, and precise code. When you’re used to wielding the hammer of code, every problem really looks like a nail. And in programming, specific tasks are usually straightforward, unless they are virtually-impossible:
(And an added challenge is that line of virtual-impossibility shifts all the time - since the comic’s publication in 2014, computer vision has advanced to the point where it is now straightforward to detect a bird in a photograph).
So the physical-world tradeoffs of power versus precision and ease-of-use don’t really exist in the same way for software tools. Yet, there still exist meaningful and useful programming constructs, used by programmers daily, that intentionally restrict the power of their tools.
Hillel Wayne writes about one of the most basic functions of programming: iterating through a list (array) and doing something with each item. As a programmer, you have a lot of options to choose from: goto vs. while vs. foreach vs. map/filter/reduce, each with their own tradeoffs.
But you shouldn't use a goto when a while loop works or a while loop where a for loop works. This is a generalization of the rule of least power (RLP): given a problem, use the tool that is most specific to the problem. If you can iterate through a list with a foreach loop, don't use a while instead!
There's two reasons for this. One is that it's more communicative to other programmers. If they see a foreach loop, they know it's going to be used for some kind of iteration, while that's not clear with the while loop.
Two is the capability/tractability tradeoff: the more limited a construct is, the easier it is to understand and work with (emphasis added). A foreach loop can do less than a while loop, but it's much easier to guarantee that it processes each item only once.
Hillel Wayne via Computer Things: “Some notes on for loops”
The more limited a construct is, the easier it is to understand and work with. There is a real mental trade-off between a tool that Does One Thing and Does It Well versus a tool that can do anything in the universe (if you put your mind/code to it). And in a team setting, your teammates will also be able to narrow their focus to the important part of the logic.
I used to work on a product to help software engineering teams build, test, and deploy their software safely (CI/CD pipelines). It was incredibly flexible - you could chain together huge sequences of independent steps, pass around context to later steps, run steps in parallel, send notifications, and more.
And yet, the majority of teams used one or two basic pipeline templates to build, test, and deploy their software. When they were just getting started, those software engineers considered the core deployment experience, not an infinitely-powerful custom workflow orchestrator. The flexibility came in handy only later, after they had scaled past those core capabilities and needed something custom.
–
Infinite flexibility is a siren song: attractive, yet dangerous. Today, we are far from a really great do-anything product (that’s one reason why chatbots are so frustrating). Therefore, we need to create some great do-some-specific-thing products.
In practice, great products are not infinitely powerful. In fact, they are guardrailed to ensure the specific task happens in the way you actually want. That’s why your email client prevents you from sending the “wrong” kind of email - limiting your power helps you improve your control.
There’s a quote from Antoine de Saint-Exupéry: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” The perfect tool is just powerful and flexible enough - and no more.