Automation eliminates value but not risk: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a|design|}} | {{a|design|[[File:Noughts and crosses.png|450px|frameless|center]]}}{{Quote|{{caps|''Dr. Johnson''}}: Sir! I hope you’re not using the first English dictionary to look up rude words! <br> | ||
{{caps|''Blackadder''}}: I wouldn’t be too hopeful — that’s what all the other ones will be used for. | |||
}}{{drop|I|f you can}} [[Automated|automate]] something, you can’t monetise it. You automate, therefore, as a ''defensive'' strategy: because everyone else is automating, and if you don’t, your unit cost is higher. | |||
This plays to a pet theory of the [[JC]]’s: [[the quotidian is a utility, not an asset]]. If you believe you have [[intellectual property]] in your [[boilerplate]], you will waste precious resource defending | This plays to a pet theory of the [[JC]]’s: [[the quotidian is a utility, not an asset]]. If you believe you have [[intellectual property]] in your [[boilerplate]], you will waste precious resource defending an articulation of common knowledge.<ref>You didn’t ''invent'' the “[[rights cumulative]]” clause, now, did you?</ref> You will, accordingly, misprice that asset, and you may be disappointed in how much people will be prepared to pay for it. | ||
Proprietors of contract assembly tools, take note. The value is in ''what'' you assemble, not ''how''. | Not much. | ||
Proprietors of contract assembly tools, take note. The value is in ''what'' you assemble, not ''[[Secret sauce|how]]'' or ''with [[Boilerplate|what]]''. Neither “how” in the sense of your precious inviolate [[boilerplate]], or “how” in the sense of the “ingenious” application that you, and a [[Bulgarian freelance coder|Java coder from Bucharest you found on ''UpWork'']] threw together over a mad weekend six months ago. You know how your software contraption was quite easy, in the scheme of things, to make? How it only cost you five thousand Romanian Leu? This should be your clue to understanding that ''this is no impregnable hillfort from which to launch your megacorn''. | |||
The ''what'' comes not from your friend’s elegant runes of JavaScript, nor from your cheeky user interface, but from your customer’s unique use-case. If you can explain what justifies your monetising ''that'', do write in and let us know. | |||
===Automation eliminates value...=== | ===Automation eliminates value...=== | ||
Automation keeps you in business; it isn’t ''a'' business. If every function in your organisation can be managed by an [[algorithm]], it is game over. There is no excitement, no difficulty, no skill required, ''no value left''. Behold the difference between [[noughts and crosses]] and [[chess]]: both are [[deterministic]], [[zero-sum game]]s — therefore unsuitable analogies for [[technological unemployment]], but that is another story — but [[noughts and crosses]] has been solved. There are trivial, mechanical steps to force a stalemate. | Automation keeps you in business; it isn’t ''a'' business. If every function in your organisation can be managed by an [[algorithm]], it is game over. There is no excitement, no difficulty, no skill required, ''no value left''. Behold the difference between [[noughts and crosses]] and [[chess]]: both are [[deterministic]], [[zero-sum game]]s — therefore unsuitable analogies for [[technological unemployment]], but that is another story — but [[noughts and crosses]] has been solved. There are trivial, mechanical steps to force a stalemate. It is no fun. Skill in [[noughts and crosses]] has no value. It doesn’t really even count as a skill. [[Chess]] is ''capable'' of algorithmic solution, but ''it has not been solved''.<ref>''Yet''. But it is a matter of time, and processing power. Interesting question actually: can we deduce, now, that when chess is solved, the solution will be a stalemate? Statistics seem to imply that white has a first-mover advantage, though Wikipedia tells us “chess players and theoreticians have long debated whether, given perfect play by both sides, the game should end in a win for White or a draw. Since approximately 1889, when World Champion Wilhelm Steinitz addressed this issue, the consensus has been that a perfectly played game would end in a draw”.</ref> Hence, to those who enjoy that kind of thing, chess is still fun. Skill in chess has some value.<ref>But a diminishing amount: even though not entirely solved, the enhanced algorithmic power available to neural networks and so-on mean that they can consistently beat humans, which kind of makes it less interesting to see how well humans play. </ref> | ||
===... but not [[risk]]=== | ===... but not [[risk]]=== | ||
But, while rigorous and well-executed automation can remove all the ''micro''-risks that are intrinsic/internal to the process being automated — logical lacunae, process inconsistencies, natural fallibility of the [[meatware]] who would otherwise be operating the process — it cannot, even in theory, manage the ''extrinsic'' risks arising from the inevitable interaction of the automated process with the inchoate and innumerable [[System|systems]] of the outside world. These contingencies present [[complex]], [[non-linear]] and potentially catastrophic risks. They are by nature impossible to see from within an automated process, let alone to predict in advance. | But, while rigorous and well-executed automation can remove all the ''micro''-risks that are intrinsic/internal to the process being automated — logical lacunae, process inconsistencies, natural fallibility of the [[meatware]] who would otherwise be operating the process — it cannot, even in theory, manage the ''extrinsic'' risks arising from the inevitable interaction of the automated process with the inchoate and innumerable [[System|systems]] of the outside world. These contingencies present [[complex]], [[non-linear]] and potentially catastrophic risks. They are by nature impossible to see from within an automated process, let alone to predict in advance. | ||
So: yes, standardise and automate by all means, but don’t expect it to lead to lasting revenue, or even cost savings and expect that you will need to monitor the interface between your closed logical system and the dirty, intractable world, like a hawk. | So: yes, standardise and automate by all means, but don’t expect it to lead to lasting revenue, or even cost savings and expect that you will need to monitor the interface between your closed logical system and the dirty, intractable world, like a hawk. This is the lesson of ''The Sorcerer’s Apprentice'', by the way. | ||
What do you mean? | |||
{{sa}} | {{sa}} | ||
*[[The quotidian is a utility, not an asset]] | |||
*[[Proprietary information]] | *[[Proprietary information]] | ||
*[[Artificial intelligence]] | *[[Artificial intelligence]] | ||
{{ref}} | {{ref}} | ||
Latest revision as of 12:38, 7 May 2024
|
The design of organisations and products
|
Dr. Johnson: Sir! I hope you’re not using the first English dictionary to look up rude words!
Blackadder: I wouldn’t be too hopeful — that’s what all the other ones will be used for.
If you can automate something, you can’t monetise it. You automate, therefore, as a defensive strategy: because everyone else is automating, and if you don’t, your unit cost is higher.
This plays to a pet theory of the JC’s: the quotidian is a utility, not an asset. If you believe you have intellectual property in your boilerplate, you will waste precious resource defending an articulation of common knowledge.[1] You will, accordingly, misprice that asset, and you may be disappointed in how much people will be prepared to pay for it.
Not much.
Proprietors of contract assembly tools, take note. The value is in what you assemble, not how or with what. Neither “how” in the sense of your precious inviolate boilerplate, or “how” in the sense of the “ingenious” application that you, and a Java coder from Bucharest you found on UpWork threw together over a mad weekend six months ago. You know how your software contraption was quite easy, in the scheme of things, to make? How it only cost you five thousand Romanian Leu? This should be your clue to understanding that this is no impregnable hillfort from which to launch your megacorn.
The what comes not from your friend’s elegant runes of JavaScript, nor from your cheeky user interface, but from your customer’s unique use-case. If you can explain what justifies your monetising that, do write in and let us know.
Automation eliminates value...
Automation keeps you in business; it isn’t a business. If every function in your organisation can be managed by an algorithm, it is game over. There is no excitement, no difficulty, no skill required, no value left. Behold the difference between noughts and crosses and chess: both are deterministic, zero-sum games — therefore unsuitable analogies for technological unemployment, but that is another story — but noughts and crosses has been solved. There are trivial, mechanical steps to force a stalemate. It is no fun. Skill in noughts and crosses has no value. It doesn’t really even count as a skill. Chess is capable of algorithmic solution, but it has not been solved.[2] Hence, to those who enjoy that kind of thing, chess is still fun. Skill in chess has some value.[3]
... but not risk
But, while rigorous and well-executed automation can remove all the micro-risks that are intrinsic/internal to the process being automated — logical lacunae, process inconsistencies, natural fallibility of the meatware who would otherwise be operating the process — it cannot, even in theory, manage the extrinsic risks arising from the inevitable interaction of the automated process with the inchoate and innumerable systems of the outside world. These contingencies present complex, non-linear and potentially catastrophic risks. They are by nature impossible to see from within an automated process, let alone to predict in advance.
So: yes, standardise and automate by all means, but don’t expect it to lead to lasting revenue, or even cost savings and expect that you will need to monitor the interface between your closed logical system and the dirty, intractable world, like a hawk. This is the lesson of The Sorcerer’s Apprentice, by the way.
What do you mean?
See also
References
- ↑ You didn’t invent the “rights cumulative” clause, now, did you?
- ↑ Yet. But it is a matter of time, and processing power. Interesting question actually: can we deduce, now, that when chess is solved, the solution will be a stalemate? Statistics seem to imply that white has a first-mover advantage, though Wikipedia tells us “chess players and theoreticians have long debated whether, given perfect play by both sides, the game should end in a win for White or a draw. Since approximately 1889, when World Champion Wilhelm Steinitz addressed this issue, the consensus has been that a perfectly played game would end in a draw”.
- ↑ But a diminishing amount: even though not entirely solved, the enhanced algorithmic power available to neural networks and so-on mean that they can consistently beat humans, which kind of makes it less interesting to see how well humans play.