아키텍트의 눈을 뜨게하는 방법으로 세부기능 하나하나에 값을 부여하는 방법이 있다. 예를들어 기능 x의 가치는 한 번 수행할 때 m바이트의 메모리와 n마이크로초 이상은 아니라는 식이다. - 58p
메뉴얼, 혹은 문서화된 명세는 충분하지 않더라도 필요한 도구다. 메뉴얼은 제품에 대한 외부적인 명세로 사용자가 보게되는 모든 세부사항들을 기술하고 규정한다. 아키텍트의 가장 중요한 산출물이다.
어느 부분이 사용하거나 구현하기에 불편한지 사용자와 구현자들로부터 지속적인 피드백을 얻어가며 순환적으로 진행해야 하는 작업이다. 구현자의 편의를 위해 변경 내용은 날짜별 버전과 같이 어느정도 분량을 모아서 반영하는 것이 중요하다.
사용자가 보는 모든 부분을 기술하되 사용자가 보지않는 부분은 기술하지 말아라. 그 부분은 구현자의 소관이며 그 안에서 구현자의 창의성을 자유롭게 뽐낼수 있에 해야한다. 아키텍트는 자신이 기술하는 모든 기능에 애해 구현방안 한가지는 제시할 수 있도록 항상 준비해야 하지만, 실제 구현이 이뤄지는 방안을 지시하려고 해서는 안 된다.
글과 제품간의 일관성이 유지되기 위해선 상세한 명세작성은 한두명이 맡아야한다. - 61, 62p
서술적 정의와 형식적 정의 두 개가 필요하다. 그리고 둘의 우열관계를 만들어주어야 한다. 형식적 정의가 주요 표현방식이고 서술적 정의가 그를 보조하는 방식이거나, 혹은 역이거나. 그렇지 않다면 둘중 어떤것을 우선시해야하는가에 대한 이야기가 언젠가 나오게 될것이다. - 63, 64p
구현하는 데 불명확한 점이 존재한다면 지레짐작으로 진행하기보다 담당 아키텍트에게 전화를 해서 물어보라. 그리고 그 질문은 아키텍처에 대한 권위 있는 자의 해석이며 이게 모두에게 공유될 수 있어록 인지하는 것 또한 중요한 요소이다. - 70p
프로그램의 크기와 그에 따른 투입 공수의 관계 그래프 - 88p
...그는 개발팀이 일정을 절반 정도밖에 지키지 못한다는 것을 발견했다. 각 작업은 애초 추정한 것보다 대략 2배의 시간이 소요되었다.
...일정이 어긋나는 패턴이 나타났을 때 그는 개발자들에게 하루 시간을 어떻게 썼는지 상세히 기록해달라고 요청했다. 그 결과, 개발 팀들이 실제 프로그래밍과 디버깅에 쓸 수 있던 시간은 전체의 50% 밖에 되지 않았고, 일정 추정상의 오류는 전적으로 그것 때문일 수 있음이 밝혀졌다. 장비 정지 시간, 긴급하게 치고 들어오는 짧고 연관성 없는 작업들, 회의, 서류 작업, 회사 일, 질병, 개인 시간 등이 나머지를 이루었다. 요컨대, 원래의 추정은 기술적인 업무를 처리할 시간에 대해 비현실적인 가정을 깔고 있었던 것이다. 내 자신의 경험도 포트먼의 이와 같은 결론을 뒷받침한다. - 89p, 예고 홈런
...아홉 개의 시스템을 프로그래머간의 상호작용 정도에 따라 나누었으며, 그생산성에 대해 다음과 같은 결과에 도달했다.
상호작용이 거의 없는 경우 - 맨이어(man-year)당 1만 명령어
약간의 상호작용이 있는 경우 - 맨이어 당 5000 명령어