Hero Image

Gall’s Law and How I Ignored It

This is one of these entrepreneurial pitfalls that, once you come across to realize you have been doing it wrong all this time, the business perspective of your ideas gets shaken like a 9.0 Richter earthquake. Such an incredible realization could only come from the simplicity of business processes and value-adding approach to work.

Gall’s Law states the following:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.

John Gall, systems theorist

I think we entrepreneurs are vulnerable to admiring the results rather than the process. We suffer from seeing the endgame, but not the constituents of the business systems we are attempting to create. What I mean by this is we create in our minds a piece of greatly complicated machinery, trying to chew up more than our mouths can handle, without realizing the impending doom of our endeavors.

What if my side-business initiative is too complicated, but I think it's justified? You increase the risk of it not working. The more variables you insert into the equation, the more you have to hunt for problems. If it’s not working, it's less straightforward to find out what the problem really is. If your initiative was simple, you'd have less trouble finding out roadblocks and bottlenecks. Simplicity is the ultimate sophistication.

Some of your grand ideas lacking execution, are actually Rube Goldberg machines that are way too complicated to operate appropriately, if at all. Let me explain myself by using an example business idea: Let’s say I wanted to make a P2P currency exchange whose interface is a chat bot instead of a web/mobile application.

Based on this statement, How would you violate Gall’s Law in this scenario? Some answers:

  • You define all the system's requirements and specifications, features, flow charts, documentation, etc., over an unproven concept. Maybe launch an MVP that flops.
  • You fail to realize that unproven ideas are hypotheses, instead of solid theory, so you treat all the assumptions you collect from your fantastic idea as truth. Extending a bit further, you fail to validate your idea, and potentially your ego might be getting in the way of being proven wrong.
  • Parallel to the above idea: Most of your projected features go unused because you thought these were awesome to have.

The point of this blog post is not to destroy your desire to start an initiative but to set an example on a simple approach that focuses on results using the least amount of resources possible. If your idea works, you will need those resources to further scale the operation, and I want to emphasize the key phrase here: “scale a (functioning) operation.” Functioning in this context means: Getting revenue and perhaps, some profits.

How would you apply Gall's Law to this scenario? Here are some examples:

  • You register a bot (perhaps using the BotFather at Telegram) and interface it with an application that enables you to see the received messages from the bot, so you execute these exchange orders manually. If you ever find yourself working too hard, it’s time to look for automation. This in itself is idea validation. Another classic read about this is Do Things that Don’t Scale.
  • While creating a simpler version of your product, you use existing software or low to no-code tools. You can always later optimize a functioning business idea by developing a far more polished system after you have justified it with a strong business case and technical case that you will need it. Otherwise, it just becomes another wasteful expenditure.

Another way to understand Gall’s Law is to take Merriam-Webster’s definition of evolution, which says:

The act or process of going from the simple or basic to the complex or advanced.

A functioning simple or basic system that works (it does the job, it gets revenue), is over a million times better than a complex system that is dysfunctional (people hate to use it, you struggle to get customers for it).

Start simple. Make sure it works. Until next time.

Discuss on Hacker News.

blog comments powered by Disqus

Other Related Posts:

Economics of Software Performance

Disclaimer: I’m presenting this post without any figures or math, so it’s just my opinion based on professional past eye-witnessed experiences. This post will not be about hate, but rather on the weaknesses of delivery of recent trending technologies.

Recently I’ve seen a dangerous trend in software development, more specifically about web and desktop technologies. I wish not to bash on software frameworks such as Electron, but I think there are hidden costs for both junior developers and enterprises are ignoring. Let’s dig a bit deeper ahead.

10th Dec 2020