I’m sure most developers have heard (and possibly used) the phrase “premature optimisation is the root of all evil” at some point to justify not making a code change because we don’t know how it will affect performance. Unfortunately, I’ve also seen developers and architects try and use it as a “Get out of jail free” card.
The important word here is premature not optimisation. Performance is not something that can be tacked on at the end, you have to think about it up front, as part of the architecture. I have heard many voices arguing that we don’t need to worry about performance because we can profile and optimise later. That’s true to a point, but when you know, in advance, that 2 machines are going to be pumping lots of data to each other, you find a way to put those machines in the same rack, or run both services on the same machine. When you know your object graph contains thousands of multi-megabyte images that you don’t need 99% of the time you access those objects, you design your data structures so that you only load them on demand. Putting indexes on a primary key isn’t premature. Designing for scalability by reducing shared state isn’t premature. Those are not premature optimisations. You know that your decisions up front can avoid a bottleneck.
It’s only premature until you measure it. You should have an idea how much data you’re transferring. If you find out with 1 week to go live that your program is sending ½Gb of XML data on every request, then you probably weren’t paying attention, and you need to look at your test environment to figure out why you didn’t spot it before.
You might tell me that you don’t need to worry about performance. Maybe 10 years ago, but Moore’s law is dead. You can no longer joust and wait 18 months for your code to get faster. Multi-core is not magic, and it won’t make procedural code any faster, just look at Amdahl’s Law. Web servers are optimised for throughput, desktops are optimised for user responsiveness, and mobile devices are optimised for battery life, not programmer bloat.
Slow code is code rot. If you can measure your technical debt in minutes, it’s time to pay it down. Of course, we still want agile development with maintainable code, and premature optimisation can still create technical debt, but don’t ignore performance, and make sure you know how to measure it, even if it’s just turning on the performance monitor on your CI build so you know if it’s getting slower.
Clean code, but fast clean code.