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

How Software Is Built

Chapter 3. What Is Needed To Change Patterns? 

3.1.1 Thought and communication in various patterns

Oblivious. Individualism is the key. Variable. Emotion and mysticism drive everything. People don't use words in consistent way. This works under the most current sources… I've fixed several bugs and made a lot of changes in the application code since this release, so I believe that these fixed the bug. Translated into precise language, this means I did a lot of big magic, so I drove the devil away. To see these thought patterns in action, watch how problems are handled. Everything is reactive and individual, with half-cocked solutions based on poor problem definitions. There's lots of heat, but not much light.

Obilivious, Variable는 조직의 첫번째 레벨에서 발견되는 요소다. + 개인 단위로 일하고 + 신비주의로 만들고 + 같은 의미를 다른 단어로 이야기하고 + 잘못된 문제 정의로 인해 반쪽짜리 솔루션을 만들고 + 릴리즈 후엔 버그를 고치느라, 계속 코드가 수정된다.

3.1.1 Thought and communication in various patterns

In Pattern 2, there is an unjustifiable certainty about what is known. For instance, managers don't know who the 20:1 programmers are, but they think they know. Another key thought pattern is linear reasoning—A caused B. This "single cause, single effect" logic works fairly well as long as things stay routine. Such oversimplified reasoning, however, frequently produces conclusions that are actually contrary to fact. Usually, this happens when something extraordinary arises, such as a project running late. Problem-solving is not much better than in Pattern 1. More people may be ordered to tackle major problems, so statistics may provide a better chance of reasonable solutions. Only short-term solutions are attempted, however, and these often have reverse long-term effects.

패턴 2는 잘못된 확실성을 갖고 있다.

예를 들면, 이 문제는 이 것 때문에 발생했어! 라고 간단하게 결론짓는거다.

이러한 추론은 간단하지만, 실제와는 반대되는 결론이 대부분이다.

보통 프로젝트가 지연되는 이유처럼 특별한 이슈가 생길 때 이런 일반화가 나타난다. 패턴2가 패턴1보다 더 낫다고 볼 수도 없다. 복합적인 문제의 원인을 찾아서 해결하기 보단, 대다수의 사람들이 자기가 맡은 일들을 해결하는게 더 많은 일들을 처리할 수 있을것처럼 보인다. 그런데 단기적인 문제 해결은 장기적으로 역효과를 낼 수 있다.

3.3.4 Developing trust

Moving to more open levels depends on creating the sub-systems that you can trust. Why does trust work? The ability to trust sub-systems reduces the amount of communication needed to get the job done, because the amount of "checking up" is reduced. Because trust reduces the need for data, increasing data flow is characteristic of a development system in trouble. Such a system lacks the information capacity to handle anything but the current crisis:

정보의 개방성을 높이려면, 서로 신뢰할 수 있는 시스템이 필요하다. 그렇지 않으면, 정보의 개방성을 높이기 위한 단계가 성과 / 처벌 등에 악용될 수 있기 때문이다. 보통 문제가 발생하는 시스템은 정보를 얻기 위한 절차가 많다. 그런데 개방성이 높아지면 정보를 얻기 위한 니즈가 줄어든다. 그냥 찾아보거나, 이미 알고있을테니까. 이렇게 정보의 개방성이 높아지면, 일을 완료하는 데에 필요한 커뮤니케이션 비용도 줄어든다.