Once Again on Relevance of TRIZ for Software Engineering

Y. B. Karasik,
Thoughts Guiding Systems Corp.,
Ottawa, Canada.

Programming, by definition, is decomposition of a higher level function into a sequence of lower level operations permissible by a programming language. For example, the objective of a program could be computing a schedule and permitted operations could be just arithmetic operations. Then writing such a program is the process of decomposing its objective into a series of arithmetic operations. The main problem here is to make such a decomposition correct so that the program really performs the required function [1].

TRIZ does not have means of decomposing functions into predefined elementary operations correctly. It never was its objective because this type of design is specific to programming only and to a much lesser degree to electronic engineering where there is a need in designing logical circuits from a predefined set of logical gates (or a scheme from a given set of chips). All other types of engineering do not have this problem because they do not have ready-made elementary blocks from which any machine can be assembled. Although engineers in other fields may also face the need of decomposing a function into sub-functions, they are not restricted by the existing set of elementary blocks and can do it at will.

One may object that car designers, for example, also have a predefined set of elementary blocks: engine, transmission, exhaust system, etc. However, these are generic blocks only. Nobody requires car designers to design their cars from parts of existing cars. Designers may design their own parts, whereas programmers cannot. They are given the set of "elementary parts".

This explains why TRIZ never scratched the surface of this problem, which is at the heart of software engineering. Although programmers may face contradictions in the course of a program design, it only happens because they do not have means of errorless decomposition of complex functions into elementary operations. Contradictions in program design stem from errors made during decomposition.

Solving contradictions arising in the course of programs design is a marginal issue for software engineering, which makes the value of TRIZ for it also marginal.

Nevertheless, recently I received the following letter:

What can be said ? If there is an "insufficient, excessive or harmful" action of one software component on another, then there is a bug. Thus, "coding for no bugs" would result in absence of "insufficient, excessive or harmful" actions and no TRIZ would be required to get rid of them. Hence, developing methods of "coding for no bugs" is much more important for software engineering than adapting TRIZ to it.

Generally, contradictions in software stem from erroneous decisions during design. Their resolution is, however, simple as soon as the root cause is identified and does not require the knowledge of separation principles. This is confirmed by the fact that hundreds of thousands of programmers solve such contradictions routinely without having a slightest idea of TRIZ. Thus, the main problem is to find the erroneous decisions. Resolution of contradictions comes as a byproduct of it.

As for "solving software problems by harnessing hardware resources", it is beyond the scope of software engineering (unless this hardware is firmware). And what is meant by "harnessing resources of super-system" is not clear.

The idea that all subsystems of a system have to evolve (i.e. get modified) at the same rate is wrong for any type of engineering [2]. But in software it is a sure way to make a system not working. Subsystems have to be modified to that degree, which is needed for implementing new functionality. Not more and not less. Imposing restriction that all subsystems have to be modified by the same percentage would make a system not working.

Arguing that TRIZ is applicable to software engineering because both abstract and model problems is a logical fallacy. Physics also abstracts and models problems. Does it make it applicable to software engineering ?

And attempts to define Substance and Field for software have no more sense than search for them in poetry.

R E F E R E N C E S:

1. Y.B. Karasik, "Why TRIZ is mostly irrelevant for software engineering"

2. Y.B. Karasik, "On an Erroneous Interpretation of the Altshuller Law of Uneven Developmenmt of Subsystems of a Technical System"