TMMM
1.[TMMM] #1 타르 구덩이
프로그램 을 프로그래밍 시스템 으로, 혹은 프로그래밍 제품 으로 만드는데 세 배, 여기에서 프로그래밍 시스템 제품 을 만드는데 다시 세 배의 노력이 든다. 프로그래밍 시스템 제품 이야 말로 진정 쓸모있는 물건이며, 대다수의 시스템 프로그래밍이 목표로 하는 결과물로서
2.[TMMM] #2 맨먼스 미신
소프트웨어 프로젝트가 파국으로 치닫는 과정 1. 낙관주의  시스템 프로그래밍 일정 관리의 바탕을 이루는 잘못된 가정은 다음과 같다: > 모든 작업이 예정된 시간 내에 완료될 것이다.  인간이 무언가를 만들 때는, 그 생각에 불완전함이나 모순이 있
3.[TMMM] #3 외과 수술 팀
어떻게 해야 큰 시스템을 의미있는 일정 내에 만들어 낼 수 있을까? 연구에 의하면 같은 그룹 내에서 가장 뛰어난 사람과 가장 못한 사람의 생산성 비율이 평균적으로 10배의 차이가 났다. (재미있는 사실은 경력 연차와 성과 사이에는 어떤 상관 관계도 없었다.) 프로젝트에
4.[TMMM] #4 귀족 정치, 민주주의, 시스템 설계
만드는데 여러 세기가 걸리는 것도 아닌 프로그래밍 시스템에서는 대부분 대성당보다 훨씬 심각한 개념적 불일치 가 발견된다. 왜 Why?설계 책임자들이 대를 이어가는 경우보다도 여러 명이 설계 작업을 나눈 경우에 이런 문제가 발생한다. 좋기는 하지만 연관성 없고 조율도
5.[TMMM] #5 두 번째 시스템 효과
건축물을 설계하는 아키텍트는 나름의 추정 기법을 써서 예산에 맞추어 작업을 진행한다. 이 추정 금액은 향후 도급 입찰 시에 확정되거나, 수정되는데, 입찰가가 전부 예산을 초과하는 때 도 가끔 있다.컴퓨터 시스템이나 프로그래밍 시스템의 아키텍트도 위와 비슷하나 다음의
6.[TMMM] #6 말을 전하다
경험있고 훈련된 아키텍트들은 확보했지만 구현자 수가 많은 상황에서, 아키텍트의 결정 내용을 모두 이들이 듣고 이해하고 구현하도록 할 방법은 무엇인가? 메뉴얼은 제품에 대한 외부적인 명세 로, 사용자가 보게되는 모든 세부사항을 기술하고 규정한다. 따라서 이것이 아키텍트
7.[TMMM] #7 바벨탑은 왜 실패했는가?
창세기의 바벨탑은 프로젝트 성공에 필요한 전제 조건(명확한 임무, 인력, 재료, 시간, 기술)을 갖추었으나 크게 실패했다.프로젝트가 실패한 두 가지 이유는 의사소통, 거기서 귀결되는 조직 이다. 일정 붕괴, 기능적 부조화, 시스템 버그 같은 일들은 모두 오른손이 하는
8.[TMMM] #8. 예고 홈런
시스템 프로그래밍 작업에 드는 시간 추정에 있어 두 가지 사항을 유념해야 한다:코딩 부분만을 추정한 다음에 비율을 역산해서 전체 작업량을 추정해선 안된다. 코딩은 전체의 6분의 1 정도에 불과하고, 그에 대한 추정이나 비율이 잘못된 경우 터무니 없는 결과가 나올 수 있
9.[TMMM] #9. 5파운드 자루에 담은 10파운드
프로그램 크기는 사용자가 지불해야 하는 비용 중에서 많은 부분을 차지하므로, 하드웨어 제작자가 부품 개수에 대한 목표치를 세우고, 부품 수를 통제하며, 개수를 줄일 방법을 모색하듯이, 프로그래밍 시스템의 구현자 또한 크기에 대한 목표치를 세우고, 그것을 통제하며, 크
10.[TMMM] #10. 기록물 가설
목표 (요구사항, 최종 목표, 필요한 것, 제약 조건, 우선 순위)명세 (컴퓨터 매뉴얼 + 성능 명세)일정예산: 예산의 존재는 제약이 없었으면 내리지 않았을 기술적 결정을 내리게 하며, 더 중요하게는 정책적 결정을 강제하고 그 내용을 명확하게 한다.조직도공간 배치측정,
11.[TMMM] #11. 버리기 위한 계획
실험실에서 동작하던 공정이라고 해서 곧바로 공장에 투입할 수는 없다. 실험실에서 개발된 담수화 공정은, 하루 200만 갤런 규모의 지역 급수 시설에 사용되기 전에 1만 갤런 규모의 파일럿 공장 에서 시험이 이뤄져야 한다. 프로그래밍 시스템에서도 동일하게 적용된다. 대
12.[TMMM] #12. 예리한 도구
숙련된 프로그래머들은 자신만의 전문화된 개발 도구(편집기, 정렬 기법, 이진덤프) 등을 자기 파일 속에 몰래 숨겨둔다. 하지만 이런 접근 방식은 프로그래밍 프로젝트에서 어리석은 짓이다. 그 이유는 이하와 같다:가장 근본적인 문제는 개별 도구를 사용하는 사람들 간의 의
13.[TMMM] #13. 전체 그리고 부분들
"나는 저 거대한 심연에서 악마를 불러낼 수도 있지." "그쯤이야, 나도 할 수 있고 누구든 할 수 있지 않소. 한데, 당신이 부르면 악마가 오기는 하는 거요?" - 셰익스피어 (Shakespeare), "헨리 4세" 1부
14.[TMMM] #14. 재앙의 알을 품다.
매일매일 조금씩 일어나는 지연은 더 알아차리기 어렵고, 예방하기도 어려우며, 만회하기도 더 힘들다. 하나하나의 지연만 보면 예정된 일은 반나절이나 하루 정도 늦출 뿐이다.그리고 일정한 한 번에 하루씩, 지연되어 간다.
15.[TMMM] #15. 또 다른 면
컴퓨터 프로그램은 인간이 기계에게 보내는 메세지인 한편, 인간 사용자에게 자기 이야기를 들려주는 또 다른 측면이 있다. 가장 사적인 프로그램이라도 저자이자 사용자인 사람의 기억은 시간에 따라 희미해지고, 자기가 만든 작품이지만 세부적인 내용은 기억을 되살려야 한다.
16.[TMMM] #16. 은 탄환은 없다: 소프트웨어 공학에 있어 본질과 부수성
모든 소프트웨어 제작에는 두 가지 일이 수반된다. 추상적인 소프트웨어 개체를 구성하는 복잡한 개념적 구조를 만드는 본질적인 일, 그리고 이러한 추상적 개체를 프로그래밍 언어로 표현하여 시공간적 제약 안에서 기계의 언어로 대응시키는 부수적인 일 이 그것이다.
17.[TMMM] #17. 은탄환은 없다를 다시 쏘다.
많은 투고자가 타당한 수정사항이나 불명확한 부분을 지적해주었고, 어떤 이들은 감사하게도 조목조목 분석하여 반론을 제기하기도 했다. 이번 장에서는 그런 개선점들을 공유하고 여러 반론을 다루어보겠다. '은탄환은 없다' 에서 말하는 부수적 에 의미는 우연히 일어난다 거나