There is always a tradeoff between performance and composability. Legos are composable at the expense of performance. They can be used to make almost any toy imaginable: model trains, spaceships, robots, dinosaurs, buildings, etc. Of course, there are better toy sets for each of those categories, but none of them are as composeable (or popular) as Legos.
In contrast, iPhones are performant at the expense of composability. To push the limits of what is possible, everything needs to be built in a tightly integrated fashion at the expense of working well with other technologies. The first iPhone would not have been possible if Apple didn’t build the hardware, operating system, and applications under one roof in a tightly integrated way. Yet sending HD photos to non-iPhone users doesn’t work.
In software developer culture, the masters of performance optimizations are idolized. There are websites with Chuck Norris-style “facts” about Jeff Dean, who is credited with creating a lot of Google’s early infrastructure. For example, “Jeff Dean writes directly in binary. He then writes the source code as documentation for other developers”. As someone who learned to write software in this culture, I, too, suffer from the subconscious desire to become an optimization Übermensch.
Unfortunately, this culture has created a generation of technical startup founders who believe their product will become widely used because it is more performant than existing solutions. Performance comes in lots of dimensions, and this phenomenon applies to all of them: latency, throughput, efficiency, accuracy, and even user experience.
In the first few years, when no one is using the product, the founders double down and put all their resources into making their product even more performant. After a year or two of limited commercial success from further performance optimization, many technical founders succumb to self-doubt, start listening to the “business people”, and pour the rest of their money into sales and marketing accelerating their demise.
To get lots of users, your product doesn’t need to be more performant than existing solutions; it needs to be more composable.
Users suffer from the fallacy of sunk costs. Integrating with existing solutions keeps users from losing face for past procurement decisions. If a startup's product is 10x more performant than an existing solution, it’s embarrassing to the person who decided to adopt the existing solution. Embarrassing your users is not an effective growth strategy.
The software industry is full of popular solutions with terrible performance, which makes it the perfect honey pot for the optimization-übermensch in a Sisyphean pursuit to build performant solutions. Machine learning is one of the most computationally intensive types of programming. It would stand to reason that performance matters in an industry where training a single model can cost $4.6m and 355 years of computing time. Paradoxically, Python, the lingua franca of machine learning, is one of the least performant programming languages. What Python lacks in performance, it makes up for in composability. There is a robust ecosystem of libraries such as TensorFlow, PyTorch, NumPy, and pandas that can be easily installed across different operating systems and hardware architectures. Furthermore, most of these popular Python libraries are written in other programming languages (mostly C/C++).
I don’t doubt that a startup can build a more performant version of any software ecosystem, but I do doubt that anyone will use it. Instead, build the most composable product that works seamlessly with every existing solution. Stand on the shoulders of giants.
Thanks to Jonathan Ross, Lee Cronin, and Val Chiykowski for reviewing drafts of this.