Posts Tagged ‘problem solving’

Context Is Everything

May 27, 2014 1 comment

Right along side with POSIWID (the Purpose Of a System Is What It Does), one of my favorite sayings is CIE (Context Is Everything).

Given a problem to solve and a person (or team) designated to solve it, the person will seek a solution in accordance with the constraints imposed on him/her by the surrounding context. As the figure below shows, his/her perceptions and thoughts of the problem will be colored by the context. The problem itself will most likely be perceived differently as a function of the context (as signified in the picture by slightly different poop types). In one or more contexts, the problem might not even be perceived as a problem at all (it’s not a bug, it’s a feature)!


While writing this post, I suddenly realized that there is no difference between the word “context” and “culture” –  but only in the context of this post. 😀


The Drunkard’s Walk

March 21, 2009 Leave a comment

Assume that your company has a problem that needs to be solved. Management then creates a project and allocates resources: money, time and you, to solve the problem. The figure below shows the context that is established at project start. There’s you, the hairball problem, and a solution somewhere at the end of the project pipeline.


Since the best solution (out of an infinite set of possibilities) is almost always unknown a-priori, the amount of allocated money and time may not be correct. In my experience as a participant in the development and (mostly) maintenance of large, complex real-time embedded software systems, the “budgeted” amount of time and money is usually vastly underestimated. To top things off, management usually thinks that the problem-to-solution path is a linear, forward-only, sequential march to success.

The figure below shows the real drunkard’s walk that is traversed when a non-trivial problem gets solved. The start-to-end signature is person-specific. A prim and proper straight line to the solution through the official corpo process book never occurs. If you’re familiar with the problem domain and have solid experience with other similar problems, then your solution path may be less erratic than the path of others.


In the example above, notice how there are 3 occurrences of vector segments that go backward in time to revisit and correct mistakes. Each decision that you make to go backwards is a result of new knowledge discovery and learning. Sadly, because going backwards is a serious taboo in linear-sequential-think orgs, some people consciously decide to never go back,  knowing full well that they’ve left some turds in the road for their followers to step in.

In a high pressure, micro-watched project, publicizing any regression steps to management in real-time is not a smart move. Even though it’s the truth, an unconscious force within you (ego) can cause you to lie and feign forward progress at every status reporting interval. Thus, in your manager’s mind, you’re “on schedule and under budget”. Splendid!

If you’re working on a multi-person project, then everyone else on the team is performing their version of the drunkard’s walk too. At each weekly breathalyzer test (oops! I meant status reporting meeting), everyone tries their damnest to appear sober in order to avoid a DUI .

Happy drinking!

%d bloggers like this: