Hi! I'm really happy to see TRIZ mentioned here on HN. I consider myself a TRIZ geek and GS Altshuller, the "father of TRIZ" was one of my influences growing up.
The 40 Principles are rarely used nowadays for solving complex problems. They were originally used in the 1960s to catalog the solutions to "standard" tradeoffs. Eventually, GSA and the rest of the TRIZ community realized that it was more effective to analyze the root of the tradeoff, and solve the problem there.
For those who are interested, I can list down some of the TRIZ tools worth learning. My co-founder and I are applying for the S19 batch and have used some of these tools to understand problems and clarify our ideas.
TRIZ tools are split into two (pre-1985, called Classical TRIZ, and post-1985, called Modern TRIZ)
By general consensus, the most powerful tools in the Classical TRIZ toolkit are:
1. ARIZ 85c (the "crown jewel" of Classical TRIZ)
2. Substance-Field Analysis (akin to the contradiction matrix)
3. 76 Inventive Standards (akin to the 40 inventive principles)
In my opinion, the most powerful tools in the Modern TRIZ toolkit are:
1. Root Conflict Analysis (like Root Cause Analysis but designed to find tradeoffs and roots of the tradeoffs; can also be used for software architecture problems)
2. Advanced Function Analysis (component-interaction analysis with spacetime-correction)
There's a nice article of the overview of the chronological order of TRIZ tool development written by Valeri Souchkov, designer of Root Conflict Analysis.
The 40 TRIZ principles are actually really nice if you’re stuck with a problem (no matter what domain). They might not always immediately lead you to the solution but at the very least open up the solution space and get the creative juices flowing. I got the 40 principles printed on index cards which makes it easy to flip through them.
Plenty of principles that directly work for those domains: taking things out, abstracting stuff away, ... Others just need a little bit of creativity to apply them
TRIZ principles are things like Oxidants, Thermal expansion etc. which have very practical meanings in a material context.
The amount of creativity you need to apply them to software means it's only a form of provocation like Eno's oblique strategies or just flicking through a dictionary. IMHO it's too far from what TRIZ aspires to be i.e. "reuse proven methods drawn from research".
If we want a software version, we need to do software research but good news, we have! We call them design patterns.
Design patterns are great, but the problem they try to solve is "how to build software well". but what about patterns for "how to use/design software to solve problems"?
I've seen some of its principles applied in UI design, to quite fine effect. Some adages translate directly: "the best interface is absence of interface."
I'll go through 10 of them, name the principle, then try to think of ways to apply to software. I might stretch some definitions (which is OK for creativity) but I'll not to do that too much.
1. Segmentation. Divide an object into independent parts.
Functional decomposition. Single responsibility principle. Unix approach of having several small, composable tools that do one thing and do it well.
2. Taking out. Separate an interfering part or property from an object, or single out the only necessary part (or property) of an object.
Remove a heavy computation from a mobile app and do it on the server. Cutting a new release and building a new binary to change one minor thing is slow, so separate things out into a config file that you can change.
3. Local quality. Change an object's structure from uniform to non-uniform, change an external environment (or external influence) from uniform to non-uniform.
Optimize your code with template specializations (such as in C++), so that it is non-uniform across parameterized types. Sense CPU model at runtime and run code that uses available CPU features.
4. Asymmetry. Change the shape of an object from symmetrical to asymmetrical.
Choose a master/slave relationship over a peer relationship. Use public/private key crypto instead of, well, symmetric.
5. Merging. Bring closer together (or merge) identical or similar objects, assemble identical or similar parts to perform parallel operations.
Use vector operations (single instruction, multiple data). Do something as a batch job instead of piecemeal (maybe for greater efficiency). When filtering a list, AND together two predicates instead of chaining together two filters.
6. Universality. Make a part or object perform multiple functions; eliminate the need for other parts.
Use crypto checksum (SHA1, MD5) both to ensure integrity of object and for content-addressability in the same system. System V init system puts name and ordering into filenames (/etc/rc2.d/S10foo runs before S20bar), avoiding the need for a separate place to declare the (full) ordering.
7. Nested doll. Place one object inside another; place each object, in turn, inside the other.
Programming languages that support nested functions. Hierarchical filesystem. Many wire formats contain length-delimited fields that can be jumped past if not needed right now (protocol buffers use these for strings and embedded messages).
8. Anti-weight. To compensate for the weight of an object, merge it with other objects that provide lift.
This one is tough because it's so physical. Perhaps you can compare storage space and weight, say data compression reduces "weight".
9. Preliminary anti-action. If it will be necessary to do an action with both harmful and useful effects, this action should be replaced with anti-actions to control harmful effects.
Employ techniques like guard pages or address space layout randomization to protect against exploits. Or change to a safe language. Rate-limit download/installation of non-urgent software updates to avoid slamming production servers' network and availability.
10. Preliminary action. Perform, before it is needed, the required change of an object (either fully or partially).
Remove a function in your code and replace it with a lookup table. Pre-fetch data (network or disk). Speculative execution in a CPU. Image computer's drive with a canned OS image so you're copying bytes instead of running a series of installers.
Back in the 1950's, my grandfather was an engineer with GE. He was interested in the same question - how can we come up with new innovations on reliable schedule? After honing in a process for his own work, and then internally inside GE, he published it as book - "Professional Creativity".
It's not focused just on the spark of an idea, but covers the whole process from the start of defining what you need to figure out, all the way through to convincing others to use the solution.
I'm clearly biased, but it's a great book! I've used the processes in it all my life and have found them incredibly useful. You can still find copies on Amazon[1].
There was a book for kids published in the Soviet Union which describes some of these principles along with examples. I received it as a gift from my aunt and it was one of my favorite books. It was called something like "And Then Inventor Appears...". Anyone remember the book?
One reviewer said it was disappointing as it is for high school students, which was true, as far as I remember. It had cute cartoons and such in it. The ideas were interesting but again I was in my early teens. As an adult not sure if I'd have the same reaction to it. Certainly not after paying £30 for it.
I still remember some of the solution there, looked at the table of contents and suddenly remembered a lot more, like metal pipe elbow with the steel balls flying to it - use a magnet to build a protective layer of steel balls. Another one is to use blocks of ice to slowly lower a heavy transformer to the ground.
From what I've seen, TRIZ fits nicely with UI design where "the best interface is absence of interface."
Also, I've see it compared to Anatoly Levenchuk's "Systems Engineering Thinking," which is apparently even more voodooish and hard to get the brain around, but likewise proves useful for some people even in isolated pieces.
Actually TRIZ is quite popular among engineering companies but in many cases employees are bounded by strict NDAs and cannot talk about this at all. There are also a few tech consulting firms that use TRIZ as a tool of their trade. In final reports TRIZ in almost never mentioned.
I remember having TRIZ lessons at school, in fifth grade. It was the nineties and schools were trying out new approaches. The most valuable thing I remember was the idea that a problem should solve itself, within its system, without introducing new elements.
There was a company in the 90s that had an expert system trained on patents that was like a CAD tool for solving problems/inventing. Does someone happen to know the name?
An old, Russian set of heuristics to think out of the box and try to solve engineering design problems.
Emphasis was on physycal design (i.e. not software) despite some attempts to port the idea to other domains.
While popular in Russia (but then at the time it was difficult to understand how much "popular/effective" it really was) it did not seem to get more traction elsewhere.
Samsung, Goldstar and other Korean cos are on the train. In Samsung, you actually have to get a TRIZ certificate as a prerequisite for promotion above a certain level in their engineering units.
Comment like yours is why I come to HN! Thank you - I was always interested in TRIZ (I’m from Russia originally) but didn’t know it to be applied anywhere outside of Russia. Out of curiosity, how did you learn about this?
I had few years of high school in Russia in a school with some degree of engineering orientation.
About TRIZ in Samsung and Korean cos, I learned that from Samsung pals I met. I've been all across Asia during the time when OEM electronics was booming: Vietnam, Taiwan, China, Singapore, SK, you name it.
Thanks for correcting me I am on the SW side and I investigated TRIZ a bit back in the ... 90s? It periodically resurfaced but I was never able to find actual usets in Europe (as I said, it may be that is more popular in physical engineering which is not my field at all).
Seriously, why do people brag about "I don't want to skim a medium-length article"? I don't read many articles, too, but I wouldn't go around announcing it to the world and demanding a wrong because too short summary.
When you're the first half of your life, a part of your brain is secretly convinced that you're immortal and that you therefore have all the time in the world. With that state of mind, reading random articles in depth seems like no big deal.
At a certain point (around your mid-30's, usually), a switch flips in your head and you start to realize your time is very much finite.
This is when TL;DR's start to matter a great deal because they help you decide where and how much of your time to invest in random new things.
I don't presume to make a solid guess which part of your life you're in, but I'd say your comment just tilted the odds towards the first half.
Skimming the article for "what is this?" doesn't take more a minute or two. The first paragraph suffices, if you want to know a bit more, read up to the table of contents. And you have your tl;dr, without posting it in every thread.
I would be more understanding if the article were convoluted, or if it were a video. But this is text, easily understood (not "in the category of endofunctors" nonsense), and people still parade around their unwillingness to click on the submission. I find that offensive.
Triaging submissions into "interests me" and "does not interest" me is something you should be able to do without outside help, in the usual case.
The 40 Principles are rarely used nowadays for solving complex problems. They were originally used in the 1960s to catalog the solutions to "standard" tradeoffs. Eventually, GSA and the rest of the TRIZ community realized that it was more effective to analyze the root of the tradeoff, and solve the problem there.
For those who are interested, I can list down some of the TRIZ tools worth learning. My co-founder and I are applying for the S19 batch and have used some of these tools to understand problems and clarify our ideas.
TRIZ tools are split into two (pre-1985, called Classical TRIZ, and post-1985, called Modern TRIZ)
By general consensus, the most powerful tools in the Classical TRIZ toolkit are: 1. ARIZ 85c (the "crown jewel" of Classical TRIZ) 2. Substance-Field Analysis (akin to the contradiction matrix) 3. 76 Inventive Standards (akin to the 40 inventive principles)
In my opinion, the most powerful tools in the Modern TRIZ toolkit are: 1. Root Conflict Analysis (like Root Cause Analysis but designed to find tradeoffs and roots of the tradeoffs; can also be used for software architecture problems) 2. Advanced Function Analysis (component-interaction analysis with spacetime-correction)
There's a nice article of the overview of the chronological order of TRIZ tool development written by Valeri Souchkov, designer of Root Conflict Analysis.
https://triz-journal.com/a-brief-history-of-triz/