Gall's Law and Big Ball of Mud

Gall's Law says:

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.

The law appeared in Gall's 1975 book Systemantics: How Systems Work and Especially How They Fail. Surprisingly, Gall's day job was a pediatrician. For example, one of his other books is Hit By a Low-Flying Goose: And Other Cautionary Tales. Notes from the Life and Practice of a Pediatrician and His Wife. Although both of those books are out of print, his The Systems Bible: The Beginner's Guide to Systems Large and Small is available on Kindle.

A good example of Gall's Law in action was Netscape's decision to completely rewrite its browser. As described by software guru Joel Spotsky in a 2006 blog post titled Things You Should Never Do, Part 1:

They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
...
Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

There is no real part 2 to this post, unless you count Netscape Goes Bonkers which Joel wrote later the same year, and which covers some of the same ground.

The Alternative

So what's the alternative to starting over completely?

An essay by Patricia Hernandez titled The Truth Is That Many Games Are Held Together by Duct Tape reveals the answer. She tells the story of how game developer Terry Cavanagh published the source code of his old game called VVVVVV. It turned out to be a mess, and he came into a lot of criticism for not having elegant, beautifully structured, easily readable code.

However, as another game developer, Mike Bithell, pointed out:

There’s a word for games where the code is barely hanging together, with stupid layout, utterly unscaleable fixes and workarounds on top of workarounds: “Shipped”

Or, as Steve Jobs put it tersely, as related by Andy Hertzfeld: Real Artists Ship.

The only computer-game where I've seen the source code was the old text-based game called either Adventure or The Colossal Cave. It was written in spaghetti-code Fortran, with a lot driven by data in a big file (the rooms in the cave, the objects, etc) but with lots of special-case stuff in the code. Stuff like "if the person is in a room with the snake and is carrying the cage and the bird is in the cage and the person opens the cage then the bird attacks and kills the snake". The reason I've seen the source code is that when I was at an Open University summer school, one of my colleagues had a printout. So we cheated and used the source code to get through the entire game. It turns out that the source code is at Colossal Cave Adventure Source Code even today.

Big Ball of Mud

Twenty-five years ago, I read a now-classic paper by Brian Foote and Joseph Yoder that they presented at the Fourth Conference on Pattern Languages in Programs which took place in 1997. It is titled Big Ball of Mud. As it says in the first few lines of the abstract:

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

Some aspects of this paper remind me of Fred Brooks' writing, see my post The Mythical Man-Month for more about that. Brooks wrote about Chartres Cathedral. Foote and Yoder go to the church in Red Square, Moscow. Their closing remarks:

People build BIG BALLS OF MUD because they work. In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can compete.
...
The onion-domed Church of the Intercession of the Virgin on the Moat in Moscow is one of Russia's most famous landmarks. It was built by Tsar Ivan IV just outside of the Kremlin walls in 1552 to commemorate Russia's victory over the Tatars at Kazan. The church is better known by its nickname, St. Basil's. Ivan, too, is better known by his nickname "Ivan the Terrible". Legend has it that once the cathedral was completed, Ivan, ever true to his reputation, had the architects blinded, so that they could never build anything more beautiful. Alas, the state of software architecture today is such that few of us need fear for our eyesight.

I started this post with an aphorism, Gall's Law. Let's finish with another aphorism, this time from Andrew Hunt of 37 Signals:

Simple rules produce complex behavior;
Complex rules produce stupid behavior.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.