Creativity and TRIZ

TRIZ (pronounced "treez," for Teoriya Resheniya Izobreatatelskikh Zadatch) is the Russian acronym for the Theory of Inventive Problem Solving (TIPS). TRIZ is a systematic approach to solving a variety of system problems creatively. Its roots can be traced to the Russian engineer and inventor Genrich Saulovich Altschuller, who discovered that the evolution of systems is not a random process, but is governed by certain objective laws. These laws, proposed by Altschuller, in turn can be used to consciously develop a system based on discovering innovative ideas and implementing them. He states that inventiveness can be taught. Creativity is not instinctive, and one does not have to be born with particular traits to be creative; rather, creativity can be acquired by learning.^[1], ^[2], ^[3]

Sidebar 12.1: What Is Serendipity?

Serendipity is the ability to recognize a valuable result that occurs when you're actually looking for something else. The word was introduced into the English language by Sir Horace Walpole in 1754. It was derived from a legend called "The Three Princes of Serendip." (Ceylon was called Serendip by medieval Arab explorers from whom the legend comes.) At a rare truce meeting between their incessant wars, the princes decided that each year they would meet and compare their inventions, and a committee of their combined advisers would elect as king for a year the prince with the best invention. The three princes soon discovered that their best inventions often turned out to be not what they were trying to create, but accidental discoveries they had not intended. In a letter to a friend, Walpole called this situation "serendipity" and thereby added this useful neologism to the English language (Oxford English Dictionary, Volume IX). Stories of serendipity abound in American technology. Perhaps the best known is the discovery of a transparent bulletproof plastic later named Lexan at General Electric R&D Laboratories by Drs. Bendler and French when they were only seeking to create a scratchproof form of Plexiglas. Of course, the oldest serendipity stories are the "Eureka!" experience of Archimedes, much later the discovery of X-rays by Roentgen, and the discovery of penicillin by Sir Alexander Fleming.

When one of the authors was vice president and director of a computer architecture program at a company led by a retired military officer, he had the occasion to note to the CEO that innovation inhered in three qualities: creativity, tenacity, and serendipity. The CEO, ever the military commander, leaned across his large desk and inquired intently, "Yes, but how do you manage serendipity?" The author, realizing that he was on the spot, improvised, "You 'manage' serendipity by providing inventors a laboratory environment in which it is very likely to happen." It was a narrow escape. However, the CEO shortly later led the design of a new research laboratory for the firm in which the physical layout maximized opportunities for serendipity. He really got it!

In English, TRIZ is sometimes called by the tantalizing apparent nonsequitur systematic innovation rather than by its Russian acronym.^[4] Systematic conjures the image of an algorithmic sequence of activities that are performed to achieve a known result. In contrast, innovation is the result of heuristics, which are the opposite of algorithms, and which are erratic and unpredictable. Writers on the subject do not intend an oxymoron and thus carefully define the term to make it precise. The essence of the theory is that contradictions can be resolved methodically by the application of innovation solutions. The premises on which the theory is based are that the ideal design is a goal, that contradictions can actually lead to improved solutions, and that innovation as a process can be structured systematically.^[5] Practitioners of TRIZ have shown that applying common solutions to resolve contradictions improves the design of products and systems. Use of TRIZ has shown it to be far more effective than the ultimate heuristic known as trial and error. This method was favored by Edison, who was fond of saying that genius is "1% inspiration and 99% perspiration." Edison could afford the luxury of doing thousands of experiments to reach a single goal because he surrounded himself with bright young men he trained and supervised closely as co-inventors (see Sidebar 12.2). His methods worked for the incandescent lightbulb, but he wasted a fortune at the peak of his career trying to separate iron ore magnetically.

Actually, all the processes for enhancing creativity are limited, because their usefulness decreases as the goal's complexity increases. At some point all heuristics reduce to trial and error, and the number of trials increases dramatically as complexity increases. Altschuller was motivated to develop TRIZ by two questions: How can the time required to invent a needed product be reduced? and How can a process be structured to encourage breakthrough thinking? He soon realized that scientists are simply not trained to "think outside the box"that is, outside their own field of reference. He and his colleagues then analyzed innovative solutions to problems stated and solved on the worldwide patent base to develop the patterns of innovation. They studied 200,000 patents and selected 40,000 of them as being particularly good exemplars of the methodology they were seeking to develop. These demonstrated that the development of an engineering system is not a sequence of random (heuristic) events but rather is governed by certain patterns. Since then, TRIZ practitioners have reviewed more than two million patents to further refine the method. It is a systematic and orderly way to help engineers think outside the box by giving them examples from beyond their own narrow discipline and experience.

TRIZ has developed a large tool set over the past five decades, beginning with the 40 inventive principles (adapted for software in Table 12.1, shown later), and then the 39 engineering parameters, the four separation principles, the concept of ideality, and the 76 standard solutions.^[6]

Table 12.1. Rea's Analogies for Altschuller's Inventive Principles^[8]

Principle Number	Principle Name	Description	Software Analogy	Example
1	Segmentation	Divide an object into independent parts	Separate similar functions and properties into self-contained program modules	C++ templates and OOP generally
2	Extraction	Separate an interfering part or property from a system	Define the grammar of a programming language to enable interpretive extraction	Extract text from image files
3	Local quality	Change a system's structure from uniform to non-uniform	Change an object's classification from a homogenous hierarchy to a heterogeneous hierarchy	Nonuniform access algorithms
4	Asymmetry	Change the shape of a design from symmetrical to asymmetrical	Change the program to nonuniformly affect a computation's result	Second-order hashing function to even out a hash table
5	Consolidation	Make operations in a system contiguous or parallel	Make processes run concurrently	Synchronize execution of threads in time
6	Universality	Make a part perform multiple functions	Make a program support multiple functions based on context	Polymorphism
7	Nesting	Palce an object inside another, then another, then another	Inheritance in OOP	Nested objects in OOP
8	Counterweight	To counter a system's weight, merge it with other objects that provide "lift"	Use sharing to support large numbers of fine-grained objects efficiently to counter dynamic loads on a system	A shared object that can be used in multiple contexts simultaneously
9	Prior counteraction	Preload counter tension to reduce excessive stress	Perform a preliminary process or actions to improve a later computation	Multiply by a precomputed reciprocal in a loop rather than dividing by a constant
10	Prior action	Carry out all or part of an action in advance	Same	Java translation to interpretive language for a Java Virtual Machine (JVM)
11	Cushion in advance	Prepare a means beforehand to compensate for unusual events	Use an algorithm that handles worst-case harmful effects	Exception handling in Java
12	Equipotentiality	In a potential field, limit position changes	Change an algorithm's operating conditions to control the flow of data in and out	A transparent persistent data store
13	Do something in reverse	Invert the action to solve a problem	Store transactions in reverse order for backing out	Database recovery
14	Spheroidality	Replace linear parts with curved parts	Replace linear data structures with circular ones	Circular buffer
15	Dynamicity	Design the characteristics of an object or process to change to be optimal	Same	DLLs
16	Partial or excessive action	If 100% is hard to achieve, try for less or more by dithering	Increase algorithmic performance by perturbation	Synchronization in Java
17	Transition to a new dimension	Difficulty with moving an object in a line may by solved by moving it in a plane	Use multilayered assembly of class objects	Interfaces in Java
18	Mechanical vibration	Use oscillation	Change the frequency of an algorithm's execution	Change an object's invocation rate to maximize overall application performance, such as updating balances on accounts after each transaction
19	Periodic action	Use periodic rather than continuous actuation	Perform a task periodically rather than continuously	Time scheduled backups
20	Continuity of useful action	Maximize a system's duty cycle	Develop a fine-grained solution that utilizes the processor at full load	Asynchronous nonpreemptive multitasking
21	Rushing through	Conduct a Process at high speed	Transfer data in burst mode before a worst-case scenario	Allocate network banwidth on a priority basis
22	Convert harm into benefit	Eliminate a harmful action by adding it to another harmful action	Invert the role of a harmful process and direct it back	Defeat denial-of-service attacks on a network server
23	Feedback	Introduce feedback to improve a process or action	Introduce a feedback variable into a closed loop to improve subsequent iterations	Rate-based feedback in an asynchronous transfer mode (ATM)system
24	Mediator	Use an intermediary process	Use a mediator to provide a view of the data in a different context	Mediators can be used XML to enhance semistructured data
25	Self-service	Make an object serve itself by performing auxiliary functions	Same	Automatic updating of applications over the Internet
26	Copying	Use an inexpensive copy instead of the real thing	Instead of creating a new object, use a shallow copy	A shallow copy constructs a new object and inserts references to the original object in it
27	Dispose	Repalce an expensive object with multiple inexpensive objects	Same	Use rapid or throwaway prototypes
28	Replacement of a mechanical system	Replace a mechanical system with sensory means	Same	Voice recognition versus typing and reading
29	Pneumatic or hydraulic construction	Use gas or liquid parts instead of mechanical parts	None	None
30	Flexible films or membranes	Isolate the object from its environment	Isolate the object with wrapper objects	Wrappers in Java
31	Porous materials	Make an object porous	None	None
32	Change color	Change an object's transparency	Same	A transparency function in a photo program
33	Homogeneity	Make objects interacting with a given object out of the same material	Create pure objects of a certain type, ensuring identical properties	Container data object, such as an array
34	Rejecting and regenerating parts	Discard portions of an object that have fulfilled their function	Discard unused memory	Garbage collection in Java
35	Transformation properties	Change the degree or flexibility	Same	Software can be transformed to provide a different service based on properties changing by time of day
36	Phase transition	Use phenomena that change during a phase transition	None	None
37	Thermal expansion	Use thermal expansion of materials	None	None
38	Accelerated oxidation	Replace common air with oxygen-enriched air	None	None
39	Inert environment	Replace the normal environment with an inert one	None	None
40	Composite materials	Change from uniform to composite materials	Change from uniform software abstraction to a composite one	Software design patterns are the core abstractions behind successful recurring problem solutions in software architecture

The natural objective function of innovative system development with TRIZ is ideality, which is defined as follows:

ideality = Σ benefits / (Σ costs + Σ harm)

in which evolution toward the ideal system is guaranteed by increasing benefits while reducing costs and harm. To provide direction to the design evolution, the design team usually imagines the ideal final result, which provides an ideal, if unrealistic, goal but gets the team focused on the same "out of the box" goal. This tends to remove both real and perceived barriers by offering alternative solutions. Starting with perfection encourages breakthrough thinking, inhibits backsliding toward less-ideal solutions, and leads to defining clear boundaries for the project.

In spite of this complexity, the method can be most easily understood as a mapping. As shown in Figure 12.1, all the TRIZ tools support this process. You identify a specific problem and its parameters, and then you map it to a generic TRIZ problem. Using the appropriate TRIZ tools, you find the generic TRIZ solution to the generic TRIZ problem. Finally, you map the generic solution from the TRIZ solution space back to the original specific problem space as a specific solution.

Figure 12.1. The TRIZ Solution Process

The first of the inventive principles is segmentation (see Table 12.1). Using this tool allows the user to apply the process shown in Figure 12.1 iteratively on the various subsystems or their components. Principle 7 in the list is nesting (see Table 12.1), which allows the user to employ the process shown in Figure 12.1 recursively on the whole system under design. The genius of the TRIZ inventive problem-solving or design methodology is that it combines at different levels both algorithmic and heuristic problem-solving techniques. It is a curious way of applying knowledge and experience to produce wisdom. Herbert Hoover, a noted hydraulic mining engineer before he became U.S. President, once said, "Wisdom is not knowing the ultimate, but rather knowing what to do next." TRIZ uses an algorithmic process to lead the inventor toward which heuristic to apply next. As always with heuristics, it is in the end a trial-and-error process, but a highly focused trial-and-error process informed by the experience of three million successful inventions documented as patents.

If you're interested in the development and practice of this sophisticated development methodology, we encourage you to read Systematic Innovation: An Introduction to TRIZ (see endnote 4), written by three experienced practitioners and illustrated with many examples from manufacturing. In this book we want to discuss more-recent applications of the method to software development.

Sidebar 12.2: Being There When the Page Was Blank

When one of the authors was an engineering undergraduate, he took an electrical engineering (EE) course on rotating machinery from a 72-year-old professor emeritus. Needing a professor's signature to pursue an opportunity to participate in the International Geophysical Year in 1956, he went to the professor's secretary to get the form signed. He asked if she would have "the doctor" sign the form. She told him that the correct title was Professor, not Doctor, because the professor had no degree. In fact, he had not even attended high school. Shocked, the author asked how the professor could teach at Harvard without a formal education. The secretary replied that when the professor was 13, his father had apprenticed him to Mr. Edison, and the professor's name was also on the patents for almost all the machinery in the school's EE laboratory. She noted wisely that if you invented it, you don't need to go to school to learn about it.