I’m happy to announce that the Patterns and Practices group has made the release version of “Improving .NET Application Performance and Scalability” available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp
The team asked me to write an foreword for their guide and I include that here by way of introduction and recommendation. It was my pleasure to contribute to this work and I hope you will both enjoy and learn from it.
I’m giving up my official job title because it’s clear to me now that, despite the incidental bits of code that I write, what I actually do is better described by the words “Performance Preacher,” and I may as well embrace reality.
It’s not so bad really.
Now the thing about being a preacher is that you have to be able to regularly come up with simple yet clever rules to get the attention of your flock. And of course you don’t want to turn your flock into a mindless cult of zombies, even if it seems like that might be convenient on certain days. No, the truth is that a good preacher will be providing resources, guidance, a good example or two, and most important of all, a framework of values.
And here we come to the topic at hand. What are good values for performance work? Well, to start with you need to know a basic truth. Software is in many ways like other complex systems: There’s a tendency toward increasing entropy. It isn’t anyone’s fault; it’s just the statistical reality. There are just so many more messed-up states that the system could be in than there are good states that you’re bound to head for one of the messed-up ones. Making sure that doesn’t happen is what great engineering is all about.
Now, it’s time for the simple yet clever rule: Never give up your performance accidentally.
That sums it up for me, really. I have used other axioms in the past – rules such as making sure you measure, making sure you understand your application and how it interacts with your system, and making sure you’re giving your customers a “good deal.” Those are all still good notions, but it all comes down to this: Most factors will tend to inexorably erode your performance, and only the greatest vigilance will keep those forces under control.
If you fail to be diligent, you can expect all manner of accidents to reduce your system’s performance to mediocre at best, and more likely to something downright unusable. If you fail to use discipline, you can expect to spend hours or days tuning aspects of your system that don’t really need tuning, and you will finally conclude that all such efforts are “premature optimizations” and are indeed “the root of all evil.” You must avoid both of these extremes, and instead walk the straight and narrow between them.
I suppose, after all, that the final function of a preacher is to remind his flock that the straight and narrow path is not an easy one to walk. Performance work has never been easy. And so, I’m happy to tell you that in the coming pages you will find some of the best advice there is to be had on the subject – resources, guidance, examples, and a framework of values. And, after reading this guide, I hope you will want to work with us for what’s right for your customer – not only the most reliable and secure software that can be made, but also the most pleasant to use and reuse.
 Hoare, Tony. “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” Quoted in Donald E. Knuth, Literate Programming (Stanford, California: Center for the Study of Language and Information, 1992), 276.