코딩을 하다보면, 기획자가 넘겨준 구조를 그대로 코딩하면 구조가 쓸데없이 복잡해지지만, 어떤 개념의 정의를 사소하게 수정해서 복잡도를 크게 줄일 수 있는 경우가 있다.
그렇기에, 아무리 철저한 기획이라도, 프로그래머 레벨에서 직접 결정해야할 사소하면서도 기획의 영역에 걸쳐있는 일들이 있다.
그런데 프로그래머가 기획자가 통제권에 지나치게 집착한다고 느끼면, 자기도 이해하지 못한 사이에, 기획자가 의도한 구조를 파괴할 수도 있다는 두려움을 느낄 수 있다.
따라서 불만족스러운 소프트웨어 상태를 납득못해도 그 부분을 건드리지 않는 선택을 하게된다. 덕분에 기획이 갈수록 발전하는 것 같은데 소프트웨어의 전체 모습은 오히려 망가지게 된다.
그래서 기획자는 기획서에 겉모습보다는 겉모습이 의도한 문맥을 충분히 시간을 들여 첨부해야한다. 문맥은 가장 중요하며, 프로그래머는 자의적으로 기획자가 시간을 들여 설명한 문맥을 파괴되면 안된다.
대신, 문맥을 더욱 견고하게 유지할 수 있다면, 기획자는 프로그래머에게, 기획서가 처음 제시한 형태의 구조를 파괴해도 된다는 믿음을 줘야 한다.
그리고 프로그래머는 기획서가 처음 제시한 형태를 더욱 간결하게 변형시키는 행위를 받아들여야 한다. 실행함으로써 일어날 갈등을 미리 무서워하면 안된다.
마지막으로, 통제권에 집착하는 기획자가 나쁘다고 단순하게 생각해서는 안된다. 기획자는 의견을 받을 준비가 되어있으나, 오히려 자신이 용기있게 바꿀 필요가 있는 것을 말하지 않은 것일지도 모른다.