소프트웨어 컨플릭트 2.0

원서 : https://www.amazon.com/Software-Conflict-2-0-Science-Engineering-ebook/dp/B002GYWP1K/

인상 깊은 단락

p19

업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.

p37

설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다.

성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다.

p40

‘The Mythical Man Month'와 최근 ‘Sillver Bullet’ 논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두가 인정하는 작품은 개인이 설계한 작품이라는 사실을 지적한다.

p41

설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이란느 사실을 이해해야한다.

p44

현재 소프트웨어 오류 문제를 모두 해결하는 단일 프로세스는 존재하지 않는다.

p45

소프트웨어 오류 제거에서 가장 중요한 요소는 제품의 특성이나 프로세스의 특성이 아니라 올바른 사람의 선택이다.

p48

오류 제거에 드는 비용은 시스템 분석과 설계와 구현에 드는 비용 각각에 비해 거의 2배에 이른다.

p50

검토는 테스트보다 더 빠르고, 더 경제적으로, 더 많은 오류를 찾아낸다.

p68

디버깅 : 어떤 사람들은 다른 사람들보다 28배나 더 우수하다.

p82

직접 재미난 일을 할 수 있는데, 재미난 일을 하는 사람들을 관리하는 직업이 무슨 재미가 있겠는가?

94

자동 프로그래밍의 미신

최종 사용자는 새로 습득한 컴퓨터 전문 지식과 응용 분야 지식을 결합하여 프로그래머가 될 것이다.

p98

“Life Cycle concept considered hamful” 이라는 논문

p120

4GL에 대해서

p125

4GL의 이득은 생산성보다 품질

소프트웨어 자동화 도구로 얻는 이익은 흔히 주장한듯 ‘혁명적'이라기보다는 ‘점전적'이다.

p153

생산성 향상 효과가 미미하다는 베리 뵘의 논문소개

p250

전산학이라는 과학과 소프트웨어 공학이라는 공학에는 탄탄한 실험에 기반하는 성향이 결여되어 있다.

252

실험은 어렵고 비용이 많이 들며, 대다수 사람은 실험하는 연구보다 ‘생각하는 연구'를 더 선호한다.

p258

가장 최근에 일어났떤 초대형 사고를 예로 들자면, 마이크로소프트 사는 새로운 워드 프로그램 개발 기간을 잘못 예측해서 새로운 제품이 준비되기도 전에 이전 버전을 시장에서 거둬들이는 탓에, 주식이 하루만에 15%나 떨어지는 현상을 목격해야 했다.

(역주)1984년 9월에 시작한 마이크로소프트 윈도우용 워드 1.0 개발은 예상 완료시점인 1985년 9월을 넘겨도 한참 넘긴 1989년 11월에 최종 완료되었다.

p260

소프트웨어 부문에서 예측 악습과 관련한 또  다른 흥미로운 문제가 있다. 다른 분야를살짝 들여다본 사람이라면 어느 누구도 정말로 소프트웨어 분야만큼 개발 초기부터 최종 예측을 시도하는 경우는 없다고 말한다. 그러면 우리가 주로 예측을 뽑아내는 시점은 언제일까? 일반적으로 요구사항 수집 단계 직전이나 도중이다. 문제를 제대로 파악하지도 못한 상황에서 무슨 재주로 제품 제작 기간을 예측한다는 말인가? 어쩌면 우리는애초에 절대로 믿지말아야할 예측값에 목매고 있는지도 모르겠다.

마치 정치판에 새롭게 뛰어든 인물이 왕따를 당하듯 다른 시스템 분야가 새로 등장한 소프트웨어 분야를 못살게 구는 듯 보인다. 실현 가능성이 없는 약속을 하도록 꼬드김에도 불구하고, 우리는 완전 초보이며 너무나도 무지한데다 그나마 배짱조차 없어서 맞서지도 못한다. 어쩌면 소프트웨어 예측 문제에 대한 진짜 대답은 점진적인 예측이며, 명확하게 정의한 중간 목표마다 새 예측값을 계산하고 모든 의사결정은 최초 예측이 아니라 최신 예측을 근거로 삼아야한다. 항상 상황을 완벽하게 장악하련는 관리자 입장에서는 통제력을 잃었다고 느낄지도 모르지만, 오늘날과 같은 현실에서 예측해야한다면 이런 완벽한 통제는 어차피 환상이 아니던가.

하지만 예측을 바꾸도록 허용한다면 기술진이 이를 오용하지 않겠느냐고 우려할지도 모르게싿. 이 질문과 관련하여 몇 가지 흥미로운 자료가 있다. 한 연구에 따르면 일정을 제약하지 않는 상태에서 소프트웨어를 개발하는 소프트웨어 개발자가 일정에 맞춰 소프트웨어를 만들어야하는 개발자보다 생산성이 더욱 높았으며, 여기서 누가 일정을 결정하든 (심지어 개발자 자신이 일정을 결정하는 경우에도) 마찬가지라고 한다. 일부 핵심 소프트웨어 개발자가 취하는 입장과도 동일한데, 사람들은 자기 업무를 자기가 통제할 때 가장 높은 생산성을 발휘한다. 생각해봐야할 문제이다.

p287

소프트웨어 분야에서 가장 큰 문제는 형편 없는 기술이 아니라 형편 없는 관리이다.

소위 ‘소프트웨어 위기'를 일으키는 요인 중 가장 큰 요인은 형편 없는 예측이다. 관리 측면에서 풀어야 할 문제를 놓고 우리는 기술적 해결책을 찾아 다닌다.