What if Gall’s Law were true?

Thanks to Bokardo.

 

 

What if Gall’s Law were true?

via Bokardo - Social Design by Joshua Porter by Josh on 12/1/08

An interesting bit came across my twitterstream the other day:

Gall’s Law

“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 working simple system.”

Yup, seems to hold for the complex systems we know and love: organic life, government, law, medicine…and of course Twitter.

Let’s imagine for a moment that it does hold. This would change lots of things, including much of the software world, which is laden with complex behemoths who frustrate us daily.

1. Building simpler software from the start
   Obviously, if Gall’s Law is true then more teams would start out building really simple software instead of overly complex stuff. Sometimes, though, it’s hard to think that way. Instead, the thinking seems to be, if we’re going to be as successful as (X), then our system needs to do more than (X). But in complex, social software, that may actually be impossible, since (X) didn’t spring fully-formed into life, either. Most of the software people try to emulate quickly took years and years to evolve to where it currently is. (as an aside, my recent argument is to focus on designing to support a specific activity and nevermind emulating success for its own sake)
2. Meeting solid metrics before adding features
   This is an interesting idea: make sure that your software works at some basic thing before you add features to it. I’ve seen on a couple projects in which there was a tension between the current under-performing software and the ambitious engineering plan that adds a lot more features. Which do you do? Stop and get people using the simple software first or push on and hope that people will come flocking after you’ve added a few more features? Well, according to Gall’s Law you get the simple software working first. My question is…are there teams who actually do this? Are there any that have actually said: “we have not reached our initial goals, let’s stop adding features and work on the ones we already have”?
3. Changes by design
   The overall effect of Gall’s Law is that most software would start off simple and evolve over time. So we wouldn’t end up with the software we imagined, but the software that managed to live through the early use and subsequent selection process. Accepting this as a rule, could we somehow plan for this evolution even though we don’t know what it will bring? Can we plan for this change? I think so, by building in feedback and reporting mechanisms and merely acknowledging to change the design based on such feedback.

Of course, the reason why we add feature after feature is because we don’t realize we’re doing it: we don’t see the accumulation of complexity…we only see adding “one more thing”. In the same way that a camel wouldn’t feel the slight addition of weight but ends up with a broken back, we don’t really feel each additional feature until its too late.

Gall’s Law might not be an actual law, but it sure seems like a good thing to keep in mind when you get into those inevitable project debates about improving what you have vs. adding new features.

Posted by email from Staysmall's posterous