I like this illustration a lot. It is a very good reminder that principles are nothing more or less than a path towards a bigger goal.
2 months ago
| 0
maintainability and performance aren't are tradeoff. Your code can be slow and hard to maintain, but it can also be very performant and easy to maintain. So the premise is already wrong. You should know how memory and the CPU works, then you should write simple code that takes the physical reality into account (instead of abstracting away from it). Abstracting from reality can cost you multiple orders of magnitude of performance, without giving you any maintainability in return.
2 months ago
| 1
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