• 모든 소프트웨어 시스템은 이해 관계자에게 '행위(behavior)', '구조(structure)', 서로 다른 두 가지 가치를 제공
• 대체로 개발자가 둘 중 덜 중요한 가치에 집중하여 소프트웨어 시스템이 쓸모없게 된다

행위

• 소프트웨어의 첫 번째 가치는 바로 '행위(behavior)'
• 많은 프로그래머가 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다

아키텍처

• 소프트웨어의 두 번째 가치는 '소프트웨어(software)'라는 단어와 관련이 있다
• 소프트웨어는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서 '부드러움을 지니도록' 만들어졌다
• 소프트웨어는 변경하기 쉬어야 한다.
• 변경사항을 적용하는 데 드는 어려움은 변경되는 '범위(scope)'에 비례하며, 그 '형태(shape)'와는 관련이 없어야 한다
• 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다
• 새로운 요청 사항이 발생할 때마다 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다
• 문제는 당연히 시스템의 아키텍처. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할 수록, 새로운 기능을 이 구조에 맞추는 게 더 힘들어진다
• 아키텍처는 형태에 독립적이어야하고, 그럴 수록 더 실용적

더 높은 가치

• 기능 or 아키텍처?

  양 극닥단의 사례를 검토

  
  - 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 요구 사항이 변경 될 때
  동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다. 이러한 프로그램은 거의
  쓸모 X
  
  - 동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수
  있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 이러한 프로그램은
  앞으로도 계속 유용한 채로 남는다
  
  변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우. 기능 또는 설정 측면에서 많은 시스템이
  이처럼 수정이 현실적으로 불가능해지는 상황에 빠지게 된다
  

아이젠하워 매트릭스

• 그림 2.1 아이젠하워 매트릭스
• 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없다
  1. 소프트웨어 첫 번째 가치인 '행위'는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다
  2. 소프트웨어 두 번째 가치인 '아키텍처'는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다
• 긴급하지도 않고, 중요하지 조차 않은 일도 있다. 최종적으로 이들 네 가지 경우에 다음과 같은 우선순위 존재
  1. 긴급하고 중요한
  2. 긴급하지는 않지만 중요한
  3. 긴급하지만 중요하지 않은
  4. 긴급하지도 중요하지도 않은