Okay, what is a Model? Many arguments (discussions) arise from misunderstandings in terminology. So, as an aside to the SoftwareCannotBeModeled discussion, here are some definitions of (or feelings about) Models:
From an interview with NoamChomsky by AlexanderCockburn? (Models, Nature, and Language -- Grand Street Issue 50)
Noam says:
-- ToddCoram
A model, at its simplest, is a vehicle which communicates fundamental principles from one mind to another. It is complete in and of itself, and no more. It contains all the flavor of a bite, or bites, but is not itself the meal. -- DonOlson
A common software model (should I write SoftwareCanSoBeModeled?) is the prototype. In particular, the "human factors prototype" has the purpose of communicating between people what the system will look like.
Merging the ideas of human factors prototyping, and incremental development, we get VisualProgrammingSystems.
-- RonJeffries
A Model presupposes a Question, something to Examine. Having the Question explains why you left out the bits you left out, kept the things you kept, what you intend to do with it. When DonOlson says, "model, at its simplest, is a vehicle which communicates 'fundamental' principles from one mind to another", he leaves out who considers what to be fundamental, and what the two minds are interested in. Another statement, written around here somewhere, is that a model instruments something. Again, ... to examine some question. Without the notion of a Question or set of them, all the discussion of a model goes around and around. To me that answers the question of SoftwareCannotBeModeled ... of course it can, and look like so-or-so depending on what questions you want to examine. I provide some questions I want to examine over there (if I can get its editor to let me type on it.)
Stepping onto soapbox
Noam's definition is a reasonable summary of the cyber-centric (see, I got that trite prefix in today <g>) view of the definition. Here is what The Random House Dictionary of the English Language (Unabridged) offers:
So my point is that we have at least two imperatives at play here, both employing the same term. In the definition #1 sense, we often attempt to use our systems to create a standard or example for imitation or comparison of client data, business practices, or algorithms. In the definition #10 sense, we also often attempt to use our systems to create a simplified representation of a [client] system or phenomenom for analysis.
Perhaps we can find a pattern to resolve these two forces? In the meantime, perhaps we can agree to use the term two different ways, or else qualify it (DataModel or AnalyticModel).
Stepping down, to a smattering of polite applause, realizing that he has spent entirely too much time on chatservers
-- TomStambaugh
Well, let's see if this thing will jumpstart, after sitting idle in the garage for four years.
The term 'model' comes from the Latin modus, meaning measure, and the 'l' at the end comes from the diminutive suffix "elle" or "ello" (depending on which Romance language you trace it through). So, a model is none other than a small measure. The reader will be quick to note that small measures mean little until applied to something. "A small measure of what?"
Etymology, as usual, provides precious little specialization, leaving modern meaning to evolve in a bunch of different directions, as has happened to this little word. However, all modern meanings still derive from this basic concept of a small measure. BigModelsAreUseless, indeed. They're not even models!
Since modeling* means going from relatively big to relatively small, there is an inherent data compression problem in all modeling: "what to leave behind?". Modeling is a "lossy" undertaking, and that's why "all models are wrong". There are as many ways of modeling a thing as there are ways of taking some but not all of it.
Be that as it may, there are families of models, perhaps even ModelingPatterns?**, that are characterized by the granularity and distributions of parts taken and parts left behind. For example, I can randomly sample the entire loaf of bread, taking seventeen crumb-sized granules, or I can lop off just a corner, or I can skin the loaf, taking the soft innards and leaving the tough crust behind. As Alistaire says above, the right model depends on what you're trying to do.
Modeling and analysis must be second cousins once removed, and their relation is clearer if you also take the more archaic meaning of analysis (to break apart), as I am lobbying on this Wiki for software developers to do. In the first place, it's impossible to make a model of something without dividing it, that is, analyzing it. In the second place, we choose analytic models for their properties of revealing even more of the structure of the original thing than was evident in the initial direct observation of that thing.
Hmmm. Isn't this a generative process? The first "break" is often crude, and only a little bit revealing. The next "break" goes deeper, and so on... Analysis for analysis' sake? Maybe, maybe not.
- - - - -
(*) Don't be afraid to spell modeling: "modelling", since the double-l harkens right back to that highly significant diminutive suffix (see above).
(**) But where can I find them?