人月の神話第12章：機材やツール、ソース管理など開発の道具立てについて

ツールを個人的に抱えこむのは良くない。個人的ツールはコミュニケーションなどの問題を生む。また、開発対象や開発環境は変わっていくので、適切にメンテナンスされていないツールは寿命が短いことにも注意が必要だ。
汎用的な開発の道具立て（機材やツールなど）については、共通化した開発とメンテナンスを行うべきだ。一方で、チームの特性や好みに合わせてツールを用意する担当者を、第3章のミルズの案のように、各チームに置くべきだ。そのツール担当者は、全ての共通ツールについて習熟していて、その使い方をチームメンバーに教えたり、チームに必要な特殊なツールを作ったりするのである。
よって、プロジェクトマネージャーは、共通ツールと各チームの特殊ツールの両方の開発に対応した体勢とリソース配分を行うべきだ。各チームにツール担当者を置かず、1部署に集めてしまうやり方はうまくいかない。
管理が必要な道具立ては、ユーティリティと呼ばれるようなツールやデバッグやテストのためのツールだけではない。コンピュータなどの機材とその利用スケジュールや、開発に使う基本ソフトとそれにより利用できる機能についての基本方針（service philosophies）、プログラミング言語とその言語の利用ポリシーなども管理が必要である。
機材の利用スケジュールの管理は、まだ量産されていない新しいハードウェア向けに開発しているときなどは、特に必要である。
OS/360の開発では、機材の利用時間の割り振り方として、時間枠を余り細かくせずにまとまったブロックとして割り振った方がうまく行った。
新ハードのためのソフト開発では、2つの点でシミュレータの価値は大きい。1点めは、新ハードの実物が出来上がるずっと前からデバックを開始できること。2点めは、開発に伴い日々変更される新ハードの実物よりシミュレータの方が安定していること。ハードの不良、たいてい出たり消えたりするその不良や、しまいには何が何だかよく分からない挙動は、デバッグをするやる気を失わせるので、安定したシミュレータは思ったより長期にわたって重要である。
クロス開発において、ターゲット向けではなく開発マシン向けにコンパイルし、それで出来る範囲のデバッグをしてしまうのは効率的なやり方である。
ソースコードなどは、きちんとバージョンを管理すること。また、その管理では、各人での開発、とりまとめ（integration）、リリースの各段階がきちんと区別されていること。そして、とりまとめやリリースの段階にあるものを変更できるのは、その権限を持った人のみとすること。
マニュアルなどの文書を管理するシステムは、きちんと整備・運用すること。
パフォーマンスシミュレータはあった方が良い。とても早い時期から取り組むこと。また、シミュレーション結果には真摯に向き合うこと。
高級言語や対話型プログラミングは良い道具だ。（注記：高級言語の有用性や、バッチ処理に対する対話的な（インタラクティブな）機能の有用性は、当時とは違い既に広く認められていると思うので、それらの有用性について書かれた詳細はここでは省略する。）