Superiority: innovation traps
In the 1980s, I read this short story by Arthur C Clarke, Superiority. From Wikipedia:
“Superiority” is a science fiction short story by British writer Arthur C. Clarke, first published in 1951. It depicts an arms race during an interstellar war. It shows the side which is more technologically advanced being defeated, despite its apparent superiority, because of its willingness to discard old technology without having fully perfected the new. Meanwhile, the enemy steadily built up a far larger arsenal of weapons that while more primitive were also more reliable. The story was at one point required reading for an industrial design course at the Massachusetts Institute of Technology.[1]
The story is now included in:
It could be called an innovation trap. The idea influenced my own position about software design and development. I think there are many innovation traps that, in some contexts, should be avoided.
Ford T vs Lopez X
Take as an example the development of the Ford T:
Initially, the innovation was put in the surrounding ecosystem, instead of a long list of added features to the car. This allow a low price. Assembly line was also an innovation that is not DIRECTLY added to the car. And the first success allows the growth of a large sales network. No fancy features. As Henry Ford said:
Imagine that I could design a “better” car, called it Lopez X, but with many innovations: air conditioning, special powerful fuel, a motor with an innovative design (ie V8, only achieved by Ford company after many years), etc. So, point by point, I could say: my own design Lopez X IS BETTER than Ford T.
But maybe all these added features also added problems: no gas station to provide the special fuel, increase of price, heavy weight of the motor so more fuel consumption per mile, in many zones and uses cases the users don’t need air conditioning, etc.
And maybe all those innovations does not cover any current problem for the users. A better strategy would be to add them when the initial market is already developed. Don’t cross the bridge before come to it.
And it is good to remember Henry Ford quote: “If I had asked people what they wanted, they would have said faster horses.” Yes, some problems has innovative solutions, that maybe are not the perceived ones.
Blockchain and Innovation
In the last four years, I was involved in blockchain development, in my daily job. I have seen different patterns for the innovation problem. Seeing the past, I could recognize the pattern:
“En la cancha se ven los pingos”
That could be translated from Spanish to English as: “horses are seen on the court”. You evaluate a horse by its appearance but maybe you commit a mistake: only its real performance in the court is what it counts. Remember Seabiscuit story (OK, it needed a new trainer, too).
So, how to apply this advice to blockchain development?
Well, instead of adding one feature after another to your production blockchain, pursuing the innovation paradise:
At the end, the last version could have a lot of additions, never tested in the real field, without user and ecosystem validation, and you know: it’s hard to change this in a production environment like a mainnet.
Maybe is better to test such innovations in other ways:
- Write papers about the innovation to add. This allows the peer review and they feedback would be valuable, instead of having a “my innovation should be added immediately”,
- Open the discussion to the community. Maybe there another possible solutions
- Allows the exploration of the innovation in an alternative testnet blockchain (a network dedicated to evaluate an implementation as a proof of concept). Notice I don’t say to add the new feature to your testnet. Not, if the innovation is important, it deserves a dedicated alternative testnet, to be evaluated by the ecosystem.
As in the Ford T history, I see a clear value to the ecosystem. The above process is not new: many times, the Ethereum development team (an open set) and community propose different solutions, to be discussed and tested, and implemented using prototypes, instead of publishing finished code directly to the mainnet. And many alternative solutions to same problems could come from other people, if the discussion is open.
Use the force, Luke!
Angel “Java” Lopez