성급한 최적화는 모든 악의 근원이다.
모듈을 설계할 때는, 심지어 루틴 하나를 설계할 때도, 그것이 지켜야 할 계약과 계약을 지키는지 테스트하는 코드도 함께 설계해야 한다. 테스트를 통과하고 계약을 지키는 코드를 설계하다 보면 자연스럽게 그렇게 설계하지 않았으면 생각나지 않았을 경계 조건이나 다른 문제들을 고려하게 된다.
리팩토링과 업데이트를 동시에 진행하지 마라.
만약 가장 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면 귀찮은 문제를 고치는 그의 열정은 줄어들 것이다. 개발자가 이런 수정작업을 하느라 시간 보내는 것을 팀이 적극적으로 방해하고 나선다면 문제는 더욱 커진다.
팀 전체가 깨진 창문을 용납하지 않아야 한다.
한 팀에 속한 개발자들이 서로 대화해야 하는 것은 물론이고 나머지 세상과 명확히 의사소통 해야 할 필요가 있다.
바깥의 사람들에게 무뚝뚝 하고 과묵해 보이는 팀이야말로 최악이다.
훌륭한 팀은 뚜렷한 특성을 갖는다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문에 사람들은 회의를 기대한다. 그들이 생산해 내는 문서는 깔끔하고 정확하며 일관 적이다. 팀은 대외적으로 한 목소리로 이야기한다. 내부적으로는 토론을 장려한다.