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

How Software Is Built

Preface

1. the ability to observe what’s happening and to understand the significance of your observations

2. the ability to act congruently in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide 

3. the ability to understand complex situations so you can plan a project and then observe and act so as to keep the project going according to plan, or modify the plan.

제럴드 와인버그는 위의 3가지 기본 능력이 필요하다고 했다. 

- 무슨 일이 벌어지고 있는지 관찰하고, 이해하는 능력

- 멘붕을 겪어서 숨고 싶고, 도망칠 수도 있지만, 어려운 대인관계 속에서 일관성 있게 행동하는 능력

- 복잡하게 얽혀있는 상황 속에서 프로젝트를 계획하고, 이걸 수정해낼 수 있는 능력 

1.2 The Relativity of Quality 

what is adequate quality to one person may be inadequate quality to another.

1.2.2 Who was that masked man? 

Every statement about quality is a statement about some person(s).

a. "Zero defects is high quality.

b. "Lots of features is high quality.

...

e. "Low development cost is high quality.

f. "Rapid development is high quality.

g. "User-friendliness is high quality.

누군가에게는 적합한 품질이, 누군가에게는 적합하지 않다. 

품질에 대한 정의는 품질을 정의하는 사람의 입장과 상황에 따라 달라진다.

시스템 엔지니어는 응답속도가 빠르고, 리소스를 적게쓰고, 비용이 적게 드는 소프트웨어를 품질좋은 소프트웨어라고 정의할 수 있다.

반면, 디자이너와 기획자는 사용자 친화적인 소프트웨어가 품질좋은 소프트웨어라고 여길 수 있다.

난 빠른 개발 속도, 많은 기능, 사용자 친화성 등도 품질의 하나라고 생각하지 못했었다. 

확장 가능하고, 안정적인 소프트웨어가 품질좋은 소프트웨어라고 생각했었다.

입장과 역할에 따라 품질에 대한 정의가 달라진다. 모두 자신의 지향하는 품질을 지키기위해 갈등을 겪었던거 같다. 

1.5. Why Improving Quality Is So Difficult 

1.5.1. It's not too bad.

a. People are using their product, and are happy with it, so it is "good quality."

b. All software does have bugs. At least we can't prove otherwise. 

c. People buy it over the competition, so it must be better, in their opinion.

Under the circumstances, there's very little motivation to improve the quality unless pushed from outside. If people stop using their product, or buying it, then the developers might decide to "improve quality," but by then it will probably be too late. 

'이 정도면 괜찮지~~ 버그 없는 소프트웨어가 어딨어 ~_~. 사용자들이 제품을 잘 쓰고있잖아~~' 라고 피드백이 오는 상황에서는 외부의 압박없이는 품질을 개선하고 싶다는 동기부여가 생기지 않는다. 

그런데 사람들이 제품을 사용하지 않게 되서, 품질을 개선해야겠다고 마음먹게 되는 상황이 되면, 이 때는 이미 너무 늦다. 

1.5.3. The lock-on 

A locked-on system tends to hold itself to an existing pattern, even against "logical" reasons to change.

An excellent example of a lock-on is the choice of a standard programming language. Once an organization is using a single programming language—for whatever historical reasons—the cost of changing increases, the motivation to study the value of other alternatives decreases, and the knowledge of how to obtain those alternatives disappears. As a result, the organization "locks on" to the language, just as a country locks on to the side of the road used for driving.

사람들은 다른 대안이 더 합리적이여도, 익숙한 기존의 패턴을 사용하는 경향이 있다. 

가장 익숙한 예시로는 프로그래밍 언어를 선택할때다. 변화에 대응하기 어려운 언어이지만, 원래 쓰던 언어들을 계속 사용하게 되는 경우가 locked-on system에 빠진 케이스가 아닐까 싶다. 

locked-on system에 빠지게 되면 새로운 언어를 배워야하는 동기도 없어지고, 이로 인해서 학습할 수 있는 기회도 없어지게 된다.

그런데 이런 상황에서 언어를 하나 변경하려면, 설득하고, 합의해야하는 요소들이 굉장히 많다. 

아무튼 이런식으로 변화에 대한 시도는 여러 저항들을 만나게 되서, 변화를 실천하기가 어렵다. 

People will always choose the familia0r over the comfortable.

사람들은 유용하고, 편한것 보다는 익숙한 걸 선택한다. 

Because of the conservative nature of culture, attempts to change are always met with "resistance." You will be better able to cope with such "resistance" if you recognize it as attempts to preserve what is good about the old way of doing things. Even better will be to begin a change project by acknowledging the value of the old way, and determining which characteristics you wish to preserve, even though changing the cultural pattern.

변화를 만드는건 항상 저항이 있을 수 밖에 없다. 그런데 기존 시스템이 왜 이렇게 만들어졌는지 배경을 이해하고, 장점을 유지하려고 하면 이 저항을 잘 해소하는 데에 도움이 된다.