RE: The “Optimal” Fallacy

In The “Optimal” Fallacy, Jurgen Apello states that “You cannot ‘optimize the whole’. The best you can do is sub-optimize, cooperate, and iterate.”

Read his whole post for more context, but I’ll do my best to summarize.

  1. There exists a Lean principle called “Optimize the Whole”
  2. The assumption is that the customer’s view on a business is one that includes the whole system. This is not true.
  3. No observer of a system can claim to have an objective view on the whole
  4. All the parts try to optimize for themselves, and through interdependencies between the parts the whole system tends to evolve to an optimal situation.

Later, in the comments, he states, “I am referring to complex systems, which are not designed by a single authority,” as opposed to designed systems.  If that’s really what he meant, it’s a straw man that is not very interesting at all.  So emergent systems cannot be optimized as a whole? Duh! Who is the actor in that passive voice sentence? I mean, who would even do the optimization if it were possible? Mr. Emerge?

Is Toyota’s production system not complex? Or does he claim that they don’t really optimize the system at Toyota? If we are talking about theoretically optimal, I would agree.  “Optimal” means the “the most desirable possible under given restrictions.”

However, to “optimize”, at least in the most common usage among people like me, means “to make more desirable”. When a compiler optimizes your performance, we do not assume that it is as fast as it can possibly be and as memory efficient as it can possibly be, only that it is faster and perhaps more memory efficient than it would otherwise be without the optimization.

When I think of “optimizing the whole,” “optimize” does not mean mathematically optimal and “the whole” does not mean a boundless system of independent actors and discussions about Arrow’s Impossibility Theorem don’t enter into it because you just get a product manager who does the best job he can of ranking things and consider that gospel, then do the best you can to improve your throughput on that list.

Take for example the Kanban systems for software development. A major benefit of this system is the help it provides optimizing the whole system.  If you have a process of product/feature conception feeding into high level design feeding into development that feeds into QA that feeds into deployment, and you can see that QA always has more works in progress than they should, it won’t do you any good to get more efficient at development or high level design or feature conception.  You don’t need more ideas for more features, you need QA to move faster (or save money by having less development capability), but speeding up your development process without speeding up your QA process won’t get your customers features any faster (or won’t get your shareholders value any faster).  That’s just this example.  The bottleneck could obviously be anywhere – deployment, product conception, development.

Taking measures to improve the efficiency of the whole value chain is all that is meant by “Optimizing the whole”.   To claim this is futile is just silly.

Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: