Performance is a subject that seems straight forward, but can get controversial easily. After all, we all want our software to be fast, right?. But there is a catch, performance comes often at a high price: code that is difficult to understand, change or extend.

I remember, many years ago, writing code with a friend. The routine in question was rendering a graphic to the screen, basically copying a piece of data from the RAM to the video card's memory. This was being done in assembly, because every cpu tick was to be optimized. To make a long story short, we even ended up 'unrolling loops'. This means to change something like this:

for f = 1 to 3 {
do something;
}

to

do something;
do something;
do something;

It would use more memory, but it would be faster than the loop. Now, imagine if the loop was longer that three... and if you start reading this code. It'd be more difficult to understand, for sure. Even if you knew the 'unrolling loops' technique, the extra lines of repeated code makes the file difficult to read. Not to mention if you need to change 'do something'... get ready to copy and paste!.

Performance tuning, at the algorithm level, comes with a high cost. In enterprise development, I have rarely seen this cost justified. Make no mistake, this might be perfectly suitable for real-time application, games or 3D engines, but enterprise development is not so much CPU intensive, but rather data intensive.

Enterprise software needs to be flexible, adaptable to changing business rules. For this, object oriented (OO) design a patterns are key. But again, going for a OO architecture means sacrificing some performance. This would not be a problem at all if the ego of many developers would not be affected. But it is. It seems like some programmers measure their knowledge by knowing how to write the fastest code. It doesn't matter if no-one can understand that code later, let alone change it (actually, that could be consider a good thing). So they resist OO design and good coding practices, and go around shifting bits to the right and reusing variables.

With enterprise software, the key is not so much performance, but scalability. The software has to be fast enough to do what it is supposed to in a reasonable amount of time. But that time has to be pretty stable as more an more people use the system concurrently, or more and more data is added to the system. For a billing system, it is not so important to display an invoice in 1 second or 0.75 seconds. But what if 1000 people want to see their invoices at the same time?. What if that invoice is one of several millions invoices that the system is handling? Then we might have a performance issue, because searching for that invoice can not take 10 seconds, that is too much.

What we have then is not a performance problem related to an algorithm in the billing system, but rather a problem of data tuning. How the data is organized and accessed is very much at the hart of the performance of an enterprise application. In the example, if the invoice is not accessed through a good index, or the RDBMS is not capable of handling the volume of data, then we'll hit a performance wall.

It is not my intention to dismiss performance as an issue that has to be deal with in enterprise applications. Rather, I want to point out that it is all to common the reason for poor coding and design decisions. Performance has to be dealt with from the beginning, with a sound architecture and design focusing mostly on how the data will be accessed.

To wrap up, just in case you haven't seen this quotes before (and as a refresher if you have), here they go:

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason- including blind stupidity.
William A. Wulf

We follow two rules in the matter of optimization:
1 – Don't do it
2 – (for experts only) Don't do it yet- that is, not unitl you have a perfectly clear an unoptmized solution.
M.A. Jackson

Item 37: Optimize Judiciously
Strive to write good programs rather that fast ones.
Joshua Bloch