Technology has become part of life and learning its beginning, even though we don’t see the end yet, is exhilarating.
Part 1, 2 and 3 of this tech series have opened our minds to exciting aspects. Hence, we bring part 4.
Gall’s Law: Why the best products are built from simple systems
In 1975, the American author and pediatrician John Gall made an observation about systems that would go on to become hugely influential in computing.
“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 idea, originating in his book “General Systemantics,” would eventually become known as Gall’s Law. Since then, it has become one of the most important and foundational ideas in tech, especially when it comes to the design of new products.
How Gall’s Law Fosters Products that People Actually Want to Use
One concept that can help illuminate the power of Gall’s Law is the idea of emergence: the notion that complex systems possess properties that the individual constituents of the system do not.
Powerful technologies can be built when users can manipulate and recombine individual pieces in order to create something of greater value.
Twitter, for example, was founded without reply or retweet functions. All users could do was post 140-character messages to their feeds.
Then Chris Messina proposed the idea of using a hashtag to collect all tweets relating to a single topic, and not long after, hashtags were added into the Twitter platform itself.
Replies and retweets followed later as the Twitter team realized that their users were trying to approximate these actions within their constrained set of possible behaviors.
Twitter could have predicted that users of a public broadcasting app would want some way to share content with their followers, reply to other people’s messages, and even organize information along topical lines.
But cultivating an openness to what users actually did, rather than assuming they knew exactly what to build, was key to how Twitter developed into the product it would become. As co-founder Evan Williams put it, it wasn’t even clear “what [Twitter] was” in those early days, and the product took several turns before settling on what it is now.
This kind of emergence-friendly development process is more or less conventional wisdom in Silicon Valley today, with the creation of a “minimum viable product” (MVP) being standard practice within product businesses.
The thinking behind the MVP is simple and echoes the development processes followed both by Amazon in inventing AWS and by the team at Twitter: build a version of your product with just enough functionality that it can engage your core users. Roll that initial version out and start gathering data and feedback. Then, use that data and feedback to chart the path forward. When done right, the result is what Gall’s Law predicts: a complex system that has arisen from the organic growth of a much simpler system.
How Amazon Followed Gall’s Law to Dominate Cloud Services
The development of Amazon Web Services (AWS) from an internal data storage service to a crucial backbone of the internet encapsulates the power of Gall’s Law.
AWS emerged from a relatively simple desire: Amazon needed a more modular system for its internal engineering work.
Every time a team at Amazon wanted to build out a new web feature, whether for internal use or for a retail partner, Amazon developers would end up building everything — from databases to computing power to storage — from scratch.
That’s when the idea emerged to build out each one of these functions as a modularized service. For one, the team had become highly competent at working on these functions. For another, the Amazon team was operating at a unique scale, being one of the biggest early internet companies.
It soon became clear that Amazon had an equally unique opportunity to make databases, computing, and storage easier for other companies and other developers to use.
“We tried to imagine a student in a dorm room who would have at his or her disposal the same infrastructure as the largest companies in the world,” Andy Jassy, then-head of AWS, told Brad Stone, author of “The Everything Store.” “We thought it was a great playing-field leveler for startups and smaller companies to have the same cost structure as big companies.”
While AWS today appears to be an intimidatingly complex system, it emerged from the interaction of a very simple set of modules designed for Amazon to use internally.
The concept was heavily inspired by the 2003 book “Creation,” written by game designer Steve Grand. Grand’s design approach had centered around building simple creatures, then sitting back and “watching surprising behaviors emerge.” For Amazon’s then- CEO Jeff Bezos, this idea proved perfectly applicable to computing.
On the influence of “Creation” across Amazon’s leadership, Brad Stone writes:
“If Amazon wanted to stimulate creativity among it’s developers, it shouldn’t try to guess what kind of services they might want; such guesses would be based on patterns of the past. Instead, it should be creating primitives — the building blocks of computing — and then getting out of the way. In other words, it needed to break its infrastructure down into the smallest, simplest atomic components and allow developers to freely access them with as much flexibility as possible.”
Today, Amazon Web Services drives over half of Amazon’s operating profit and about 16% of its overall revenue.
Feature Bloat: What Happens When Companies Flout Gall’s Law
Tech history is full of products that failed because they went the opposite way of Twitter and Amazon: they built over-engineered products, bloated with features, that lacked enough simple utility for users.
One of the classic examples of feature bloat is ICQ, the once- popular instant messaging client. In a 2007 blog post, Robert Scoble attributed the service’s sudden decline mainly to over- engineering: “It got too cluttered and stopped being developed.”
At one point, ICQ had been the king of instant messaging. In 1998, AOL bought the company behind ICQ for $287M upfront and $120M in performance-related payments. The service had more than 100M accounts registered around the time it peaked in 2001.
For Scoble, that’s where the decline, and the clutter, started. ICQ started branching out from its core utility by adding features around shopping, music, games, and even careers, resulting in a busy interface that felt removed from the purpose of the product.
At the same time, new products like Facebook were emerging that allowed people to more organically connect with their friends outside the constraints of a messenger.
“Feature bloat is how most consumer web and desktop products suffocate themselves,” Dropbox co-founder and CEO Drew Houston has said. “ICQ became so comically bloated that they released an ‘ICQ Lite’ version, but by then they were already on the decline.”
Releasing a “lite” version of a product might make sense if you’re differentiating it from a “premium” version that serves an audience with more complex needs, but ICQ and ICQ Lite were the same basic product for the same basic target user.
The release of a “lite” version, in this case, could be seen as a way to actually offer a superior product — an attempt to cut the feature bloat that had crept in over the years.
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.