人月の神話
ブルックスが1986年に発表した論文である。『人月の神話 20周年記念版』では、第16章として収められた。「銀の弾丸」として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や特効薬は、今後10年間 (1986年の時点から10年の間) は現れないだろう。そもそも、ソフトウェア開発の複雑性には、「本質的な複雑性」と「偶有的な複雑性」とがある。これまで、ソフトウェア開発者は、高水準プログラミング言語、タイムシェアリングシステム、統一されたプログラミング環境により、偶有的な複雑性の多くをやっつけてきた。しかし、現在 (1986年) のプログラマは、ほとんどの時間を本質的な複雑性に取り組むことに費している。
ブルックスは、次のことを提案している。
購入できるものをあえて構築しないようにするための大市場の利用。
ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的 (系統的) に成長させること。
若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。
— (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、第16章、P.166)
『人月の神話』(にんげつのしんわ、英: The Mythical Man-Month: Essays on Software Engineering)は、フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍である。
チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで(そして、電子メールで)。 Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. [And by electronic mail.]
外科手術チームでは、一人の外科医が指揮を執る。そして、その外科医は最も重要な作業を行う。一方、他のメンバーは、その外科医を補助したり、それほど重要ではない仕事をする。このやり方は、ソフトウェアプロジェクトにも活用できる。つまり、一人の「優秀な」プログラマが、重要なシステム・コンポーネントを開発し、他のメンバーが、そのプログラマに対して、必要なものを提供する。