Writing

Feed Software, technology, sysadmin war stories, and more.

Tuesday, December 27, 2011

Zero, one, infinity needs more respect

There's this rule of thumb in software called zero one infinity which is meant to help designers avoid bad situations. You either allow none of something, exactly one of something or an unlimited number of things. I don't think it gets enough respect. Here's why.

Let's say you write something which allows for exactly one node. It sits there and handles all of the load. Great. You now have a self-contained system. Now let's say you want to split it up and allow for a second node. This is when you find out there's a huge gap between allowing one and allowing more than one.

This scares some people. They don't want to do that kind of investment up front, even if they can clearly see a need for it within a year or so. It's far easier to just throw something together quickly which doesn't have to worry about coordination and correctness in a parallel world.

Let's say you do that and it gets your minimum viable product going so you can get to market quickly. That's great! But you have to eventually pay the the price to make it scale. You can either do it while your system is still relatively small and isn't running at capacity, or you can wait until it's too late and then do it with a gun figuratively pointed at your head.

Which would you rather have? You can scale up a system while the existing one is keeping up with the load, or you can do it while the existing system is falling down and is failing every day. You have to come up with something new and do it while under heavy load and tons of stress. Is that really such a good idea?

The funny part about all of this is that the gap between 1 node and 2 nodes will probably be far bigger than the gap between 2 and 3. It will also probably stay relatively small through 4, 5, 6, and so on until you get to some new hurdle. Then you get to reconsider things all over again.