Some definitions

This post is another one in the series of posts about Inventions and Theory of Inventive Problem Solving (abbreviated in Russian as TRIZ). First, I’d like to call it Inventiveness Theory for short and I’ll use it interchangeably with TRIZ. Because I find it very strange that the Russian acronym ТРИЗ was translated into English as TRIZ and used throughout. Also the Theory of Inventive Problem Solving sounds very cryptic and confusing to an English speaker to say the least.

Why do I write these posts?

The main urge to right these posts is to share the excitement I have about how Inventiveness Theory can help ordinary people to fell like they have tools to be creative in ways that they could hardly imagine, since inventions and inventors are covered with the mythology of divine inspirations and thousands of trial and error attempts before being able to come up with an invention. Inventiveness Theory shows that it’s not exactly the case and its tools and methodology can direct you to invention using algorithmic approach.

Inventiveness is in every engineering field

In the previous post I provided examples of how Inventiveness Theory uses standard solutions to problems that have similar structure. In this post I’d like to show inventiveness is used in every human endeavor. For example, it’s difficult to think of any progress in engineering, physics, mathematics, chemistry without engineers and scientist constantly resolving contradictions and this way making inventions. If you recall Inventiveness Theory defines invention as a resolution of a contradiction that the problem presents.

When Genrikh Altshuller and Rafael Shapiro first wrote about TRIZ in 1956 article¹ most of the examples they provided for the applications of this approach were from mechanical engineering. Later Altshuller and his students worked on more advanced version of Inventiveness Theory which was applied to electrical engineering, chemistry and other fields. Only in recent decades TRIZ was applied to electronics, software engineering and other disciplines.

Since, I have an experience in software development and software testing I’d like to provide most of my examples from these fields. But, I’ll also provide examples from electronics, physics and mathematics. It turns out there could be no science or engineering as we know it without creativity.

Computer Science

Hardware

If we look at Computer Science history we’ll see that it evolved from invention to invention. First, there were mechanical calculators, then came electro-mechanical ones using relays, then electronic computers using lamps. Then with an advent of the semiconductors computers were made with hundreds of transistors later to be replaced with microchips having billions of transistors in one single microcircuit.

Software

Software too had an interesting evolution moving from machine language programming to invention of compilers that allowed a more abstract approach to programming to high level programming languages like Java, Python etc. that allowed programmers to reason almost in a human language while righting programs.

Each of these evolutions wouldn’t be possible without a chain of inventions that scientist and engineers made along the way. For example, let’s take Data Structures and Algorithms topics that any programmer learns to some degree. Sorting algorithms like bubble sort or merge sort are an example of inventions when a problem of sorting data is resolved by various creatives ways, like swapping as in bubble sort or divide and conquer as in merge sort approaches.

What is interesting is that in TRIZ there are a number of ways to resolve a physical contradiction² which are

• In space
• In time
• In structure
• By condition

And in Computer Science computational complexity is also measured in space by memory storage requirements and in time it takes for an algorithm to run.

Real example

One concrete example of a contradiction in software engineering is how to be able to update software without the need to rebuild it which requires extensive resources and procedures once it is deployed in production. The contradiction here is that software should have certain parameters to function, but there is a need for these parameters to be changed when required. This particular problem was resolved in structure by extracting parameter values into a dedicated configuration file. This file is loaded by the main program on start up and can be even reloaded on the fly. This approach allows to update the parameters as required without a need to invest additional development time and rebuilding the software.

References

1. Altshuller, Genrikh, Shapiro, Rafael. “On Psychology of Inventive Creativity”. Questions of Psychology, no. 6, 1956, p. 37-49.
2. Petrov, Vadimir. TRIZ Basics: Theory of Inventive Problem Solving. Self publishing, Kindle edition 2019, p. 368.