Gall's law
In a timely coincidence, I came across Gall's law on Daring Fireball the other day.
From Wikipedia:
A complex system that works is invariably found to have evolved from a simple system that worked. 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.
It's been on my mind since.
I've found myself thinking about examples of Gall's law that I've encountered. The two that immediately came to mind:
- The Unix philosophy of "do one thing and do it well"
- Building logic gates in a NAND-to-Tetris exercise
At sc0red, we've been doing user validation on prototypes for an upcoming revamp of the core application. We're now starting to architect the system in preparation for development.
As part of planning and architecture phase, the team spent a good chunk of this week working on an entity relationships document in preparation for building our database. The idea is that spending real time at this level—making sure the concepts make sense on paper—will lead to a well-architected database that we can build upon.
We break things down into their smallest parts, interrogate their existence, and reason about how each part relates to other parts in the system. This enables us to then implement simple primitives. If we do that well, we can make simple systems. Those simple systems enable us to build a complex system that can carry a reliably effortless user experience.
In the day-to-day at sc0red, I often find myself advocating for a user-centric "outside-in" approach to learning, decision-making, and prioritizing. We start with the value we can deliver to customers and work backward from that.
But there are moments in application development where you need to flip that narrative. You've got the user-validated prototype that brings the vision to life. It's necessarily a complex system. How are you going build up to that?
Gall's law is such an easy concept to leap past when teams are chasing market realities and deadlines. It's possible to get away with avoiding it for a period of time. But it can't be ignored forever; it will catch up with you.
So I'm really proud that our team was up for taking time at the outset of our app revamp to architect a solid conceptual framework for the entities in our system. Now we build.