Why TRIZ is mostly irrelevant for software engineering

Attempts to apply TRIZ to computer programming began 30 years ago [1,2]. In the beginning they rotated around contradictions resolution. It was natural for two reasons. Contradictions resolution is the first corner stone of TRIZ. And the process of creating computer program is full of contradictions resolution.

It took several years, however, and participation in the real large scale software projects to eventually realize that contradictions prevention and avoidance is much more important for programming than contradictions resolution.

Programming begins with conceptualization of what the program has to do followed by implementation. At the stage of conceptualization (i.e. defining the functional requirements) there are usually no contradictions. They appear at the stage of implementation when it becomes apparent that this particular implementation contradicts to the functional requirements (i.e. the program does not do what is required, or does it not always, or partially, etc). Then contradictions resolution techniques are invoked to fix the program.

The programmer is lucky if he discovers all such incompatibilities in the course of program design and subsequent testing. In the case of large programs many incompatibilities remain unnoticed for the entire life time of the product. Moreover, fixing of some discovered incompatibilities may lead to creating others, which prolifiration is usually hard to trace1.

The amount and quality of incompatibilities in implementation depends on the size of program and programming techniques employed. In the 1950s and 1960s (when programs were relatively short) there were no techniques (or disciplines) of programming. And incompatibilities (i.e. contradictions) were rampant. Then in the 1970s some first techniques/disciplines appeared to help and prevent contradictions from happening. Since then, evolution of programming languages, methodologies, tools, etc. was driven by desire to make programming less error prone. And error is a contradiction in program: contradiction between what program does and what it is required to do. Hence, the evolution was in fact aimed at creating and advancing the means of contradictions avoidance rather than resolution.

Why engineers other than software engineers still do not bother with contradictions avoidance/prevention ? Because products, which they design are incomparably simpler than software systems. To change emphasis from contradictions resolution to contradictions avoidance requires that system to be complex enough. The level of the complexity of systems other than software ones are still well below that threshold.

The techniques of contradictions prevention are missing in TRIZ, which renders it marginally useful for software engineering2.

R E F E R E N C E S:

  1. G. L. Filkovsky, "Contradictions: analysis and examples" (in "Towards the general theory of creativity", G.S. Altshuller ed., pp. 7 - 25, Baku, 1974).
  2. Y. B. Karasik, "Possibility of creating general theory of creativity: its foundation" (in "Towards the general theory of creativity", G.S. Altshuller ed., pp. 3 - 6, Baku, 1974).


1: The latter phenomenon, by the way, represents a completely new type of technical contradictions. So far all technical contraditions fell into the following category: improvement of one parameter of technical system results in worsening of another one. This worsening parameter was always indicated in the description of any technical contradiction. Thus, contradiction took place between known parameter and known parameter. However, in programming improvement of one parameter may result in worsening of another one, which is hard to indicate ! For example, fixing one bug may result in introducing many new hidden bugs, which nobody is aware of. Thus, it is contradiction between known parameter and unknown parameter (when you know what is improved but do not know what is worsened) !

2: Altshuller sometimes called contradictions "a decease of technical systems" and even spoke about "contraditionless evolution of technical systems". But no tools of so doing were proposed. Moreover, no work in this direction has been ever initiated. It seems that by "contraditionless evolution" he meant applying his "Standards" and "patterns of evolution" to advance systems without resorting to analysis of contraditions existing in technical systems and their subsequent resolution. In this vision, application of "standards" and "patterns" hides the work of contradictions identification and resolution rather than prevents contradictions from happening.