プログラミングの小さな問題

ソフトウェア開発において、SMOP ( small matter of programming ) またはSimple matter of programming は、提案された機能または設計の変更に実際には多大な労力が必要であることを皮肉を込めて示すために使用されるフレーズです。

これは、変更が明らかに可能であるにもかかわらず、実際に実行するには非常に手間がかかることを指摘しています。多くの場合、この機能を提案した人がコストを過小評価していることを意味します。

1983年のJargon FileではSMOPについて次のように説明されている。^[1]

SMOP (ess'em'oh'pee') 名詞。

「a Small Matter Of Programming」の頭字語。まだ書かれていないプログラム コードの一部で、その予想される長さは、その知的複雑さよりもはるかに大きい。

この用語は、明らかに作成できるが、手間をかけるほどの価値がないプログラムを指すために使用されます。また、皮肉なことに、プログラムを作成できるため、難しい問題が簡単に解決できることを意味するためにも使用されます。皮肉なことに、そのようなプログラムを作成するのは大変な作業になることは明らかです。

例: 「FORTRAN コンパイラを変更して COBOL もコンパイルするのは簡単です。プログラミング上のちょっとした問題です。」

IBMの専門用語辞典ではSMOPを次のように定義している: ^[2]

SMOP ( smop ) n.実現可能だが、実現するには利用できないリソースを必要とするもの。「なぜその機能はプログラムで利用できないのですか?」 − 「それは単なるプログラミングの問題です」(数世紀の人手があれば、すべてのことが可能になるという意味です)。また、SMOUP ( smoop ) は、単純なマイクロプログラミングの問題です (手書きの場合は、ギリシャ語のmuを使用)。「それがどれほど難しいか」も参照してください。

SMOP は、ある記事で、自己啓発心理学の分野でエリック・バーン博士が特定した「人々が行うゲーム^{」に類似していると説明された「ゲーム」の 1 つです。 [3]} このゲームは基本的に、デザインに対して一見単純な調整を提案することで、予期しない結果や遅延を引き起こします。

同様の意味で、 simple matter of softwareやsmall matter of softwareなどの別の言い回しも時々使用される。しかし、この言い回しは皮肉を込めずに^{[4]、ある問題を解決するには単純な}ソフトウェア開発だけが必要であることを示すためにも使用される。この用法は、ソフトウェア変更の容易さと、ハードウェア変更や業界標準の変更の困難さを対比させたい場合によく用いられる。この皮肉を込めない用法は、ソフトウェア エンジニアよりも、上級管理職やハードウェア エンジニアによってよく用いられる。 ^[要出典]

この用語は、コンピュータ科学者のボニー・ナルディが1993年に出版した著書『A Small Matter of Programming: Perspectives on End User Computing』でも研究され、拡張されました。^[5]

• 90-90ルール – コンピュータプログラミングにおけるユーモラスな格言
• ホフスタッターの法則 – 時間見積もりに関する自己言及的な格言
• 難易効果 – 認識された困難に基づいて成功を誤って見積もることに関連する認知バイアス
• 計画の誤り – 必要な時間を過小評価する認知バイアス