마이크로소프트 윈도우용 워드 첫 버전은 대표적인 '죽음의 행군' 프로젝트로 알려져 있습니다. 이 프로젝트는 영원히 끝나지 않을 듯이 보였으며, 일정이 계속 늦춰졌습니다. 아까운 시간을 허비했고, 프로젝트 기간은 계속, 계속, 계속해서 연장됐으며, 스트레스는 말도 못할 지경이었습니다. 최종적으로 이 망할 물건을 4년 정도가 지나서야 가까스로 출시했고, 마이크로소프트사는 전체 팀을 멕시코의 휴양지 칸쿤으로 휴가를 보낸 다음에 심각하게 자기 반성을 했습니다.
  마이크로소프트 사는 프로젝트 관리자가 일정을 제촉한 나머지 프로그래머가 형편없는 코드라도 구현해서 서둘러 끝내려고 했음을 알게 됐습니다. 정식 일정에 버그수정단계를 넣지 않았기 때문에 발생한 문제였습니다. 버그 개수를 낮게 유지하려는 어떤 시도도 없었으며, 오히려 상황을 나쁘게 만드는 시도만이 판을 쳤던 겁니다. 예를 들어 텍스트 행 높이를 계산하는 코드를 작성했던 프로그래머의 이야기를 들어보면 기도 안찰 노릇입니다. 이 프로그래머는 일부러 "return 12;"(대부분 워드 프로세서는 기본 폰트 크기가 10아니면 12입니다.)로 만들어 놓고서는 자신이 만든 함수가 항상 올바르게 동작하지 않음을 확인하는 버그 보고서가 오기를 기다렸다고 합니다. 일정은 기껏 기능이 버그로 바뀌기를 기다리는 점검항목에 불과했습니다. 프로젝트가 끝난 다음에, 이런 관례를 무제한 버그 양산 방법론 infinite defects methodology이라 부르게 됐습니다.
 이런 문제를 해결하기 위해 마이크로 소프트사는 전사적으로 무결점 방법론 zero defects methodology이라는 기법을 도입했습니다. 회사에 근무하는 대다수 프로그래머는 낄낄거렸습니다. 관리자 명령만으로 버그 수를 줄일 수 있다고 생각하는 관리 기법처럼 들렸기 때문입니다. 실제로 무결점은 어떤 특정 시점에서 모든 코드를 새로 작성하기에 앞서 버그 제거 작업을 가장 높은 우선순위에 둔다는 사실을 의미합니다.
 <3장>
 ... ...
  어리석은 관리자는 직원이 일을 더 빨리 하게 만들어서 일정을 단축하려고 합니다. 이는 너무나도 비현실적입니다. 사람을 몇 명 더 고용할 수 있을지도 모르겠습니다. 하지만 일정 수준에 이르려면 시간이 걸리므로, 첫 몇 달 동안은 50% 효율밖에는 올리지 못할 거입니다.(그리고 기존 직원은 신입사원을 지원해야 하는 업무가 추가되므로 업무 효율이 더 떨어지게 되지요.) 하무튼 현실적으로 프로그래머를 투입해서 그 효과를 보는 일은 적어도 6개월 정도 걸립니다.
 개발자를 100% 쇠진하게 만드는 대가를 감수하고서 일시적으로 10% 정도 코드를 더 쓰게 만들 수 있을 지는 모르겠습니다. 하지만 이는 그렇게 큰 이익이 될 수 없으며, 옥수수 종자씨를 야금야금 먹어 버리는 상황이 되는 것입니다.
 개발자가 얼마나 피곤한지 생각하지도 않고 모든 사람이 엄청나게 힘들게 일하도록 간청하는 방법으로 코드 생산성을 20% 정도 높일 수도 있겠지요. 쾅, 디버깅 시간은 2배로 늘어납니다. 어리석은 결정은 결국 소탐대실로 끝이 납니다.
 결코 n에서 3n을 얻을 수는 없습니다. 당신이 이런 기적을 낳을 수 있다고 생각하면 당신회사의 주식 시세명을 좀 알려주세요. 오늘 당장 등록하겠습니다.
 <9장>