“나도 할 수 있고 누구나 할 수 있다. 하지만 당신이 그것을 작성했을 때 제대로 작동하는가?” - 맨머스 미신 중

1

이 책이 1975년에 출판되었음에도 불구하고 ‘지금’ 우리의 이야기 같다고 느껴진다면?

2

무릎을 맞대고 같이 울 수 밖에…

---

“일정 추정”은 언제나 힘들다. 물론 그 일정을 ‘단축’하는 일은 쉽다. 그리고 다 같이 망하는거다.

소프트웨어 프로젝트가 실패하는 가장 흔한 이유 1) 견적 기술 미비, 2) 인력과 작업 기간은 상호 교환 가능하지 않음 3) 견적 수치에 대한 확신 없음 4) 감독 기술 없음 (그냥 빨리~ 빨리~) 5) 일정이 공전되면 사람을 넣어서 헬게이트 완성시킴

“니 생각”이 곧 버그다.

[…] 하지만 우리의 아이디어에 문제가 있기 때문에 버그가 존재한다. 따라서 우리의 낙관주의는 정당화하기 어렵다.

TDD가 괜히 나온게 아니다.

[…] 하지만 실제로는 대부분 실제 일정의 절반 정도를 테스트 목적으로 사용했다.

무리한 일정 ‘단축’이란, 좋은 프로그램 ‘조금’, 치명적인 버그 ‘많이’

[…] 오믈렛을 2분 내로 만들어 달라고 주문한 고객은 두 가지 가운데 하나를 선택해야 한다. 더 기다리거나, 아니면 채 익혀지지도 않은 음식을 그냥 먹는 것. 소프트웨어 고객도 마찬가지다.

인력을 추가해봐야 ‘복잡도’만 증가한다.

[…] 일정 자체를 조정하고 인력은 추가하지 않는 것이 좋다.

팀은 8명을 넘겨선 곤란하다.

결론은 간단하다. 200명 규모의 프로젝트를 운영하려면 최고의 능력과 경험을 가진 25명의 관리자가 있어야 한다.

설계는 유니콘이지…

설계는 구현과 명확하게 구별되어야 한다.

‘스타일’은 언제나 중요하다.

다른 예술이나 공예에서도 규율이 예술에 좋은 영향을 준다는 믿음을 갖게 하는 사례가 많다.

애자일 덕분에 이런건 별 문제가 안 될 것 같지만 꼭 그렇진 않다.

대부분의 소프트웨어 프로젝트에서, 최초의 결과물은 거의 사용할 수 없는 물건이라고 봐야 한다.

명세는 언제나 중요하다. “좋은 프로그램 만들어주세요” 같은게 “우주”에 있을리 없쟈나?

파나스는, 본질적으로, 자동 프로그래밍은 대부분의 경우 문제가 아니라, 명세가 주어져야 할 해결 수단이라고 주장한다

구현도 그러하다.

[…] 위대한 설계는 위대한 설계자만 할 수 있다. 소프트웨어 구축은 창조적인 과정이다. […] 판에 박힌 듯 일하는 사람들에게 불을 지피고 영감을 줄 수 없다.

매우 좋다.

점층적 구축 모델이 더 좋다 - 진보적인 정제작업

자신의 오류에 대해서 겸손하고 용감하다.

정보 은닉에 관해서는 파나스가 옳았고 저자가 틀렸다.

일정대로 가는게 최선이다. 줄여서 얻는건 ‘버그’요, 잃는건 ‘고객’이다.

몇 사람을 투입하든 상관없이, 계산된 최적 일정의 3/4 이내에 성공적으로 마무리 되는 프로젝트는 거의 없다.

SW는 전부 사람이다. 모든게…! 괜히 ‘공밀레’가 아니다.

사람이 전부다(어쩌면, 거의 전부다)