Contradiction matrix for software engineering ?
Why ?

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

Darrell Mann proposed a contradiction matrix for software engineering [1]. Its brief examination reveals the following obvious shortcomings:

  1. The parameters of the matrix are similar to the parameters of the Altshuller contradiction matrix compiled by analyzing mainly mechanical systems. Does Darrell Mann want to say that software systems are not different from mechanical systems and do not have their own parameters ? If so, then he errs. Software systems have such unique parameters as portability, scalability, modifiability, extendability, reusability, generality (to name just a few), which his matrix misses. While the latter parameters are relevant to any software system, there are also parameters which characterize specific types of software systems. For example, object oriented software systems are characterized by such parameters as depth of inheritance tree, degree of objects coupling, degree of data abstraction coupling, degree of message passing coupling, number of local methods, lack of cohesion in methods, etc. etc. Has Darrell Mann ever heard of such parameters ? Oopps, I forgot that he takes "great pride in knowing as little of the industry jargon as is possible" !

  2. Suppose that Darrell Mann continued his work and included all the relevant and important parameters. Why would software engineers need his matrix ? Is there need in resolving contradictions between parameters of software ? Not very often. For example, compactness of data contradicts to the speed of their processing. In most cases programmers do not bother with resolving this contradiction and just choose what is more suitable in their case: either higher speed or higher compactness. They do not bother for the following reasons: a) processing time increases noticeably only if the amount of data is large, which is usually not the case; b) the contradiction is often impossible to resolve; c) even if a solution exists, it is usually hard to find (or requires a significant amount of time, which programmers simply do not have); d) even if they had time to find a solution, it would have not significantly affected the quality of their programs. Then why bother ?

    To create the required software, one need not resolve technical contraditions at all. It is enough to just compromise (i.e. trade-off contradictory parameters). Moreover, resolution of technical contradictions may be detrimental to the quality of software.

  3. Logical (or physical in TRIZ terminology) contradictions are what programmers face and have to cope routinely. Unlike in TRIZ, logical contradictions in software design do not stem from contradictions between parameters of software. They stem from incorrect assumptions at the earlier stages of design and implementation. And without resolving logical contradictions (unlike technical contradictions) no software product can be created. However, Darrell Mann's work does not deal with such contradictions (which are of the foremost importance to software engineering) and does not propose means of neither their resolution, nor prevention. The latter, by the way, is more desirable (see the editorial this month).

  4. Mann writes that his research "has confirmed the existence of the same 40 principles as are found in the classical TRIZ." "No software engineers," - he continues - "according to our analysis identified inventive strategies that do not fit into the existing principles". But what is about "fractional cascading" ? Oopps, I again forgot that he takes "great pride in knowing as little of the industry jargon as is possible" !

In conclusion, I could not get rid of the impression that Mann wrote a parody on the Altshuller book rather than a serious work. The tell tale sign is the notorious number (from "Algorithm of Invention") of 40,000 software patents allegedly analyzed ! (Are there so many software patents, by the way ?)

Anyway, his work fits the Marx pattern of evolution: great books/ideas repeat themselves, first as a sincere delusion, second as a deception.

R E F E R E N C E S:

  1. Darrell Mann, "TRIZ for software ?", The October 2004 issue of TRIZ-journal.