どの様な話？
「等べき」とは、
- そのボタンを1回押しても複数回押しても同じ効果が得られることをいう。
例えば、「一時停止」ボタンが冪等でない場合、押すたびに一時停止と
実行再開を繰り返すだろう。
一方、一時停止ボタンを何度押しても一時停止したままの場合は、
別にある「プレイ」ボタンで実行再開させる。後者は冪等である。
（冪等 情報工学における冪等 ユーザインタフェース Wikipedia日本語版）
という風に、ソフトウェアに取り入れると品質（理解可能性、簡潔性、一貫性、保守性、試験性等々）が良くなると言われる概念との事です。
年度が変わって、
年度が変わって、私が面倒を見ているメールの異動対応をしたのですが、そこに等べきが有ったのです。
メールサーバーは今まで二種類（オンプレミスのExchange Server Standardと、クラウドのメール）見て来ました。
もちろん、1人2人対応する際の（補助的な）操作では、GUIで、差分で操作出来ますが、大量人の異動対応の場合、
CSV（Exchange ServerはPowerShellのスクリプト）での対応が出来ると嬉しいと思います。
今まで、深くは考えませんでしたが、それら2つのメールサーバーとも、MLのメンバーをスクリプトで変える場合、
- 変更後のそのMLの全メンバーを指定
するのが常套手段となっているのに気づきました。差分では無いのです！
何故か？
やはり、
- 「変更後の全メンバーを指定」だと等べきで、
- 「差分」だと等べき性の一部が失われる
というのが原因だと思います。オンプレ・クラウド双方での有名所のアプリ2種が共に、前者だというのは、付合する何かが有る可能性が大です。
良いことばかりか？
良いことばかりでも無いと思います。「変更後の全メンバーを指定」の方が「差分」よりスクリプト作成の負荷が上がると思います。
等べきというのは、
- たちの悪さを、呼ぶ側の負担として、リスクを移転しているだけ
かも知れません。まぁ、昔言われた「ステートレス」なサーバーなども
- 引数の内容が（「ステートフル」なサーバーと比べて）増える
傾向に有ったので、理屈はとおっていると思います。
技術革新に於いて名前が等べきで無い場合
「反転」というのは等べきで無いと思います。
その様な技術革新以前のプログラムでも、
- 全商品の最大公約数的オブジェクトを必ず門番として設け、
- それを介してのみ、各商品のそれぞれの処理のオブジェクトにつなぐ
構成をとっていた事がありますが、
- これを「反転」させると改悪になる
と思います。なんで（技術「革新」にもかかわらず）この様な悪影響が出るのかというと、
- 名前が等べきで無かったから
では無いかと思います。すでに良い方向に有った場合には「反転」させると改悪になるのです！！！
もちろん「等べき」も良いことばかりでは無いのですが、このケースは悪さが際立つと思います。
結論
「等べき」で無い技術革新に関する名前により、これからもプログラミングが嫌いになる人は存在し続けることでしょう。
