Gall's Law maps to building "The simplest thing that could possibly work."
However, one can work at an even smaller granularity. "The simplest thing that could possibly work," can be made out of stupid things that won't work. To build the networking for an MMO, I cookbooked a websockets chat demo, then used it to pass updates from the server to the client. No login mechanism. No security. No dead reckoning. No fancy synchronization. All those things can be added later, however. It will be easier to add them to a running system. (Provided one also refactors to clean up code.)
If you're stuck at how to proceed, feel free to stub out features in a way which can't possibly work in production, but which will let you compile, run, and test your system. It's always easier for me to modify a running system than it is to big-bang an entire system from scratch.
Gall says nothing about the simplest thing, only that complex systems grow out of simple small ones. I mention this not to be a stickler, but to highlight the interesting possibility that "the simplest thing that could possibly work" might not actually (or always) be something that a complex later system can evolve out of. We don't know that. I'm reminded of a comment by Alan Kay about how you don't want the lowest stratum of a system to be too simple.
Gall says nothing about the simplest thing, only that complex systems grow out of simple small ones.
My point is just that the way Gall's Law maps to something like Extreme Programming is through, "the simplest thing that could possibly work." When one is starting out a new project, that is precisely how one applies Gall's Law.
"the simplest thing that could possibly work" might not actually (or always) be something that a complex later system can evolve out of.
Software shouldn't be that limited. In particular, of you are using principles/tactics like DRY and Law of Demeter, you should be able to grow your project into a more complex one. (Or, in preparation for growth, apply those and then refactor.)
I'm reminded of a comment by Alan Kay about how you don't want the lowest stratum of a system to be too simple.
This is probably because the lowest stratum can be the hardest to change. In software, it's even possible to take away the foundations and exchange them! I've worked with people who have done it. (Migrate an app from an Object Database to a relational one, for example.)
>Gall says nothing about the simplest thing, only that _SUCCESSFUL_, complex systems grow out of simple small ones
Fixed. Missing a key word. The whole point of the law is that complex systems can be built from scratch but will fail. The successful ones grew organically.
Weapon system designers sometimes observe that an older system on its nth iteration can be better in the field than the revolutionary new ground-up design. (Until the latter gets to its nth iteration.)
"to highlight the interesting possibility that "the simplest thing that could possibly work" might not actually (or always) be something that a complex later system can evolve out of."
One of my big focuses when I'm designing a system is not to get everything right up front, but to always be looking two or three steps ahead and making sure there is a reasonable path to get to where we need to be. It's one of the ways in which I definitely do not 100% subscribe to the idea of just doing what you need to do right now and consciously avoiding any other planning; if you're not poking your head up and keeping an eye on where the project is mostly likely to head, it's too easy to grind something into the very foundation of the architecture of a system that will make it essentially impossible to get to where you are actually going.
For example, if today, your system doesn't require any networking, then it may be advantageous to do everything as a fully local process with no networking involved, because networking is hard and expensive for your architecture. However, if you peer six months into the future and it's pretty obvious that you're going to have to add networking of some kind to your system, you can often cost-effectively hedge your bets without necessarily going to full-on networking usage by making sure that as you proceed in the initial steps, you tend away from any solutions that will make it impossible to add a networking layer in the future. Often you've got several options that are effectively the same price right now and have effectively the same benefits (never identical, but close enough), but have very different characteristics if you consider where the project is likely to go. You can often take out cheap insurance that pays off big later, and on those occasions where it may not pay off, it wasn't that expensive in the first place, so it's not that big a deal.
For a much more micro example, this is why every non-trivial file you write and every network protocol you specify should have a version number in it. It's virtually free today to put one in, even if you don't need it right now. (And for version 1, almost by definition you don't.) But the odds that you'll need it in the future, and that it'll be much harder to put in, are very good. Not putting a version number in today because you don't need it today is a great way to constrain your future moves.
(I actually still sort of endorse the radical YAGNI approach for young designers. Young designers who don't have a lot of experience tend to cargo cult the more complicated designs they see in other systems without deeply understanding what those are there for. I think there's a lot of advantage to taking a radically simplifying approach to your early designs, and you're likely to produce better work in almost every sense as a result if you do. But as you gain experience with that approach, bear in mind that it is something you will eventually outgrow. Armed with the direct experience of what problems arise and what solutions there are, and, alas, yes, the times you backed yourself into a corner, you'll grow the wisdom needed to peer ahead a bit and get the future course right often enough to make even better decisions. I'm not perfect at it, but I'm better at it than the hard-core XP propaganda seems to believe is possible.)
One of my big focuses when I'm designing a system is not to get everything right up front, but to always be looking two or three steps ahead and making sure there is a reasonable path to get to where we need to be.
This is very key! This goes back to the "driving the car vs. aiming a cannon" analogy from Extreme Programming. Instead of aiming a cannon and hitting the target in one shot, a driver steers moment to moment while thinking about the road ahead and the next turn. (As opposed to driving with no thinking about the next turn and the road ahead, which is just bad driving.)
Young designers who don't have a lot of experience tend to cargo cult the more complicated designs they see in other systems without deeply understanding what those are there for.
Also very key. One shouldn't just imitate the form, but understand the forces that determined the form!
Tracer code is "The Pragmatic Programmer" approach to applying Gall's Law:
Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary.
What I'm describing is also how one can incrementally get to the Tracer Code. First, write something stupid. Perhaps it's fragile and hardcoded and only sends one particular query and gets the answer back. Then correct the hardcoding and start filling in the missing pieces.
Makes me think of something I say occasionally... "The simplest thing that can possibly work is simpler than the simplest thing you can possibly imagine."
However, one can work at an even smaller granularity. "The simplest thing that could possibly work," can be made out of stupid things that won't work. To build the networking for an MMO, I cookbooked a websockets chat demo, then used it to pass updates from the server to the client. No login mechanism. No security. No dead reckoning. No fancy synchronization. All those things can be added later, however. It will be easier to add them to a running system. (Provided one also refactors to clean up code.)
If you're stuck at how to proceed, feel free to stub out features in a way which can't possibly work in production, but which will let you compile, run, and test your system. It's always easier for me to modify a running system than it is to big-bang an entire system from scratch.