Design Naïvely

A very complex intersection seen from a high vantage point

What exactly does it mean to avoid premature optimization when writing software?

When building a new town from scratch, don't plan for hi-rise buildings, complex freeway interchanges and underground mass transit lines. Start with the buildings and roads and parking lots that will attract people to your new town.

Which is worse?

Build just enough of your application to say you have the feature.

Do it the easy way.

Don't care that it won't work if you achieve Facebook-activity-level scale. That level of activity almost never shows up overnight.

Odds are good that you'll never need to.

And that's a good thing.

It freed you up to spend more time building more new ideas (naïvely). The more you build, the more likely one of those ideas is to find success.

So put it in the monolith. Use algorithms that are easy to implement. Avoid complex workflows like message queues and service busses.

Watch activity logs. Measure performance. When, and only when it's being stressed near to its breaking point so you have to closely monitor the feature during heavy usage periods to make sure it doesn't explode and ruin your day, and/or when those processes become critical-path to the success of your business, should you invest time and money to add complexity and support increased demand.


It's like comments, but you do it on Twitter.

1 Like


1 Retweet


2 Replies

Carwyn Carwyn
"What exactly does it mean to avoid premature optimization when writing software?"…
Add your comment: Tweet about this article.

Webmentions via

Discuss on TwitterEdit on GitHubContributions