The first rule is to avoid premature optimization at all costs. I have literally been at companies that I've seen destroyed by premature optimizations. I can't name names, but just know that doing premature optimization can massively destroy your design and create such a complicated system that when you actually come to your performance and profiling phase, you don't know where to start. The most important thing is to build the right system. Don't take short cuts based on what you believe will affect its performance; build a system that is maintainable, that satisfies getting your functionality out the door, that satisfies getting your system built quickly, whatever your important things are, but don't do premature optimization.Grabbed this from a coder's blog. A sentiment that I find echoed in so many places. I can think of many situations where people have indulged themselves in premature optimization. I'm using the word indulged because performance optimization is a very interesting intellectual activity and programmers typically love to say that they're working on optimization. But I am very skeptical of all the imaginary use-cases and performance optimizations that people are forever carrying on before even implementing features and products.
This doesn't mean that we should purposely implement our applications in a shoddy way - we must follow best practices of whatever platform we are working in, we must create a design and architecture that makes sense - but what we shouldn't do is to bend over backwards to optimize something that barely even exists.
I want to round this off with an unrelated but nice quote about Test Driven Development that I found yesterday. It is from a book by Kent Beck; he says - Tests are a Programmer's Stone, transmuting fear into boredom. I hope I remember this the next time I am feeling bored writing tests.
