Rules are rules… until performance says otherwise.
Most of the time, the real problem in software isn’t speed — it’s change.
That’s why I believe maintainability matters far more than performance optimization.
Generally, writing maintainable code means writing code that’s less performance-optimized. And that’s fine.
Generally, when we have to choose between the two we should choose maintainability. It keeps our systems alive in the long run.
But every so often, performance IS the problem. And in those rare cases, we should break whatever rules we need to get the job done.
Take immutable lists. They’re great for reasoning about code. But every time we insert in the middle, the whole list has to be rebuilt. In many domains, that overhead is fine. In others, it’s a deal-breaker. That’s when we open the escape hatch and choose a more performant tool.
Another example: denormalization in relational databases.
The fact that we sometimes have to denormalize doesn’t make normalization useless. The default should still be to normalize. Even at the cost of performance. But only until performance becomes the higher priority.
We don’t follow principles for their own sake.
We follow them until either performance, or pragmatism, forces us to trade them away.
But let’s talk about pragmatism tomorrow.
Now, have a look at the image. The ideal level of performance is where the two lines meet. But since computers are so fast these days, I’d argue the customer dissatisfaction line drops much faster than drawn. Which moves the ideal point further to the left. Which is why I say we should default to maintainability.
My book, The Object Oriented Way, is about writing changeable software and knowing when to follow principles, and when to break them. Link in the comments.
Christopher Okhravi
Rules are rules… until performance says otherwise.
Most of the time, the real problem in software isn’t speed — it’s change.
That’s why I believe maintainability matters far more than performance optimization.
Generally, writing maintainable code means writing code that’s less performance-optimized. And that’s fine.
Generally, when we have to choose between the two we should choose maintainability. It keeps our systems alive in the long run.
But every so often, performance IS the problem.
And in those rare cases, we should break whatever rules we need to get the job done.
Take immutable lists. They’re great for reasoning about code.
But every time we insert in the middle, the whole list has to be rebuilt.
In many domains, that overhead is fine. In others, it’s a deal-breaker.
That’s when we open the escape hatch and choose a more performant tool.
Another example: denormalization in relational databases.
The fact that we sometimes have to denormalize doesn’t make normalization useless.
The default should still be to normalize. Even at the cost of performance. But only until performance becomes the higher priority.
We don’t follow principles for their own sake.
We follow them until either performance, or pragmatism, forces us to trade them away.
But let’s talk about pragmatism tomorrow.
Now, have a look at the image.
The ideal level of performance is where the two lines meet. But since computers are so fast these days, I’d argue the customer dissatisfaction line drops much faster than drawn. Which moves the ideal point further to the left. Which is why I say we should default to maintainability.
My book, The Object Oriented Way, is about writing changeable software and knowing when to follow principles, and when to break them.
Link in the comments.
2 months ago | [YT] | 46