Contradictions Between Expectations/Anticipations and Results/Reality

Y. B. Karasik,
Thoughts Guiding Systems Corp.,
Ottawa, Canada.
e-mail:karasik@sympatico.ca

TRIZ distinguishes between three types of contradictions:

  1. 1) Contradictions between objectives and means (or wishes and opportunities). For example, "I want to do X (or achieve Y) but have no means of (or opportunity for) doing so (or don't know how)". Altshuller called such contradictions administrative.
  2. 2) Contradictions between parameters of a technology (called technical contradictions).
  3. 3) Incompatible (and often opposite) physical requirements to a physical entity (object, action, process, etc). These contradictions are called physical.
However there is one more type lying between 1) and 2). It is contradiction of the following type: doing X has to result in Y but it does not. Had it been "doing X has to result in Y and has not" we would have called it physical. But one word ("does" instead of "has") makes the difference.

Another form of this contradiction is this: expected outcome of X was Y but it resulted in Z.

I call all such contradictions between anticipations/expectations and reality/results investigator's contradictions because their resolution requires investigation of why the expected has not materialized.

For example, recently I was assigned to resolve the following problem in the Virtual Roulette GUI (Graphics User Interface) written in Java Swing: a cursor was visible over the video player of roulette, which was unwanted. I first investigated if cursor was set to hidden in the Java code. It turned out that it was. In this way I bumped into the contradiction: Java Swing player.setCursor() function has to set player's cursor to the required characteristics (e.g. hide it) but does not.

It was not a physical contradiction because instead of "has not" there was "does not". It was a typical investigator's contradiction. So, in order to resolve it I embarked on investigation.

Why does it hide cursor for other Swing components of GUI ? - I would ask myself, - What is the difference between them and the player ? Is it not a Swing component that setCursor() does not work for it ? But no - it is a Swing component because there can be nothing else in Java Swing code that successfully compiles, - were my thoughts.

I did not formulate physical contradiction at this point but on the contrary firmly assumed that it has to be not a Swing component (since setCursor did not work) and simply ignored arguments against it (such as why does it compile as a swing component then and why does it seem to work as Swing component in all respects other than cursor ?).

Now when the onus was on proving that this was not a Swing component the idea supporting this hypothesis immediately entered my mind. The idea was that it could be a window of an independent player software taking place of the Swing component called "player" when it starts playing. The idea was prompted by experience only and not by a methodology. It did not take much time to verify it.

The Swing component "player" indeed turned out to be just a placeholder of the window of the independent software that played video. The Swing component just held the place of the real player while no video was played and gave way to the window of the real player as soon as it started playing. No wonder that cursor set for the above placeholder in our Java code disappeared with it and a regular cursor appeared on the window of the real player as soon as it took place of the placeholder.

There was no way to set cursor over the real player from the Java code because it was not a Java Swing object. I had to call C/C++ functions to do it via Java Native Interface (JNI). In this way the problem was solved.

In retrospect the solution can be seen as separation of contradictory requirements "it has to be a swing component and it has to not be a swing component" between two entities: placeholder of the player is a swing component and the real player is not. But in fact the solution could not be attained via formulating physical contradiction and applying separation principles. It could not because there was no proof that "it has to be not a swing component". Physical contradiction can only be formulated when both "has to" and "has to not" can be proven. In this instance it was not the case. The onus here was on proving that "it has to not be" rather than on formulating contradiction. The solution (in the form of separation) was a by-product of the proof.

Suppose that I would have not guessed that player that actually plays the video is not the Swing player used in our Java code of the GUI. How could the contradiction help then and how could it be resolved ? This guess was the key to solution not contradiction. On the contrary, this was the guess which allowed formulating contradiction retroactively and interpret its "solution" retroactively as separation.

This case study casts doubt on the possibility of resolving investigator's contradictions via transforming them into physical ones and applying separation principles, which is the standard procedure for resolving administrative contradictions. It looks like investigator's contradictions can only be resolved by investigation and solution found can then be retroactively interpreted as separation. This is a big difference between administrative and investigator's contradictions.

Investigator's contradictions are a separate type not studied in TRIZ yet and should be taken into account.