Big problems in small steps
How Gall's Law can guide your approach to product development
Gnarly problems require gnarly solutions, right?
In a word - No. That is not right. Gnarly problems require simple solutions.
Gall's Law, a principle from systems theory, speaks directly to this topic:
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.
- Gall’s Law
Gall's Law suggests that for software teams seeking to build efficient, manageable, and scalable solutions, they should start with something simple and then evolve it. This means developing a basic version of the software that addresses some aspects of the problem effectively before expanding or adding complexity. In some cases, this is creating the entire “happy path”. In some cases, this is solving for only a portion of the overall problem.
Starting simple and building upon the initial solution with additional simple increments and solutions provides not only for a more malleable solutions, but creates optionality along the way. Evolving a system allows you to get something working and valuable into production and then, if warranted, shift focus to something else.
By keeping the system straightforward initially, teams can more easily observe how changes affect functionality and performance. This transparency helps in identifying which new features truly enhance the system and which might introduce unnecessary complexity.
Several years ago, I was on a team working with a major airline. Our mission was to rewrite their booking flow and they had put a great deal of money into high-priced consultants and designers who had come up with a very robust design. Naturally, the airline was anxious to get the whole thing done as quickly as possible. The entire effort was slated for 2 years of development before the big cut-over. There was not a moment to lose.
So you can imagine - they were disappointed, at first, when we opted for a more incremental approach.
We started with a change in routing that directed a small subset of traffic to our flow. At first, it was a portion of people who were flying solo on one way trips. This allowed us to get something into production within a matter of weeks. From there, we made small changes. Round-trip solo bookings. Bookings for more than one person. Bookings for people flying with small children. Multi-city trips. You get the idea.
Throughout the process, we learned more about how users actually interacted with the system, we were able to pivot our attention to account for new regulatory requirements, and we ended up with a solution that eliminated nearly $1M per year in anticipated infrastructure and licensing costs that proved to be unnecessary with the solution we created. Oh - and we delivered the solution about six moths ahead of schedule with more functionality than originally specified.
In the end, they were pleased with the outcomes.
As it turns out - Gnarly problems require simple solutions; simple solutions deliberately evolved over time.
Keep Gall’s law in mind when approaching your next gnarly problem. In fact, keep it in mind any time. If there is one thing I have learned in software development - if you don’t apply your core principles when it is easy, you certainly won’t do it when it is hard.