Complexity in Tech: The Emergence of Higher-Order Systems

This is the second in a series of five postings responding to a recent white paper from CB Insights (CB-Insights_Laws-Driving-Success-In-Tech.pdf) that made the following claim in its headline:

What separates success from failure? These 11 laws contain some of the most influential ideas that the biggest tech companies use to run their operations, design business models, and build products.

Here is the list of the laws involved:

1. Moore’s Law
2. Metcalfe’s Law
3. Law of Mobility
4. Gall’s Law
5. Law of Modularity
6. The 2-Pizza Rule
7. Conway’s Law
8. Yule’s Law of Complementarity
9. The Law of Shitty Clickthroughs
10. Zimmerman’s Law
11. Pareto Principle

The first post discussed items 1 through 3 as drivers of exponential growth, something high tech has been blessed with in a way no other sector has. This post will look at items 4 and 5 in the context of how the scope and reach of tech continues to emerge from the unplanned interactions of simpler subsystems.

Gall’s Law

Here is how the CB Insights paper presented Gall’s Law. I had never heard of Gall, but I was familiar with the idea, and I expect you will be too:

“A complex system that works is invariably found to have evolved from a simple system that worked,” he wrote. “A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

This is the fundamental principle behind the idea of emergence, the one that underpins the entire argument of my recent excursion into writing on philosophy, The Infinite Staircase. Certainly, when it comes to evolution, it holds true. In the secular worldview, nothing that lives on Earth was designed from the top down. It all evolved from the bottom up. 

Gall extends this principle into the domain of intellectual creations. By adding in the phrase “that works,” he incorporates natural selection directly into the dynamics of systems development. As developers of complex systems, we may say we have invented our creations, but Gall would argue that, if they work, they will be found to have been composed of pre-existing subsystems that worked.

OK, so far, so good. Don’t try to reinvent the wheel—work on the bicycle instead. But there is a much more magical element baked into this law, which is that complex systems emerge without benefit of any prior planning! Indeed, one might argue that planning could actually be a deterrent, as it will bake in constraints that turn out to be unnecessary. Look at what APIs have done for the evolution of complex systems on top of the Web. No one planned for Uber. No one planned for Zoom. No one planned for the iPhone. Indeed, in every case, there were planned systems that were completely disrupted by the emergence of these innovations. And all three, as innovative as they undoubtedly are, consist entirely of the creative assembly of preexisting subsystems that were created by other enterprises and went viral in part due to accidental discoveries made along the way.

That all said, CB Insights’s final takeaway is somewhat misleading:

TAKEAWAY

Today, with free trials, SaaS, and subscription business models in vogue, it’s more sensible than ever to produce a minimum viable product (MVP) and iterate on it based on user feedback.

While companies should avoid feature bloat, aiming for a gradual evolution from simple functionality is a way to build a growing product that actually reflects users’ needs.

And according to Gall’s Law, products that start small — as simple, effective systems — stand the best chance of becoming powerful businesses built on high-functioning, complex systems.

This takeaway holds true for the all-digital volume operations business models, the only caveat being that, if there is a recession coming, the consumer budgets that fund these businesses are going to be under water. But the notion that successful volume operations businesses can convert their success into a complex systems franchise down the road does not hold. Yes, those franchises will come, but no, they will not be developed by their volume operations predecessors.  The two models are antithetical to each other in every dimension. They can interoperate, but they cannot blend or merge.

Hence the need to turn to Law #5, which CB Insights titles as Law of Modularity: Why building blocks are essential to modern tech design. 

My only quibble here is to say that modularity is essential to modern complex systems design. High-volume, transactional applications can afford to be monolithic—high-value, adaptive systems cannot. Modularity is what allows complex systems to evolve, incorporating bits and pieces of volume subsystems in one place without having to rework every other part of the overall system to accommodate them.

Sounds obvious—what’s the problem? Well, perhaps you have heard the phrase tech debt. The problem is we only have a finite amount of time to field systems to meet our current needs, and as that window of opportunity begins to close, we take more and more shortcuts to get ourselves in under the wire. Every one of those shortcuts violates the principle of modularity, but what else can we do? The net result is unintended monoliths squatting like tree stumps in the midst of what was intended to be a modular field. And from then on, every time we come up to a stump, we have to plow around it, working feverishly to neutralize the start-ups that are still playing on an open field. We refactor when and as best we can, but it is always a rear-guard action. This gets even more complex when we use M&A to fill in a hole in our product line and then want to integrate down the line. The oft-made promise of seamless integration is right up there in the credibility standings with your check is in the mail. 

Nonetheless, modularity is the name of the game, and complex systems vendors must play it the best they can given the cards they have been dealt. As CB Insights says in its takeaway:

TAKEAWAY

Across both hardware and software, modular design can drive a step-change in the value of tech products and services — both for the end-user and for the business itself.

Flexible, customizable, and interoperable systems can also invite outside engagement, whether by creating space for third-party developers to build on top of a platform or through APIs that create new value via interconnected services.

Ecosystems keep complex systems in demand by designing the next generation of offerings on top of the prior one. IBM, SAP, and Oracle may no longer be their former modular selves, but they aren’t going away any time soon. Like a coral reef, each provides numerous nooks and crannies for a host of organisms to live and thrive.

That’s what I think. What do you think?

Follow Geoff on LinkedIn | Geoffrey Moore Main Mailing List | Infinite Staircase Mailing List

__________________________________________________________________________

Geoffrey Moore | Infinite Staircase Site | Geoffrey Moore Twitter | Infinite Staircase Twitter | Facebook | YouTube