Matt Sayler (sayler@thewalrus.org) on 2/3/09 wrote:
---------------------------
>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. ;-)


In many cases, just good software engineering practices, and keeping good interfaces between components and whatnot is where the initial focus needs to be. If the data storage subsystem turns out to need a real database, so long as it has a clean interface to the rest of the system, swapping that in can be reasonably straight-forward.

I've always been of the opinion that encapsulation and modularity are the most significant things a OO language supports - primarily for the reasons that it encourages clean (and limited) interfaces. Which is not to say that people don’t make a complete hash of that on a regular basis...