ウォーターフォールとアジャイル
ウォーターフォールとアジャイルについても、建前を一切排除するなら、
と言えるかも知れません。
建前を一切排除して考えるなら、
に過ぎないと言えますが、汎用機COBOLでは、
- インターフェースを変えられない事情（後述）が有り、
- それにより、開発効率が、「制御の反転」（Wikipedia 日本語版、以下略）の開発手法で実現出来る程度に
- （インターフェースの変化を許容しない）「制御の反転」とは別の後世の開発手法（例えばアジャイル）と比べ開発効率が向上していた
からです。
汎用機COBOLでインターフェースを変えられなかった理由
「制御の反転」では、
- （さまざまな理由から）呼ぶ側を固定する形になる
- 呼ぶ側を固定すると、呼ばれる側からはインターフェースを変えられない
ので、結果的に開発効率が向上する事になりますが、
汎用機COBOLは、
- 個々のプログラム（以下「手続き」という）が全体でどれだけ有るのか管理していない、むしろ、全体が判らなくても構わないのが利点としていた
- コマンド一発リビルドなど有り得なかった（オープンCOBOLになってからはそうでは無い）
- 全体の再コンパイルは、重大事故を引き起こす元凶だった。
- だから、インターフェースを固定し*1、その範囲でプログラムを変更し、個別コンパイルしていた
- 重大事故の原因としては、コンパイルの漏れ抜けや、最新ソースの紛失、などだった。
その為、（開発期間が伸びても気にしない）アジャイルなどと比べ、結果的に開発効率が向上していたと思われます。
インターフェースは”不変”か？
とんでも無いです。なにか（原因の解釈違いの発覚など）で、その結果となる部分の仕様変更が起きたら、100%インターフェースも変更となると思います。
その様な事例は、１でも１０でも無く、もっと管理しづらくなる数だと思います。
アジャイルは、それもするのだと思います。（そうでなければアジリティは実現出来ないと、強く思います。）
結論
これからも「インターフェースの変化をどう制限するか？」が不詳な状況でプログラミングが嫌いになる人は存在し続けることでしょう。
*1:「CPYLIB」というフォルダに、引数情報のみを書いたテキストファイルを置き、各「手続き」がそれをインクルードしていたが、その内容は絶対に固定とした。
