Dean Kent (dkent@realworldtech.com) on 1/31/09 wrote:
---------------------------
>As a writer of commercial software, this is one of the most common problems I see
>in any long-lived product. It seems that the average person (meaning, average developer/programmer)
>has trouble keeping in mind all of the various pieces of a design that will need
>to scale as the number of resources used or tracked increases.

As much as I hate software that doesn't scale, I probably hate premature optimization more. I'm going to speak in generalities here, but my guess is that most programmers who've been around the block a few times have experienced over-engineering or excessively "enterprisey" software.

Software that scales well is not always easy to write. Sure, there is low hanging fruit that you should look out for; and as experienced programmers, it's our job to catch as many of those as we can.

But does every bit of data need to be a database? Does every database need to be transactional? Does every program need to be multithreaded? Must we assume that UDP packets will frequently arrive out-of-order?? :) The answer is sometimes a resounding *no.* Sufficiently small programs can be made arguably, provably perfect; I have yet to see any truely perfect software I use every day. Needs change, times change, hardware changes, use cases change. And sometimes it's better to code for what you have now -- keeping in mind that you may have to go back and do it over later.

Lack of foresight is a beginner's curse. Premature optimization is the next stage. The truly enlightened programmer knows how to strike a balance. ;-)