Engineering is a quantitative discipline

A few days ago I saw request for performance related information on one of our internal discussion lists that I thought was a bit vague and so I decided it was a good time to introduce my latest performance meme.  Here's my response slightly edited and improved for yous guys :)

Engineering is a quantitative discipline. 

I recommend you do some trials/models to see what the costs are of the various solutions then see if you can't quantify the benefits in terms of value to your customer.  You should be able to get an idea what your costs/benefits will be without doing all the work.
 
If you haven't done any measurements you'll just be guessing, not engineering. 
 
Appealing to the world for subjective advice really puts you in an even worse situation because we can't possibly characterize the value of these features to your customers and we are in an equally bad position to characterize the costs, leaving us to make wild guesses which you should find valueless.

On the other hand, if you can tell the world that certain metrics are very important to your customers you can then ask us questions like "What are good ways to measure this metric?”,  “What systems perform well or poorly in this dimension?”,  “Are there any best practices related to reducing my metric?", and you can get much higher quality advice.

Comments

• Anonymous
  June 16, 2004
  That is some of the BEST truth I have heard in a long time. Rico, again, you amaze me. Maybe, just maybe, one of these days I'll be able to impress you with something just as insightful.
• Anonymous
  July 04, 2004
  there's underlying truths that matter as well...
  Whoever the customer is (internal v external, yourself or a paying customer, etc), they are paying for it(1), so measure in terms of what they need / want.
  
  (1) Even when coding "for yourself", you should compare the payoff - the time you spent (which you'll never get back) versus the payoff - personal productivity, corporate glory, learning a new skill etc