Any time you make a decision, you’re optimizing for something.
When deciding between watching the new James Bond film or a romantic comedy, you optimize for adrenaline or warm fuzzies. Or maybe you optimize for personal pleasure, or that of your partner. Or one of countless other factors that might figure into the decision.
Often these optimizations go unnoticed, even as we’re making the decision. But they’re there. Sometimes disguised as “I’m in the mood for …” or “I like …”
The same is true when we write code and design systems.
The notion that we write code, then later optimize it, is missing part of the picture. The famous Donald Knuth quote “premature optimization is the root of all evil” was specifically talking about inappropriate optimization.
So what optimization is appropriate, and what’s not?
To answer this question, I like to look at the system I’m designing as a whole. That is, not just a function or class, but the entire system. That includes the software, the infrastructure (servers or VMs), the programmers, operations engineers, customer service staff, and even customers. What does each one of these cost, in terms of maintenence, as well as opportunity cost?
With this entire system in mind, it may not come as a surprise that most businesses should optimize for customer experience. This includes getting bug fixes and new features out the door as quickly as possible. Without happy and loyal customers, not much else matters in the world of business.
Occasionally there will be some performance-related issue that surface to the level of customer experience. If it takes 30 seconds to display the details of a purchase, it’s time to spend some time optimizing that database query. But most of the time, from a customer experience standpoint, the “code quality” means every little.
Somewhere down the list of expensive subsystems we find “engineers”. Software developers and operations engineers are expensive. For most businesses, they are many mangitudes more expensive than the servers running the software. So how should this color our optimization choices?
As one example: Optimize for the engineer’s time, not for CPU time. This means that it is usually better to write code that’s easier to read, even if it’s slower to execute. It means use languages and tools that your engineers are comfortable with (PHP? Python? Heroku?), even if they may not be as performant or powerful as something else (C++? Assembly? Kubernetes?)
If you find that some piece of code, some tool, or some specific technology is causing performance problems that have a meaningful impact, that is the time to optimize.
And as a bonus, in most businesses, scaling problems grow along with revenue. This means that by the time you care about performance, you’ll be in a better position to afford to optimize for performance anyway.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)