One of the sense-making techniques I have used over the years is to take two words which are commonly used as synonyms in common day speech and make them into antonyms. That is to say, I take two words which are used interchangeably, and establish a difference between them. Now english as a language allows you to create an opposite by the addition of a prefix, and we do this with unorder, in order to contrast it with order. The ones I currently use I list below with some short hand explanations; it includes some antonyms that could never be taken as synonyms by the way. I hope you find them useful, additions welcome.
ORDER :: UNORDERFor those interested this supplements my earlier blog on aspects of complex systems.efficiency :: effectiveness
Efficiency is about stripping away superfluous functionality so that you only have what you really need left. This is great if the context does not shift and has dominated re-engineering and six-stigma approaches. Effectiveness involves introducing a requisite degree of inefficiency so that the system as a whole can be more resilient and adaptive. Focusing on effectiveness is appropriate where the context is, or may shift before you can re-engineer your systemstability :: resilience
In nature, and for humans any system which is stable is not resilient and vice-versa. If a stable system is disrupted it may never recover, while a resilient system has more recovery capability but may cost more/appear to be less controlled.exploitation :: exploration
Structures with little variety and low levels of dissent and good at exploting what they know, but poor at discovering new things. If the level of dissent goes up and variety increases then the structures increase their exploratory capability, but at the cost of being able to exploit it.rules :: heuristics
Rules prescribe actions and their compliance with them can be objectively measured. Heuristics in contrast have a degree of ambiguity and can adapt more readily to a shifting or changing contexts. Heuristics are more commonly known as rules of thumb, and can cover a much broader field such as knowledge management in a few phrases, whereas rules would take a book. Rules can also be contrasted with habits, and with ritual.regulation :: habits
Regulations (rather like rules) constrain a space. habits (and rituals in some aspects) create a pattern of behaviour. In Cognitive Edge we use ritual and habits as an alternative to regulations in issues such as health and safety and crisis response management. Its easy to forget a regulation or ignore it but habits become instinctive.dilemma :: paradox
A dilemma represents a choice between two incompatible alternatives, the most harrowing example I know is in the film Sophie’s Choice and to be honest, although it is brilliant I don’t think I can watch it again. Dilemmas are used in some types of systems theory to force diversity. Paradox on the other hand presents a contradiction which is not a choice, but which forces you to think about the problem in a different way. For example, in KM: If you tell someone they must share their knowledge they will hide it, if you tell them they can keep in private they will share it. Another example comes from narrative: if you ask people to tell the truth they will lie, if you tell them they can lie they will tell the truth.
Comments (1)
With my experience in software development I thought I might add package -- Bespoke. Of course, this isn't general enough given the broad scope of your own antonyms - so maybe "reuse" -- "build from scratch" which can cover much more than software or IT systems.
Now in my experience many organisations go for package software because it is cheaper. For many applications this probably makes sense - who wants to write another payroll package from scratch or a nominal ledger system. But in other cases the business situation is very unique or special. The package providers come in with the "thats what they all say but businesses aren't that different" or with the "we can modify the package to fit your business" quoting the 80/20 rule.
An interesting consequence for an organisation undertaking a specialised application is that in commiting to a package solution, with a fixed purchase price but a somewhat vague specification on the modifications, is that the total cost can be considerably more than a bespoke application which frequently suffers reduced or forced functionality.
Now you can link this opposites with your previous request "Experiments: Help Needed" blog.
I am not sure on exact games from this, but it would involve the difference between starting fresh with a problem where participants had to construct something within a known situation out of known components or a ready solution that has to be unpacked and repackaged to achieve the same result. In reality, only part of the problem is the addition of remaining functionality (although I could quote many cases where this is extremely difficult or badly done). By far the most difficult is the undoing of the massive amount of additional funcationality embedded in the product but not made aware to the client company. It may be true that it needs a 20% addon, but what they don't say is that its a 250% fit and 170% has to be taken off before the additional 20% can be added back. So a game option would need to include a reasonable amount of undoing or taking away before it could make sense to add back to achieve the same result.
In practice one wouldn't want to make definite conclusions about which is the best way (its just that I'm involved in bespoke software so I want to spin the story my way) but experimenting with different mixes to help understand the implications of working with existing solutions verses constructing new ones from scratch would be interesting.
Posted by Peter Stanbridge | October 3, 2006 3:14 PM
Posted on October 3, 2006 15:14