QSM: Volume 1.1: How Software is Built

Part 1. 품질의 패턴들 (Patterns of Quality)

Chapter 1: 품질이란 무엇인가? 그것이 왜 중요한가? (What Is Quality? Why Is It Important?)

Summary

1. 품질은 상대적이다. 한 사람에게 좋은 품질은 다른 사람에게 낮은 품질일 수도 있다. Quality is relative. What is quality to one person may even be lack of quality to another.

2. 상대성을 찾는 것은 "품질에 관한 그 진술의 뒤에 있는 그 사람이 누구냐"라고 물음으로써, 품질에 관한 진술의 암묵적인 사람이나 사람들을 탐지하는 것을 포함한다. Finding the relativity involves detecting the implicit person or persons in the statement about quality, by asking, "Who is the person behind that statement about quality."

3. 어떤 사람이나 사람들에게 있어서 품질은 가치보다 크거나 작지 않다. 이러한 견해는 "결함을 0으로 하는 것이 고품질이다.", "기능이 많은 것이 고품질이다.", "우수한 코딩이 고품질이다.", "고성능이 고품질이다.", "적은 개발 비용이 고품질이다.", "쾌속 개발이 고품질이다.", "사용자 친화성이 고품질이다."와 같은 문구를 조화시킬 수 있게 한다. 모든 진술이 동시에 사실일 수 있다. Quality is neither more nor less than value to some person or persons. This view allows us to reconcile such statements as,"Zero defects is high quality." , "Lots of features is high quality." , "Elegant coding is high quality." , "High performance is high quality." , "Low development cost is high quality." , "Rapid development is high quality." , "User-friendliness is high quality." All of the statements can be true at the same time.

4. 품질은 거의 항상 정치적/감정적인 문제지만, 우리는 합리적으로 해결될 수 있는 것처럼 행동하기를 좋아한다. Quality is almost always a political/emotional issue, though we like to pretend it can be settled rationally.

5. 품질은 오류로부터의 자유와 동일하지 않다. 일부 사용자들은 공식적인 요구 조건에도 부합하지 않는 소프트웨어 제품을 높은 품질로 간주할 수 있다. Quality is not identical with freedom from errors. A software product that does not even conform to its formal requirements could be considered of high quality by some of its users.

6. 조직들이 일을 하는 특정한 패턴을 고수하는 경향이 있기 때문에 품질을 향상시키는 것은 매우 어렵다. 그들은 현재의 수준의 품질에 적응하고, 새로운 수준으로 변화하는데 무엇이 필요한지 알지 못하며, 실제로 알아내려고 노력하지 않는다. Improving quality is so difficult because organizations tend to lock on to a specific pattern of doing things. They adapt to the present level of quality, they don't know what is needed to change to new level, and they don't really try to find out.

7. 소프트웨어 조직에서 채택한 패턴은 몇 개의 클러스터, 즉 하위문화에 속하는 경향이 있는데, 각각은 그 특징적인 결과를 낳는다. The patterns adopted by software organizations tend to fall into a few clusters, or subcultures, each of which produces characteristic results.

8. 문화는 본질적으로 보수적이다. 이 보수주의는 주로 다음과 같은 것들에 나타나 있다 Cultures are inherently conservative. This conservatism is manifested primarily in

   1. 특정 수준의 품질에 대한 만족도 the satisfaction with a particular level of quality

   2. 훨씬 더 잘하려고 하는 시도로 그 수준을 잃는 것에 대한 두려움 the fear of losing that level in an attempt to do even better

   3. 타문화에 대한 이해 부족 the lack of understanding of other cultures

   4. 그들 자신의 문화의 투명성 the invisibility of their own culture

Chapter 2. 소프트웨어 하위 문화들 (Software Subcultures)

Summary

1. PhilipCrosby의 "품질은 공짜다" 아이디어는 아마도 몇 가지 손보면 소프트웨어에 적용될 수 있다. Philip Crosby's "Quality is Free" ideas can be applied to software, though perhaps with several modifications.

2. 소프트웨어에서, 요구사항을 준수하는 것은 제조 작업에서처럼 요구사항이 확실할 수 없기 때문에 품질을 정의하기에 충분하지 않다. In software, conformance to requirements is not enough to define quality, because requirements cannot be as certain as in a manufacturing operation.

3. 소프트웨어에 대한 우리의 경험에 따르면 "결함 0"은 대부분의 프로젝트에서 현실적이지 않다. 왜냐하면 마지막 몇 가지 결함에 대한 가치가 감소하기 때문이다. 더욱이 다른 결점이 줄어들면 지배하는 경향이 있는 요구사항 결점이 있다. Our experience with software tells us that "zero defects" is not realistic in most projects, because there is diminishing value for the last few defects. Moreover, there are requirements defects that tend to dominate once the other defects are diminished.

4. 크로스비의 주장과는 달리, 소프트웨어에서는 "품질의 경제학"이 있다. 가치로 정당화되지 않은 완벽에 대한 심리적 욕구가 없는 한 우리는 완벽을 추구하는 것이 아니라 가치를 찾는 것이다. Contrary to Crosby's claim, there is an "economics of quality" for software. We are not searching for perfection, but for value, unless we have a psychological need for perfection not justified by value.

5. 어떠한 소프트웨어 문화 패턴도 올바른 고객으로 볼 때 성공적일 수 있다. Any software cultural pattern can be a success, given the right customer.

6. "성숙도"는 추론할 수 없는 우월성을 내포하고 있기 때문에 하위문화 패턴에 대한 올바른 단어가 아니다. "Maturity" is not the right word for sub-cultural patterns, because it implies superiority where none can be inferred.

7. 우리는 최소 6가지 소프트웨어 하위 문화 패턴을 확인할 수 있다: We can identify at least six software sub-cultural patterns:

   • 패턴0: 무의식 Pattern 0: oblivious

   • 패턴1: 가변적 Pattern 1: variable

   • 패턴2: 루틴 (그러나 불안정) Pattern 2: routine (but unstable)

   • 패턴3: 조정하는 Pattern 3: steering

   • 패턴4: 예상하는 Pattern 4: anticipating

   • 패턴5: 일치적인 Pattern 5: congruent

8. 거의 모든 소프트웨어 조직이 다른 패턴에서 발견되기 때문에 패턴 4,5에 대한 관찰은 거의 존재하지 않는다. Hardly any observations exist on Patterns 4 and 5, as almost all software organizations are found in other patterns.

9. 이 책에서 우리는 주로 패턴 1~3, 즉 어떻게 하면 만족스러운 패턴을 유지하거나 더 만족스러운 패턴으로 이동할 수 있는지에 대해 관심을 가져야 한다. In this book, we shall be concerned primarily with Patterns 1-3—how to hold onto a satisfactory pattern or move to a more satisfactory one.

Chapter 3. 패턴을 변화시키기 위해서는 무엇이 필요한가? (What Is Needed To Change Patterns?)

Summary

1. Each pattern has its characteristic way of thinking and communicating.
2. The first essential to changing a pattern is changing thought patterns that are characteristic of that pattern.
3. Thinking patterns consist of models, and new models can be used to change thinking patterns
4. In the less stable patterns, models need not be precise, but merely convincing. Indeed, precise models wouldn't make any sense without first establishing stability.
5. Models help us to:
   • discover differences in thinking, before they have big consequences
   • work on ideas together, to facilitate team-building
   • understand the reasons for various project practices
   • record communication so newcomers can get productive much faster
   • maintain a record we can use to improve our processes for the next time
   • be creative, because projects will never be routine.
6. Before you set about choosing a better pattern, you should always ask, "Is our present pattern good enough?"
7. The pattern you choose depends on a tradeoff among organizational demands, customer demands, and problem demands. These tradeoffs can be represented by choosing a point in "pattern space."
8. There is always a temptation for a software organization to stagnate by not choosing a new pattern, but instead reducing customer demands or problem demands.
9. The process of recognizing that a new pattern is needed is hindered by circular arguments that close the organization to the information it needs.
10. The key to opening closed circles is the question, "Is your rate of success okay?" Closed circles, however, tend to prevent this question from being asked.
11. Lack of trust tends to keep this key question from being answered truthfully, so organizational change often begins with actions for developing trust.

Part II. 관리의 패턴들 (Patterns Of Managing)

Chapter 4: 관리를 위한 제어 패턴들 (Control Patterns for Management)

Summary

1. The Aggregate Control Model tells us that if we're willing to spend enough on redundant solutions, we'll eventually get the system we want. Sometimes this is the most practical way, or the only way we can think of.
2. The Feedback Control Model tries for a more efficient way of getting what we want. A controller controls a system based on information about what the system is currently doing. Comparing this information with what is planned for the system, the controller takes actions designed to bring the system's behavior closer to plan.
3. The job of Engineering Management is to act as controller in engineering projects. Failures of engineering management can be understood in terms of the Feedback Control Model. Pattern 2 managers often lack this understanding, which often explains why they experience so many low quality, or failed, projects.
4. Projects can fail when there is no plan for what should happen.
5. Projects can fail when the controller fails to observe what significant things are really happening.
6. Projects can fail when the controller fails to compare the observed with the planned.
7. Projects can fail when the controller cannot or will not take action to bring actual closer to planned.

Chapter 5 명시적인 관리 모델들 만들기 (Making Explicit Management Models)

Summary

1. Every manager and programmer has models of how things work in their software pattern, though many models are implicit in their behavior, rather than stated explicitly. Things go awry in software projects because people are unable to face reality and because they use incorrect system models.
2. Linear models are attractive because of additivity. Linear systems are easier to model, easier to predict, and easier to control. Managers often commit scaling fallacies because linear models are so attractive.
3. The diagram of effects is a tool for helping model system dynamics to reveal non-linearities. Being a two-dimensional picture, it is more suited than verbal descriptions to the job of describing non-linear systems.
4. One way of developing a diagram of effects is to start with the output—the variable whose behavior you wish to control. You then brainstorm and chart backwards effects from that variable—other variables that could affect it. From these, you chart backwards again, unveiling secondary effects, which you can trace through the primary effects to the variable of interest. You may want to explicitly indicate multiplicative effects because of their importance.
5. Non-linearity is the reason things go awry, so searching for non-linearity is a major task of system modeling.

Chapter 6: 피드백 효과 (Feedback Effects)

Summary

1. The Humpty Dumpty Syndrome explains one reason why project managers are unable to be courteously stubborn to their mangers, and what happens as a result.
2. Projects run away—explode or collapse—because managers believe two fallacies: The Reversible Fallacy (that actions can always be undone) and The Causation Fallacy (that every cause has one effect, and you can tell which is cause and which is effect.)
3. One reason management action contributes to runaway is the tendency to respond too late to deviations, which then forces management to big actions which themselves have non-linear consequences. That's why it's necessary to "act early; act small."
4. The effect of Brooks's Law can be made worse by management action. Moreover, the same pattern of management action can lead to a Generalized Brooks's Law, which shows how management action is often the leading cause of project collapse.
5. One reason management action contributes to runaway is the tendency to respond too late to deviations, which then forces management to big actions which themselves have non-linear consequences. That's why it's necessary to "act early; act small."
6. Negative feedback is the only mechanism that has the speed and power to prevent runaway due to positive feedback loops in a system. The Pattern 3 controller has two major negative feedback loops with which to exercise control—one involving resources and one involving requirements.

Chapter 7: 소프트웨어 조정하기 (Steering Software)

Summary

1. Many otherwise good ideal methodologies fail to help prevent collapse because they don't prescribe negative feedback actions to be taken when the project deviates from the ideal model.
2. When the methodologies do prescribe feedback, they often speak only of the product level, or feedback steps that are too large. To be effective for control, feedback must operate in small increments, at all levels, personal, product, process, and cultural.
3. Software professionals often overlook the human decision point in models of effects. One reason is their inability to visualize certain states at all, often because they are "other outputs" of the process, and not directly connected with the product.
4. To control a project successfully, you have to learn that you need not be a victim of the dynamics. When human decision points are involved, it's not the event that counts, it's your reaction to the event.

Chapter 8: 조정에 실패하기 (Failing to Steer)

Summary

1. Many project managers fail to steer well because they believe they are victims, with no control over the destiny of their project. You can easily identify these managers by their use of "victim language."
2. Brooks's Law doesn't have to be a victim law if the manager recognizes where the managerial control is, and that this control can take different forms.
3. A common dynamic is punishing the messenger who brings accurate but bad news about project progress. This intervention avoids "negative talk," but also diminishes the chance of the manager's making effective interventions needed to keep a project on the road.
4. Since the time of the Greeks, people have not only gotten their interventions wrong, they've gotten them backwards. Laying out a clear diagram of effects can help you sort out a situation in which two parties are driving each other to destruction, all the while thinking they are helping the situation.

Part III. Demands That Stress Patterns

Chapter 9: 왜 조정하는 것은 항상 어려운가 (Why It's Always Hard to Steer)

Summary

1. Human intervention dynamics are those over which we potentially have control, but there is always a set of "natural" dynamics which put a limit on how good a job any controller can do. A large part of the controller's job is devising intervention dynamics that can keep the natural dynamics under the best control possible, which can never be perfect.
2. The Square Law of Computation says that computational complexity grows non-linearly as the number of factors in the computation grows.
3. Control can be thought of as a game that the controller plays against "Nature." Even games of "perfect information," such as Tic-Tac-Toe and Chess, require non-linear increases in brainpower to play perfectly as the size of the "board" increases.
4. Simplification is always needed, because controllers are always playing a "game" well outside their mental capacity. Simplification takes the form of rough dynamic models and approximate rules such as "Always break a project down into modules."
5. Software engineering management is harder than Chess, because controlling a project is a game of "imperfect information," and the size of the "board" is not fixed.
6. The Size/Complexity Dynamic appears in many forms throughout software engineering, forms such as the Fault Location Dynamic and the Group Interaction Dynamic.

Chapter 10: What It Takes To Be Helpful

Summary

1. Our brains will never be big enough for our ambitions, so we'll always need thinking tools, such as size/effort graphs.
2. Size/effort graphs can be used to reason about the Size/Complexity Dynamic, such as when estimating a project or comparing the impact of two different technologies. Graphs, however—such as log-log graphs—can also distort or conceal the non-linear nature of the dynamic. We must learn to see the stable meaning through the variations in the data and the method of presentation.
3. Because of the Size/Complexity Dynamic, it's easy to write requirements that the most competent programmers cannot satisfy.
4. A single method or tool is seldom the best over the entire range of problem sizes. Size/effort graphs can help managers combine two methods into a composite pattern that adopts the best range for each one.
5. "The bottom line" doesn't dictate all technology choices. Managers are often willing to pay a lot on the bottom line to reduce the risk of failure. The size/risk graph can help in reasoning about these choices, especially when used in conjunction with the size/effort graph.
6. If you set out to change an organization, the first rule should be the one given to physicians by Hippocrates" "Do no harm."
7. We are all subject to the Size/Complexity Dynamic, so interactions intended to be helpful often wind up being irrelevant, or actually destructive. It's a good idea to assume that regardless of how it looks or sounds, everyone is trying to be helpful.
8. We can help most when we apply the The Principle of Addition to add more effective models to a person's repertoire.

Chapter 11: 고객 요청에 대한 응답들 (Responses to Customer Demands)

Summary

1. The relationship with customers is the second important factor driving organizations to particular software cultural patterns.
2. Simply increasing the number of customers can wreak vast changes on an organization, such as
   • increasing the development load
   • increasing the maintenance load
   • disrupting the pattern of development work
3. On the other hand, a software development organization can be extremely disruptive to its customers. That's why customers try to be controllers of the software development organization, leading to a situation of multiple controllers. The more controllers, the more "randomness" there appears to the other controllers.
4. The cast of outsiders who may influence software development is enormous, including such roles as
   • customers and users
   • the marketing department
   • other surrogates
   • programmers as self-appointed user surrogates
   • testers as official and unofficial surrogates
   • other unplanned surrogates
5. Many of these outsider roles are planned as attempts to reduce the effective number of customers.
6. Because some of the surrogates are much more intimate with the development system, they may negate their reduction of the effective number of customers with the force and frequency of their interactions.
7. Interactions with customers are fraught with peril as the number of customers grows. Interruptions increase. Meetings increase in size and frequency. Time lost because of interrupted meetings increases. All of these increases are non-linear.
8. With more customers comes more configurations to support. More configurations means additional coding, more complex testing, less effective test coverage, and longer repair times.
9. Releases are needed whenever there are multiple customers. As soon as a product is released to customers, it assumes an entirely different dynamic than when it was held in the shadow of the development organization.
10. Multiple versions of a software product complicate maintenance enormously, but more customers means more versions, whether official or unofficial. Frequent releases complicate the development/maintenance process, but so do infrequent releases, so that almost all software cultures tend to stabilize releases at around two per year.