생산 환경에서는 사람을 기계 부품으로 생각하는 경향이 있다. 부품 하나가 고장나면 다른 것으로 바꾸기만 하면 되는 것이다. 원래의 것과 호환되는 새 부품을 번호대로 주문만 하면된다.
많은 관리자들도 이와 같은 태도를 갖고 있다. 그들 대부분은 직원 한 사람이 나가면 누구든 그의 일을 대신할 수 있다고 생각한다.
핵심 인력이 회사를 그만두면 어쩌나 하는 불필요한 걱정을 하면서, 그들은 차라리 핵심 인력 같은 건 애초에 없다고 억지로 믿어 버린다. 그들은 경영의 본질은 직원이 들어오든 나가든 여기에 구애받지 않고 업무를 계속 진행시키는 것이라고 생각한다. 그 결과 마치 마술을 부리는 인력 창고가 있어 언제든지 대신할 수 있는 직원을 구할 수 있다는 듯이 행동한다. "조지 가든하이어와 똑같으면서 덜 건방진 걸로 하나 보내!"

단골손님이 서두른다고 요리사가 음식을 허공에서 뚝딱 만들어낼 수는 없다. 요리하는 데는 반드시 필요한 시간이 있다. 프로그래머들도 마찬가지다. 고객의 사정이 급박하면 일정을 당기는 등 서두들 수 있다. 하지만 그렇게 만들어진 결과물이 소원대로 잘 나오지는 않는다. 오믈렛을 2분 내로 만들어 달라고 주문한 고객은 두 가지 가운데 하나를 선택해야 한다. 더 기다리거나, 아니면 채 익혀지지도 않은 음식을 그냥 먹는 것. 소프트웨어 고객도 마찬가지다.
요리사의 경우, 다른 선택을 할 수 있는 여지가 프로그래머보다는 더 많다. 즉 불을 더 세게 하는 것이다. 하지만 그 결과는 구제 불능의 오믈렛이 되는 경우가 많다. 한쪽은 타고 다른 쪽은 전혀 익혀지지 않는 오믈렛 말이다.
저자는 소프트웨어 관리자들의 타고난 용기와 고집이 요리사들이나 다른 공학 분야의 관리자들보다 더 부족하다고 생각하지는 않는다. 하지만 단골 고객이 원하는 날짜에 맞추기 위하여 잘못된 일정 계획을 짜는 일은 다른 어떤 공학 분야보다 소프트웨어 분야에서 더 흔하게 발생한다. 정량적 방법론에 근거하지 않고, 뒷받침하는 자료도 거의 없이 주로 관리자의 직감에 의해서만 결과를 보장하는 견적을 자신의 직책을 걸고 박력 있게 추진하는 것은 그럴싸하게 보일 수도 있다. 하지만 이것은 매우 심각한 결과를 낳는다.

하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지 방법조차 존재하지 않는다.

다음은, 이러한 엔지니어들의 이해하고자 하는 욕구를 꼬집어 내는 오래된 우스갯 소리이다.
『 목사, 변호사, 엔지니어가 사형을 당하게 되었다. 먼저, 목사가 교수대로 걸어 올라갔다. 집행관이 교수대 발판을 여는 레버를 잡아당겼지만 아무 일도 일어나지 않았다. 목사는 신께서 자신을 살려주신 것이라고 주장하며 석방을 요구해 자유의 몸이 되었다. 그 다음, 변호사가 교수대에 섰다. 집행관이 레버를 당겼으나 또 아무런 일도 일어나지 않았다. 변호사는 재시도는 이중 처벌이라고 주장하며 석방을 요구해 자유의 몸이 되었다. 마지막으로, 엔지니어가 교수대 위에 올라가서 교수대를 주의 깊게 살펴보기 시작했다. 집행관이 레버를 당기기 전에 그는 위를 올려다 보며 소리쳤다. "아하, 여기가 잘못됐군요."』
그에게는 교수대에 생긴 문제를 이해하는 것이 살아 나가는 것보다 더 중요했던 것이다.

한편 '오픈소스 역설'이라는 문제가 추한 경제적 측면을 드러내기 시작했다(역설은 지금도 존재한다). GNU, 리눅스, 기타 오픈소스 소프트웨어는 사악한 자본주의 세계로부터 프로그래머들을 해방시킬 목적으로 제작되었으나, 오픈소스 움직임은 오히려 사악한 자본주의자들에게 궁긍적으로 이익을 주는 듯 보였다. 자동차 회사, 정유 회사, 변호사, 슈퍼마켓, 버링튼 코트 팩토리 등 다양한 업계는 소프트웨어에 들일 돈을 절약해서 신이 났겠지만, 이러한 경비 절감으로 프로그래머들이 보상을 받았다는 증거는 어디에도 없었다. 게다가 IBM처럼 리눅스를 사용한다고 시끌벅적하게 공표한 기업을 들여다보면 의구심이 들지 않을 수 없다. IBM은 가장 독점적인 독점 소프트웨어와 독점 하드웨어로 업계를 휘어잡은 거장이 아니던가. IBM은 결국 꼬맹이 벤처 마이크로소프트에게 업계 선두주자 자리를 내놓았고, 마이크로소프트는 역사상 어떤 회사보다도 많은 공돌이를 부자로 만들었다. 마이크로소프트는 백만장자 프로그래머를 수천 명이나 배출했지만, IBM은 몇 명이나 배출했던가? 같은 맥락에서 리눅스가 그리 대단하다면 리눅스 백만장자는 다 어디에 있는가?

대부분의 화가들이 흐릿한 스케치에서 시작해서 그것을 천천히 구체적으로 만들어 나간다. 이런 방식으로 일을 하면 이론적으로는 당신이 아직 덜 끝난 것처럼 보이는 작품으로 하루의 일과를 끝낼 일은 없게 될 것이다. 그 대신에 화가들이 말하는 것처럼, "화가가 작품을 완성하는 경우는 없다. 단지 그는 작업을 멈출 뿐이다." 소프트웨어에서 일하는 사람들에게는 이 말이 낯설지 않을 것이다.

조엘 테스트는 다음과 같은 12개 항목을 포함합니다.
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

한 사람이 감당할 수 없는 업무 요구사항을 만족시키려면 프로그래밍 팀을 조직해야 한다. 그 필요성은 단순히 해야 할 작업의 요구 명세뿐만 아니라 그 일에 필요한 사람들의 능력과 할당된 시간과도 관련되어 있다. 그 2가지 요소 즉, 팀 구성원의 능력과 가용 시간에는 작업을 수용하는 데 요구되는 최소치가 있다. 예를 들어 어떤 프로그래밍 작업은 팀 크기가 아무리 크다 해도 초보자들만으로는 불가능하기 때문에, 경제에서 말하는 인력을 두 배로 늘려도 전혀 소용이 없을 것이다. 일정에도 이와 비슷한 특성이 있는데, 여성을 9명 동원하여 한 달 만에 아이를 낳게 해보려 했다는 우스꽝스러운 실험만 예로 들어도 무슨 뜻인지 이해될 것이다.

"저는 그에게 제가 지금까지 수집한 자료를 보여줬습니다. 그가 보안팀 직원을 호출했고, 우리는 새벽 4시 30분에 그 직원을 회사 건물 앞뜰에서 만났죠." 그 직원과 수석 엔지니어는 에이드리언의 자료를 훑어본 후 구체적으로 어떻게 방화벽을 뚫고 들어올 수 있었느냐고 그에게 질문했다. 대략 아침 6시경 그들의 회의는 끝이 났으며, 에이드리언은 그가 액세스를 얻는데 이용했던 프록시 서버를 실제로 보고 싶다고 부탁했다.
우리는 네트워크를 짚어가면서 마침내 그 프록시 서버를 찾아냈습니다. 그리고 그들이 저에게 묻더군요. "당신이라면 이 장비를 어떻게 안전하게 만들겠습니까?"
에이드리언은 그 프록시 서버가 아무런 특별한 역활도 없이 그저 '노는 시스템'이라는 사실을 이미 알고 있었다.
저는 주저하지 않고 주머니칼을 꺼내서 그 서버의 네트워크 케이블을 잘라버렸습니다. 그리고 그들에게 말했죠. "이제 이 시스템은 안전합니다."
그들이 말했습니다. "그러면 되겠군요!" 그 엔지니어가 종이에 뭐라고 적더니 그걸 프록시 장비에 단단히 붙여버렸습니다. 그 종이에는 '재연결 금지'라고 쓰여 있었습니다.

이론적으로는 이론과 실제에 차이가 없지만, 실제로는 이론과 실제가 다르다.