software-history

4 posts

IBM의 Zero-Defect Process는 KLOC당 0.1개의 Bug를 달성했다. 업계는 그럼에도 불구하고 이를 포기했다.

IBM의 Cleanroom engineering은 업계 평균보다 100배 나은 defect rate를 달성한 뒤 사라졌다. 사라진 이유는 그것이 작동했는지와는 아무런 관련이 없었다.

IBM의 Cleanroom software engineering process는 천 줄당 0.1개의 defect를 달성했다. 당시 업계 평균은 10에서 50 사이였다. 이 process는 문서화되었고, 여러 프로젝트와 언어에 걸쳐 replicate되었으며, 독립적으로 검증되었다.…

Donald Knuth는 프로그램을 문학처럼 읽히길 원했다. 컴파일러는 다른 생각이 있었다.

Literate programming은 코드를 먼저 인간을 위해, 그 다음 기계를 위해 작성해야 한다고 약속했다. 40년이 지난 지금, 거의 아무도 그렇게 쓰지 않는다. 소프트웨어 문서화에서 가장 우아한 아이디어가 우리의 작업 방식을 바꾸지 못한 이유는 다음과 같다.

1984년, Donald Knuth는 급진적인 전환을 제안하는 논문을 발표했다. 프로그램은 컴파일러를 위해 작성되고 인간을 위해 주석을 다는 것이 아니라, 인간을 위한 문학으로 작성되어야 하며, 컴파일러는 그로부터 실행 가능한 부분을 추출해야 한다. 그는 이를 literate…

Fagan Inspections는 테스트 전 90%의 결함을 찾아냈다. 그리고 우리는 그것을 멈췄다.

IBM의 Michael Fagan이 개발한 구조화된 검토 프로세스는 코드가 컴파일러에 도달하기 전에 거의 모든 결함을 포착했다. 동시에 총 프로젝트 노력의 15~20%를 소비했다. 소프트웨어 역사상 가장 효과적인 리뷰 방법이 사라진 이유와 팀이 실제로 놓친 것은 무엇인지 알아본다.

1976년 Michael Fagan은 IBM Systems Journal에 한 편의 논문을 발표했다. 거기에 기술된 리뷰 프로세스는 소프트웨어 품질의 금기준(gold standard)이 될 정도로 효과적이었다. Fagan Inspections는 단 하나의 테스트도 실행되기 전에 전체…

NASA는 같은 프로그램을 27개 복사해 실행했다. 버그들은 한 묶음으로 투표했다.

N-version programming은 독립적인 팀이 독립적인 실수를 할 것이라 약속했다. 1986년 Knight와 Leveson의 실험은 정반대임을 입증했고, NASA는 조용히 물러섰다.

1980년대 초, NASA는 오늘날까지 안전 필수 엔지니어링을 괴롭히는 질문에 직면했다: 아직 발견하지 못한 버그를 어떻게 견딜 수 있는가? 그들의 답은 N-version programming이었다. 같은 명세를 세 개의 독립적인 팀에 주고, 세 프로그램을 병렬로 실행한 뒤, 출력에…