A collegue reminded me of one of my favorite “architecture” sayings yesterday, which I had on my door for a couple of years:
All models are wrong. Some models are useful
The point is that we don’t create a model to be an exact replica of reality. We create a model because it is quick and easy and guides us towards reality.
That goes as much for models that are diagrams, models that are proofs of concept, and models that are communities. That’s right: communities.
I am part of three communities at work that I value. A group of SOA experts from around the company, a group of SOA experts in Microsoft IT, and the general Architects community in Microsoft IT. All three give me things that I could not get on my own: a chance to learn, an opportunity to share, an place to discuss things that I find important, and last but not least, a place to build influence towards solving problems that slow us down.
But a community is a model. It does not contain every person that SHOULD be there, and certainly not every person who COULD be there, and probably a person or two who should NOT be there. It is a facsimilie of the real constituency that it represents: a non-scientific subset self selected by passion, support from management, and incentive.
So by extension,
All communities are wrong. Some communities are useful.
It is up to the members of a community to make it useful.
I commit to this: I’ll do my best.
3 thoughts on “All models are wrong, some models are useful”
I’m pretty sure that saying originates in economics. Regardless, it accentuates the reality of our increasing digital world that most "things" we now create are drastic approximations of reality and scepticism/critical thinking are a necessity.
" All generalizations are false, including this one." – Mark Twain
BTW, "models" quote you used in the beginning is just my mantra for life.
I’m not sure if I agree that all models are wrong. A model is an abstraction in the sense that it doesn’t have all the details, but it doesn’t necessary make it wrong.
We abstract away irrelevant details on purpose – to manage complexity of the problem we are trying to solve. Whatever is true about the abstraction must be also true about any instance it represents.
Of course there is a danger of abstracting relevant to the problem details – in this case the model won’t represent the real problem, and as a result solution based on that model will be wrong.