Joshua Allen nails a key distinction:

"[...]Which gets to my personal bias.  I believe that all of these "distributed computing" paradigms all come down to a model where code is central.  I believe that there are a huge number of business problems which are more suited to a data-central view.  People will argue that code and data are complimentary, and it can even be argued that code is data, but I am talking about a fundamental architectural bias here.  Do you view your system as being one big chunk of RAM, or one big CPU?  I think it's typical for developers to think from a code-centered perspective first, and it takes a certain amount of experience with the boring, bread-and-butter business apps before a developer realizes that the data is the only really important part of the application." [via Better living Through Software]

This is so terribly important to internalize. As developers we really do try to apply the DRY principle and to leverage frameworks and runtimes. Part of this well-intentioned push results in "standardization" on a given framework, runtime, or class library (and, usually, on more than one).

So Java developers decide if they are in the fat or thin client world, then dive whole-hog into building Struts or JSTL or EJB-based systems. But without care, our new framework becomes a golden hammer. The design stage for every application soon involves a discussion something like "how can we fit this design into an EJB container?" rather than thinking about the best tool for the job at hand. Maybe we don't need a distributed, transaction-aware runtime to update a single row in a database. Blasphemy!

The ultimate golden hammer for software developers is, of course, software itself. Rarely do I see a problem that doesn't seem as if it might yield to the careful application of some custom-written code. Sometimes, however, all the client really needs is a spreadsheet, or a few simple screens in FileMaker. Maybe they just need a good report on existing data or enough documentation to bridge the difference between the physical model of the database and their own mental model of the data. How many times have I seen a thousand lines of code deployed into an application server that could be replaced with a few lines in Perl or sed? More than once.

Sometimes I'm so focused on writing the system to get data into a database that I forget the whole point is analysis of that data, which, of course, means getting the data out. While it may fly in academia, I can't tell my clients that I'm leaving the actual analysis of the data as an exercise for the reader.