초보 개발자 시절엔 모든 코드를 자기가 생각하는 주요 비즈니스로직에 따라 작성한다. 사용자가 입력을 주면 파일에 쓰고, 검색어를 입력하면 검색을 수행한다.

여기서 조금 발전하면 코너 케이스를 보게 된다. 사용자의 입력이 버퍼 오버플로우를 일으킬 수 있다. 사용자의 입력이 엉뚱한 곳에 저장되어 시스템에 부정적인 영향을 줄 수 있다. 이런 점들을 깨달은 엔지니어는 이제 모든일에서 빼먹기 쉬운 유의사항을 쉽게 찾아낸다.

그리고 이런 깨닳음은 업무의 전반이나 일을 처리하는 방식에 영향을 준다. 데이터베이스 스키마가 준비되지 않아 UI 를 작성할 수 없다. 최종 사용자에게 줄 API 스펙이 준비되지 않아 복잡도가 높은 라이브러리의 리팩터링을 시작 할 수 없다.

그러나 생각해보자. UI 의 변경은 UI 변경 그 자체의 필요가 있어 시작된 것이고 데이터베이스가 미리 준비되지 않았다면 fake data 를 파일로 부터 읽어 UI에 그리는 작업을 사전에 진행할 수 있다. Presentation은 Data와 독립적인 것이다.

마찬가지로 라이브러리 내부의 복잡도 해결은 최종 사용자에게 어떤 API를 제공할 것인가와 독립적인 문제이다. 기능을 직교적으로 분할하여 재조합하기 쉽게 만드는 내부적인 clean up을 미리 하면 사용자가 쓰기쉬운 API가 정해졌을 때 내부의 기능을 조합해 쉽게 제공할 수 있다.

직교적으로 생각하는 것은 소프트웨어 엔지니어링에서 매우 중요하다. 무엇이 해결되야 다음을 할 수 있다던가, 무엇과 무엇이 같이 진행되야한다는 것들은 능숙하게 찾아낸 코너 케이스가 아니다. 가능성의 경우의 수를 제한하는 한정적 사고일 수 있다.

이런 이유로 초보 개발자는 코너 케이스와 의존성을 알지 못하고, 숙련된 개발자는 그들을 발견하며, 고도로 숙련된 개발자는 그 모든 것들을 직교적 기능으로 분할해 독립적인 단위로 만들어 낸다. 이것이 가능하면 일정이나 협력의 속도가 빨라진다.