소프트웨어 시스템은 행위(behavior)와 구조(structure)라는 서로 다른 두 가지 가치를 제공한다. 소프트웨어는 기능 동작으로 수익 창출과 같은 직접적 가치를 제공해야하며 변경하기 쉬운 부드러운 “소프트웨어"적 추상적 가치를 제공해야 한다.
부드러운 소프트웨어
변경사항을 적용하는데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
시스템의 형태와 요구사항의 형태가 서로 맞지 않는다면, 이해관계자는 범위가 비슷한 일련의 변경사항을 제시할 뿐이지만, 개발자 입장에서는 복잡도가 지속적으로 증가하는 퍼즐 판 위에서 이해관계자가 계속해서 퍼즐 조각을 맞추라는 지시를 하는 것처럼 느껴진다. 흔히 소프트웨어 개발자는 사각형 마개를 동그란 구멍에 밀어 넣도록 강요받는 느낌을 받게 된다.
아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치
소프트웨어 시스템이 동작하도록 만드는 것이 더 중요한가? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?
아이젠하워 매트릭스에 의하면, 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없다고 한다.
가치에 대한 우선순위를 두자면,
우리가 흔히 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이다. 즉, 긴급하지만 중요하지 않은 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못한다.
보통 업무관리자는 긴급한 업무를 우선 시 하는데, 개발자는 관점이 달라야 한다. 개발자는 중요한 업무를 위해 싸우고 투쟁해야 한다.