Premature Optimization
I was once part of the planning team for a big wedding anniversary party. You know the kind im talking about - with hundreds of guests, so that it felt like a wedding reception.
There we are, working on all the details, when it comes to talking about waiters. Our team was very worried about how many waiters we would need - not for serving food, but for serving drinks. I was less worried.
The reason I was less worried about people getting their drinks was because we had a huge bar at the venue. Anyone who wanted a drink could easily head to this 200 ft wide bar and order a drink.
No, what worried me was something different. I was worried about the drinks themselves. It didn't appear that we were going to have enough soda or spirits.
This is Premature Optimization
If you take just a minute to think about the situation, you'll quickly realize this was a perfect example of premature optimization. You could have all the waiters in the world and it wouldn't solve the core problem (of not having enough drinks).
Thinking this is uniquely a software problem? It's not. It's a human problem. We regularly want control, and often choose the wrong place or time to take it.
In Mark 9 (verse 5) and in Matthew 17 (verse 4), we see how Peter reacts to seeing Jesus, Moses and Elijah on the mountain top. Matthew doesn't highlight the motivation but Mark mentions Peter was afraid.
Our insecurities and fears often push us towards premature optimization. Peter sees the three of them and wants to build shelters, presumably so others can come up and see them (maybe even sell tickets).
But the word from Heaven shuts it all down. And I wish, when we're building software in the faith space, that we would equally hear an actual voice from Heaven shutting down premature optimization.
What We Need to Worry About
If we shouldn't worry about premature optimization, what should we worry about?
It's a trick question. Don't worry.
But seriously, what should we be thinking about as we build things? I think we need to think about four things. Here they are.
- Worry about whether you should build something at all. If you put a bunch of software people together, the questions will be about "can," instead of, "should." Just because you can build something doesn't mean you should build it.
- Wonder if there is a market for what you think you should build. I can't tell you the number of times people show up with an idea that they don't see anywhere in the market and instead of asking why they don't see it, they presume no one has ever had the idea before. There may be a very good reason (and accompanying warning) for why something doesn't exist.
- Discover if you have the right features at the right price to make something compelling. There are few things harder than finding product-market fit. Optimizing your storage, query performance, CPU utilization or hosting is a waste of time if you can't find hundreds of people who want what you're offering at the price you're offering it at.
- Lastly, do you have a focused and defined buyer? If you tell me everyone needs what you're selling, you haven't done your homework. There's no way you'll be able to build a great product, much less market or sell your offering, without a deep understanding of your target market.
Notice I said nothing about scaling (either your processes or your architecture)? That's because, as attractive and fun that puzzle is, it's not the main thing. And our job is to always keep the main thing the main thing.