The broken development process and "The Golden Rule"

In many of the performance issues I help resolve there is strong resistance from developers and architects, in some ways a disbelief that their application could be anything other than perfect and performant.

Digging a little deeper, identical patterns of development appear. Put bluntly there is no attention paid to operational price/performance, huge assumptions are made and in many cases there is blind hope coupled with a certain arrogance.

"But it works fine on my PC" is a common chant, this little example of failed logic is indicative of the broken Java development process. Naturally it worked fine on a powerful development machine at 1'ish transactions per second, with no concurrency and trivial data volumes, it was bound to as developers unconsciously adapt to make it so. However this has no relation to production platforms, transactions rates and data volumes.

The golden rule is to consider "non-functional" performance requirements from the very beginning, in the design phase, and to carry these through development with constant measurement and refinement. Involving management, reporting on price/performance on an daily basis as the application takes shape, making technology and architecture choices visible and deciding on their value using empirical data as well as subjective "attractiveness".

It's not all about developer productivity (which is never measured BTW).

This "feedback loop" is in fact identical in nature to the unconscious tuning that happens in a developers personal "space", their development workstation, but broadened to encompass real volumetrics and real deployment platforms.

I plan to go into much more detail about this, but for 2007, remember this Golden Rule, take responsibility for performance, set goals and constantly measure.

We are approaching a time where throwing hardware at an issue will increasingly run out of steam, planning for operational performance helps delivery times and reduces costs for very little investment.