The Optimistic Engineer and the Journey

I'm afflicted with a condition known as the engineering mindset.  It can be painful and embarrassing, but it can be useful as well. If you tell me what outcome, future state, you want then I'll design a pattern of technologies, a solution, that will more or less achieve that state.  I tend to be optimistic about the possibility of a solution if only enough technologies are considered.  Technology, in this case, is any repeatable pattern of mechanisms that causes change, that is activation of potential forces.  Note that there are technologies in all domains, from electronics to politics and anything around and in between.

It turns out that often the hard part of the problem isn't developing a solution, it's figuring out what the outcome is that you want.  There are several ways of addressing this problem, but they all follow the same general pattern...

1. Tee up a hypothetical target outcome.
2. Design a solution.
3. Implement it.
4. Determine if it's what you want, i.e. test it.
5. If or when it's not, go back to step 1.

There are a lot of different ways to exercise this pattern,  let's call it the engineering pattern, but they tend to vary based on the cost and risk of implementation and testing.  

A process called "waterfall" tends to be applied when the cost or risk of implementation or testing is high.  It may involve a lot of "thought experiments", where implementation and testing is done in your head.  It may utilize simulations.  It may more heavily depend on testing component parts of the proposed solution before implementation of the proposed solution.  A "contrary" process is known as "agile".  In this case implementation and testing is cheap, so it is immediately implemented and thrown away if it's not what you want.  If it is what you want then use it.  There are a lot of benefits to this approach when it's available to you.  In actual fact there is a spectrum of approaches to the engineering pattern and waterfall an agile are just regions on this map.

A challenge with the engineering pattern is that it takes time.  Time is changes in context due to the application of forces within and on that context.  This is a challenge because developing a solution requires a relatively static view or your target outcome of the moment.  Target outcomes tend to be derived from the current and historical states of the context.  If the current state changes while you're working on a solution, which it always does, then the target outcome will become less optimal and may even become irrelevant.  

The "waterfall" approach tends to be more susceptible to these risks because of the time involved, the "distance" between a proposed outcome and an acceptable solution.  The distance between a proposed outcome and acceptable solution is potentially, but not necessarily, much less using the "agile" approach, but still the difference between the two is primarily governed by the solution development technologies involved.

Why is this true?  Go back and look at the engineering pattern again.  Note that there is no step 6.  This is not an oversight, this is reality.  Producing a solution, for example a telephone, is still just a test.  As technologies change, needs change, or understanding changes that solution looses relevance in it's context.  When it's diverged far enough we go back and develop a new solution.  It doesn't matter if that solution was developed using waterfall or agile.  Of course, durability is an important factor to consider when developing a solution.  How long is that solution likely to stay relevant given our understanding of likely changes in its context?  If durability is low then a high level of investment in solution development may be continuous.

Durability is a downward force on opportunity cost.  As durability increases, opportunity cost decreases.  Opportunity cost is all of the things, that is potential forces, you might be doing, activating, if you weren't focusing your energies on the things that you are doing.  Quicker implementations of the engineering pattern also decrease opportunity cost.  Low durability solutions do not decrease opportunity cost.  Making these trade-offs can create a lot of tension between people with varying value systems.

This is all preamble to an exploration of how the engineering pattern is applied to "bigger" problems such as how people organize themselves to enhance their success.  This will hopefully be addressed in a subsequent post.  Right now, I need to go eat breakfast and get on with my day.