일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.

- 개발자는 사용자를 잘 알고 있는가
- 프로젝트에 잘 맞게 정리된 방법론을 구체적인 현실에 제대로 구현하고 있는가
- 팀원 간에, 고객과의 관계에서 행하는 의사소통은 효과적인가
- 원활한 의사소통과 개개인의 암묵지를 담아낼 정도로 조직은 유연한가

이어서, 이 거만한 소프트웨어의 탄생을 막아낼 실천적 대안으로 PAPER원칙을 제안한다.
1. Peopleware
2. Active involvement
3. simPlicity
4. Experience
5. Repetition
6. PAPER

프롤로그; 여기서 치이고 저기서 치이는 겸손한 개발자 나대리, 온갖 악조건 하에서도 열심히 개발했지만, 결과는 사용자의 불만 가득한 목소리뿐이다. 그 원인은 무엇인가?

1~5장: 거만한 소프트웨어가 나오는 원인을 짚어 본다.
사용자와 개발자의 인식의 차이, 효율성만 쫓는 권위적인 조직 그리고 개인 간 의사소통의 실패, 이 모든 원인이 어우러져 거만한 소프트웨어가 탄생하게 된다.

- 하이테크 제품이라도 낮은 수준의 소프트웨어를 탑재하면, 품질 딱 그 소프트웨어의 수준만큼 떨어진다. 제품의 질만 떨어뜨리고, 사용자를 고려하지 않은 소프트웨어, 그것이 거만한 소프트웨어다.
- 사용자는 개발자가 생각한 대로 소프트웨어를 쓰지 않는다. 화성에서 온 개발자, 금성에서 온 사용자처럼 한 가지 소프트웨어에서 두 가지 사용법을 발견하기도 한다. 개발자는 사용자의 심리를 잘 이해하면서 소프트웨어를 만들어야 한다.
- 기능이 너무 많아도 사용자는 혼란스럽다. 꼭 필요한 기능을 직관적으로 쓸 수 있게 만들어야 한다.
- 실패를 개선의 기회로 바꾸지 않는 조직, 방법론만 적용하면 모든 게 잘 될 것이라는 착각에 빠진 조직, 효율화라는 명목으로 직원들을 내보내고 아웃소싱에 개발을 맡기는 조직, 단기적으로는 효율적이지 모르지만 장기적으로 손해를 입을 것이다.

6~16장: 그럼 이것의 원인을 어떻게 제거할 것인가?
해답은 PAPER 원칙을 실천하는 것이다. PAPER 원칙은 그 원인을 제거하는 실천법(People, Active involvement, simPlicity, Eexperience, Repitition & Paper)이다.

- 무조건적 야근은 근본적인 해결책이 될 수 없을뿐더러 인센티브는 최종 보상이 되지 못한다. 내가 일하는 데서 보람을 얻는다는 느낌을 주는 것이 중요하다. 부서 사이에 협력이 되지 않을 때, 사일로가 생겼다고 한다. 다른 부서 사이에(디자인 부서+개발 부서) 존재하는 의견 대립에 타협점을 끌어내고 원래의 목표대로 팀을 이끌어 주는 제품 통합자가 필요하다.
- 개발자가 프로그램을 단순하게 만들면 사용자가 힘들다. 프로그램에 갖가지 기능을 넣었다고 외양을 복잡하게 만들어도 사용자가 힘들다. 가장 좋은 방식은 기능이 복잡하더라도 외양이 단순해 보이고 쓰기도 쉬워야 한다는 것이다.
- 프로젝트에 들어가기 전에 생각의 차이를 좁히고, 프로젝트 성격에 대한 합의를 거쳐야 프로젝트 진행에 있어 혼란이 적어진다.
- 사용자가 소프트웨어를 어떻게 사용하는지 알려면 인터뷰만 하지 말고 인터뷰와 동시에 그 사람이 어떻게 움직이며 어떻게 일하는지 관찰해야 한다. 일하는 맥락에서의 소프트웨어 사용법을 파악하는 것이 바로 맥락을 살피는 인터뷰다.
- 프로젝트 진행 시 그냥 반복하지 말고, 한 번 반복할 때마다 개선을 해 나가는 '지속적인 반복'이 필요하다.
- 일하면서 글로 적어두지 않은 경험과 노하우가 많다. 이런 것들을 정리해 조직적으로 학습을 해야 한다.
- 소프트웨어는 사람이 전부다. 오랫동안 부린 땅은 일정 기간 쉬게 해주듯이(아직 실현 가능성은 적지만) 사람에게도 안식년이라는 보상이 필요하다.