I am experimenting with a framework to summarize how I observe things that are going on around me, analyzing situations and coming up with solution approaches. Currently this is what I have:<\/p>\n
{Desires} \u00d7 {Problems} \u00d7 {Mechanisms} \u00d7 {Devices}<\/p><\/blockquote>\n
Everything I see can be analyzed as a result of the cross-product (a fancy word for combinations of contents) between these 4 broad categories. To make it easier to remember, they can be factored into 2 major categories:<\/p>\n
{Questions}\u00a0\u00d7 {Answers}<\/p><\/blockquote>\n
Where obviously<\/p>\n
\n
- [Questions]\u00a0Desires (objectives) lead to problems (practicalities) to solve<\/span><\/li>\n
- [Answers]\u00a0Mechanisms (abstract concepts) hosted by a device (implementation) to address questions<\/li>\n<\/ul>\n
Why the cross product? By tabulating everything I learned or know in 4 columns (categories), I can always select a few of them (subset) and notice a lot of recurring themes (questions) and common solution approaches (answers). This corresponds to an old saying “there’s nothing new under the sun”.<\/span><\/p>\n
Then what about innovations? Are we constantly creating something new? Yes, we still are, but if you look closely, there are very few ideas that are fundamentally new that cannot be synthesized by combining the old ones (sometimes recursively).<\/p>\n
Let me use the framework itself as an example on how to apply this framework (yes, it’s recursive):<\/p>\n
\n
- Desires<\/em>: predict and understand many phenomenon<\/li>\n
- Problems<\/em>: mental capacity is limited<\/li>\n
- Mechanisms<\/em>: this framework (breaking observations into 4 categories)<\/li>\n
- Devices<\/em>: tabulation (cross-products, order reduction)<\/li>\n<\/ul>\n
Feedback as an example:<\/p>\n
\n
- Desires<\/em>: have good outcomes (or meet set objectives)<\/li>\n
- Problems<\/em>: not there yet<\/li>\n
- Mechanism<\/em>: take advantage of past data for future outputs (through correction)<\/li>\n
- Devices<\/em>: feedback path (e.g. regulator or control systems.)<\/li>\n<\/ul>\n
Feedforward as an example that shares a lot of properties as feedback:<\/p>\n
\n
- Desires<\/em>: have good outcomes (or meet set objectives)<\/li>\n
- Problems<\/em>: not there yet<\/li>\n
- Mechanism<\/em>: take advantage of past data for future outputs (through prediction)<\/li>\n
- Devices<\/em>: predictor (e.g. algorithm or formula)<\/li>\n<\/ul>\n
Abstraction as an example:<\/p>\n
\n
- Desires<\/em>: understand complexities (e.g. large code base)<\/li>\n
- Problems<\/em>: limited mental capacity (programmers are humans after all)<\/li>\n
- Mechanism<\/em>: abstraction (generic view grouping similar ideas together)<\/li>\n
- Devices<\/em>: black-boxes (e.g. functions, classes)<\/li>\n<\/ul>\n
Trade as an example:<\/p>\n
\n
- Desires<\/em>: improves utility (utility = happiness in economics lingo)<\/li>\n
- Problems<\/em>: one cannot do everything on its own (limited capacity)<\/li>\n
- Mechanism<\/em>: exchange competitive advantages<\/li>\n
- Devices<\/em>: market (goods and services)<\/li>\n<\/ul>\n
Business as an example:<\/p>\n
\n
- Desires<\/em>: improves utility (through trade)<\/li>\n
- Problems<\/em>: need to offer something for trade<\/li>\n
- Mechanism<\/em>: create value<\/li>\n
- Devices<\/em>: operations<\/li>\n<\/ul>\n
Money (and Markets) as two examples:<\/p>\n
\n
- Desires<\/em>: facilitate trade<\/li>\n
- Problems<\/em>: difficult valuation and transfer through barter, decentralized<\/li>\n
- Mechanism<\/em>: a common medium<\/li>\n
- Devices<\/em>: money (currencies), markets (platform for trade)<\/li>\n<\/ul>\n
Law as an example:<\/p>\n
\n
- Desires<\/em>: make the pie bigger by working cooperatively<\/li>\n
- Problems<\/em>: every individual tries to maximize their own interest but mentally too limited to consider working together to grow the pie (pareto efficient solutions)<\/li>\n
- Mechanism<\/em>: set rules and boundaries (I personally think it’s a sloppy patch fix that is way overused and way abused) and get everybody to buy it<\/li>\n
- Devices<\/em>: law and enforcement<\/li>\n<\/ul>\n
Religion as an example<\/p>\n
\n
- Desires<\/em>: coexist peacefully<\/li>\n
- Problems<\/em>: irreconcilable differences<\/li>\n
- Mechanism<\/em>: blind unverified trust (faith)<\/li>\n
- Devices<\/em>: Deities and religion<\/li>\n<\/ul>\n
Just with the examples above, many desires<\/em> can be consolidated along the lines of making ourselves better off, and many problems<\/em> can be consolidated along the lines of we’re too stupid. Of course it’s not everything, but it shows the power of tabulating into 4 categories and consolidating the parts into few unique themes.<\/p>\n
I chose to abstract the framework into 4 broad categories instead of 2 because two are too simplified to be useful: since the framework is a way to organize (compactify) observations into manageable number of unique items, there will be too many distinct entries if I have only two categories. Nonetheless,\u00a0I would refrain from having more than 7 categories because most humans cannot reason effectively with that many levels of nested for-loops (that’s what cross products boils down to).<\/p>\n
I also separated desires<\/em> from problems<\/em> because I realized that way too often people (manager, clients, customers, government, etc.) ask the wrong question (because they narrowed it to the wrong\u00a0problem<\/em>) that leads to a lot of wasted work and frequent direction changes. People are too often asked to solve hard problems<\/em> that turns out to be the wrong ones for fulfilling the motivating\u00a0desires.<\/em>\u00a0Very few learn to trace it back to the source (desires<\/em>) and find the correct problem<\/em> to address, which often have easy solutions that’s more valuable to the requester than what was originally asked. This often leads to unhappy outcomes for everybody that’s avoidable. An emphasis on desires<\/em> is one of my frequently used approaches to prevent these kind of mishaps.<\/p>\n
<\/div>\n