제럴드 와인버그 <Quality Software Book : How Software Is Built > - 2장 요약

How Software Is Built

Chapter 2. Software Subcultures

Quality is value to some person(s). Requirements are not an end in themselves, but a means to an end—the end of providing value to some person(s). ... In software work, however, we cannot assume this ideal situation, so much of the development process is concerned with more closely approaching the "true" requirements. Therefore, much of what we need to understand about quality software management concerns this parallel development of requirements and software.

요구사항은 목적이 아니라 수단이다. 소프트웨어 품질은 요구사항과 소프트웨어를 개발하는 것과 관련있다. 개발 프로세스는 진정한 요구사항에 가까워지는거다.

Thus, for the foreseeable future, most of us will have to manage software development in a "dirty" environment, where requirements cannot be assumed correct. To ignore this reality would be to play the ostrich, not the quality software manager

소프트웨어 개발 환경에서는 정확한 요구사항을 예측하기 어렵다. 그래서 이걸 인정해야한다. 그렇지 않으면, 현실도피주의자가 될거다.

However, when the customers' values are not known, and even worse when the customers are not known, then we don't know what the "things" are. We may produce things right, but discover that they are not the right things. That's why the requirements process can produce or destroy value, and that's why there's an economics of quality, in any software project that includes a requirements process.

처음부터 잘 만들어두는게 경제적이란 이야기가 있지만, 고객이 누군지도 모르거나, 고객을 위한 가치가 뭔지 모를 때는 사실 이런게 불가능하다. 요구사항 분석에 따라 가치가 달라질 수 있어서 개발 프로세스 안에 요구사항 분석을 포함해서 생각해야한다.

Quality is the ability to consistently get what people need. That means producing what people will value and not producing what people won't value. Don't use a sledge-hammer to crack a peanut. Don't use a nut-cracker to break up a wall. Choose the pattern that will give you the quality/cost you need and work within that pattern to do it consistently.

땅콩을 깨는데 해머를 쓰지말라. 벽을 부수는데 호두까기 인형을 쓰지말라

The quest for unjustified perfection is not mature, but infantile. .. if your goal is changing an organization, start by dropping the comparisons, such as implied in the loaded term "maturity."

완벽한 품질에 대한 논의는 성숙하지 않고, 유치하다.

드라마 실리콘밸리에서 주인공 리처드가 인덴트를 할 때, 스페이스가 아니라 탭을 쓰는게 더 맞다고 우기다가, 여자친구랑 헤어지는 장면이 생각난다.

소프트웨어를 개발할 때, 완벽을 추구하다보면 현 상황에 맞지않는 기술 스택과 아키텍처를 선택하게 되는 경우가 종종 있는 것 같다. 그리고 완벽을 이야기하다보니 의사결정도 더뎌지는 경우도 있는 것 같다. 그래서 현재 제품 규모에 맞는 수준의 품질을 지향하는게 필요한 것 같다.

Like all the patterns, this one is often successful. I commonly find this pattern in young companies producing software products for microcomputers.

At the slightest provocation, any member of the organization will relate an elaborate "creation myth" about the heroic feats of the founding team. Often, as the new company grows, it evolves to Pattern 2, but retains the myths of Pattern 1. These myths have great value in recruiting new programmers. ... The ideal development structure in Pattern 1 is "the star in the closet." If the project is patently too large for one star, then the ideal is the "skunkworks." ... In Pattern 1, purchasing a "star" is the only hope the organization has of improving quality.

이 책에서는 소프트웨어 개발 문화에서 발견되는 몇가지 패턴에 대해서 이야기한다. 그 중 패턴 1은 슈퍼 개발자가 큰 영향력을 발휘하는 개발문화다. 

패턴 1은 영웅적인 슈퍼 개발자와 이를 서포트하는 팀원으로 구성된 팀은 젊은 회사에서 종종 발견된다.

이런 신화 속에서는 새로운 프로그래머를 뽑는 데에 엄청 중요하게 생각한다. 이런 슈퍼 개발자가 혼자서 만들기에 버거운 프로젝트인 경우, 작은 실험실처럼 만들어서 운영하는게 이상적이다. 그래서 이러한 조직에서는 또다른 슈퍼 개발자가 등장해서, 품질을 높여주길 바란다.

Humphrey says that the first step in statistical control is to achieve rudimentary predictability of schedules and costs. Since performance in Pattern 1 depends almost totally on individual efforts, the variability in schedules and costs depends almost totally on the variability in individuals.

...

In Pattern 1, the best predictor of project schedule, cost, or quality is which programmer does the job, thus reinforcing the belief system characteristic of this pattern. The programmer gets all the credit, as well as all the blame.

품질을 통계적으로 관리하는 첫번째 단계는 일정/비용 예측이다.

패턴1에서는 슈퍼개발자의 일정에 의존성이 크다. 그래서 리스크가 더 커진다.

패턴 1에서 슈퍼 개발자은 많은 신뢰를 받지만, 잘 안되는 경우 비난의 대상이 되기도 한다.