Middle-out

When creating something, it often seems like you start from a particular point and fill the rest in around it. For example, you start with an amazing character idea and build a plot around that character, or alternatively you start with a great plot idea and find characters that can drive it. Or, if you're Asimov, you just write your ideas down and hope for the best.

In software businesses there are similar starting points. You can start with a particular product and figure out the engineering necessary to build it - that's most modern web startups. You can start with an engineering breakthrough or scientific discovery and figure out how to turn it into a product – that's basically the rest of the startups. Even in the software itself, you often have to choose which components to start with, which database or web framework or game engine, and that decision then shapes all the subsequent decisions you can make.

And I think that really misses something. Because when you commit hard to an early decision it means there are significant limitations to how you can make all the other decisions. You can often feel this in a codebase, a kind of impedance mismatch where you can see lots of translation layers between different modules because they're designed in different ways that don't line up well. Or you avoid that by only using modules that fit nicely with the existing ones, even if that means they don't work well in other ways.

I once read that Jony Ive's philosophy on design is different because he spends so much time thinking about materials and how they can complement or inform product design. The particular choice of metal or plastic, or what kind of manufacturing process to use, doesn't come right at the end, as it does with many other companies, but is part of the process the whole way through. Instead of saying "we want a laptop this size, therefore we'll make it out of metal", or "we want something made out of metal, how about a laptop?", it's more like "we like laptops, we like metal, I wonder if those can go together".

Ultimately I think this kind of philosophy is best. Obviously there's nothing stopping you from picking one most important starting point and fitting everything around that, but I believe that really amazing feats of design and engineering only happen as a kind of simultaneous equation. You consider all of the possible options for all of the aspects of the thing you're making, and among those you find a set that fits together so beautifully that the resulting product just falls out naturally.

Of course, that's much easier said than done. All of the options for all of the aspects is a fearsome combinatorial explosion to deal with. In practice, you probably have to pick your battles on that front, and be sensitive to the limitations of your poor fleshy brain and the time available to the project. However, I think that in many cases picking one place to start is a very early optimisation, and an unnecessary one. Taking the time to think about the right set of primitives can give you something much better than you could have designed incrementally.