Applications of Gall's Law

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.

• Version control system: git vs. [darcs](http://darcs.net/Theory/PekkaPatchTheory) – git was borne out of Linus's specific projects developing the Linux kernel. It started off with only 1244 lines of code (today it is over 200,000). On the other hand, darcs was a patch-algebra distributed version control system that was written in Haskell. Despite being more sophisticated in many ways (and theoretically correct), it never caught on.
• Netscape took three years to do a full rewrite of the software, without any intermediate major releases. The rewritten version lost years of embedded knowledge, bug fixes, and optimizations. Joel Spolsky details the history in Things You Should Never Do, Part I.
• Protocols like TCP/IP vs. OSI, WWW vs. Gopher – Working code (even underspecified) is often better than a draft by a standards committee. Simple protocols mean simple clients. (Why Do Protocols Win?)
• Big projects that failed because they were non-incremental complex systems from the start: Google Wave, Project Xanadu, and OpenStack.

My own experiences:

• I used to use a complex system for planning, TODOs, note-taking, and knowledge management. Yet, I always failed to keep these up. At some point, I moved over to the simplest solution – Apple Notes. Over time, some structure has emerged out of those notes, but it has never been planned.
• Success with leaving services as monoliths before splitting into microservices – The U-Shaped Utility of Monorepos
• In product – not building too much before talking to users, getting feedback, and iterating.

One always begins with the simple, then comes the complex, and by superior enlightenment one often reverts in the end to the simple. Such is the course of human intelligence. – Voltaire