이 책도 필독서로 자주 거론되는 책이다. 책 전체적인 내용은 장인의 관점에서 SE에 대한 접근이라 할 수 있다. 주된 요지를 정리하면 다음과 같다. 이제껏 SE의 접근은 잘못되었다. 소프트웨어 개발과 자동차 개발은 다르다. 소프트웨어 개발은 훨씬 복잡한 작업이다. 부품을 끼워 맞춘다고 되는게 아니다. 코딩은 단순한 작업이 아니다. 명세서만 나온다고 순식간에 코딩이 되지 않는다. 기존의 SE에서는 테스트및 버그 수정에 엄청난 비용을 들인다. 애초에 버그 없는 프로그램을 개발하는 것이 맞다. 이 모든 관점에서 볼 때 장인(수퍼 개발자)이 정답이다. 장인을 중심으로 구성된 작은 팀이 효율적으로 일할 수 있다. 열명의 초보 개발자를 고용하는것보다 한명의 장인을 고용하는 것이 좋다.
나름대로 맞는 말이다. 난 전문적인 SE 교육을 받지도, 전문적인 SE 과정을 통해서 개발되는 프로젝트에 참여한 적이 없었다. 학교에서 SE 수업을 들으면서도 가장 황당한 시츄에이션은 교수님들의 코딩 무시 발언이다. 요구사항 정리하고 명세서 뽑으면 코딩은 그냥 끝나는 줄 안다. 심지어는 그런 일들은 인도 사람들이 한다고 할 필요가 없다고 한다. 솔직히 그들이 실제 개발환경에서 일해본 적이 있나 의심스러울 지경이다. 내가 겪은 소프트웨어 개발 현장에서는 고객의 요구사항, 명세서 따위보다 중요했던 것은 실제 코드였다. 요구사항, 명세서를 잘 지켰나 하는 것도 실제 코드가 있을때나 나오는 말이란 것이다. 그리고 그 말이 전파되는 경로가 길수록 중간에 왜곡될 확률이 높다. 이 책의 저자 말마따나 그들이 그토록 좋아라하는 CASE툴, 그들 말대로라면 지금쯤 프로그래머는 멸종했어야 옳다~ 내가 보기엔 그들은 그들의 파이를 차지하기 위해서 단지 그런 것들이 중요하다고 말할 뿐이다. 물론 내가 코드를 작성하는 입장에 있기에 나에게 유리한 입장을 지지하는 지도 모른다.
끝으로 이 책의 내용은 차치하고서, 이 책의 번역의 품질을 따져볼 필요가 있다고 생각한다. 솔직히 이 책의 번역을 한마디로 표현하자면 번역기다. 책의 내용에 시종일관 등장하는 딜리버리(?!), 문맥은 완전 영어 자체를 옮겨논 듯하다. 정말 한번에 읽고 이해하기 힘들다. 세번 네번 읽고 유추까지 해야지 원문이 어떤 말이었는지 생각날 법 하다. 책 내용에 "열린 책 시험"이라는 문구가 나온다. "열린 책 시험"이 당췌 뭔가??? 솔직히 파수꾼, 껍데기랑 틀릴게 없다. 문맥적으로 봐서는 오픈북을 열린 책 시험이라 번역한 것 같다. 정말 아니다~ 이 책의 번역 품질은 최악이다.