소프트웨어가 망하는 과정, 아키텍트 VS 구현자들

기획자는 자신이 설계한 아키텍트에 대해 매료되며 그것을 요람처럼 받드는 경향이 있다. 이것은 그 기획자가 개성과 창의성을 유지하는데 있어서는 필요한 덕목이다.

하지만, 그 아키텍트의 결함과 논리적 모순을 찾아내는 것은 언제나 구현자들이다. 왜냐하면 대부분의 아키텍트는 구현영역의 아주 간단한 기초지식 조차 없이 설계하는 경우가 많기 때문이다. 대부분의 소프트웨어 기획자들은 모니터 화면에 점 하나가 어떻게 찍히는지조차 모르며, 또 그것을 그다지 부끄럽게 여기지도 않는다. 따라서 구현자들은 그 기획을 실행하거나, 그 이전 단계에 이르러서야 문제를 찾아낸다.

구현자가 그러한 결함이나 모순을 지적하면, 아름다운 아키텍트에 대한 부정행위를 곧 신성모독으로 인식하며, 해당 엔지니어는 무능한 엔지니어라는 오명을 쓰게 된다. 대화가 통하지 않는다는 사실을 알게된 구현자는 어떻게든 그 문제를 자기선에서 처리한다. 이 때, 제품의 형상은 1차적으로 기획의도를 벗어나게 되고, 더 이상 구현자들은 아키텍트를 따르지 않으며, 직속상관만을 따르기 시작한다.

가령, 기획자가 실내에서도 위치 서비스가 가능하다면, 대형 마트에서 물건을 찾아서 바로 카트에 실을 수 있어 유용할 것이라는 아이디어를 낸다. 그리고, 엔지니어들에게, 마트 내부에 모의 GPS위성을 설치하여, 위치를 특정할 수 있는 솔루션을 개발하라고 한다.

그러나 엔지니어들이 조사한 결과에 따르면, GPS는 최소 3대이상의 위치가 알려진 정지점에서 각각의 거리값을 이용해, 3개의 구가 만나는 교점을 계산하는 방식이란 것을 알게된다. 마트의 내부엔 어마어마하게 많은 양의 장해물이 있기 때문에, 산란전파로 인해, 방정식이 흩트러져 그것을 계산하는 것이 어렵다는 사실상 불가능하다고 보고한다. 기획자는 GPS의 작동원리를 제대로 이해하려는 시도를 하지 않고, 차량도 건물들이 복잡하게 늘어서 있어도 GPS가 작동된다는 점을 예를 들어, 순전히 자신의 직관에 기초하여 반박한다. 우주의 인공위성은 충분히 멀리 떨어져 있기 때문에 오차가 무시할만한 수준이지만, 실내에서 그렇지 않다는 사실을, 수학자나 물리학자가 아닌 소프트웨어 엔지니어가 정확히 말할 수 있을리 없으므로, 엔지니어는 논쟁에서 패배하게 된다. 대부분의 엔지니어는 훌륭한 정치가가 아니다.

엔지니어들은 무선 AP그리드라던지 다른 대안들을 검토하여, 그것을 어떻게든 구현해낸다. 이때 사실 수학자나 물리학자들의 도움이 필요하지만, 예산문제로 철회되어 엔지니어들이 도메인 문제를 스스로 푼다. 

디자인이 반영될 시점, 기획자는 디자이너를 싸게 시간제로 고용하여 작업한다. 얼결에 프로젝트 마지막에 투입된 디자이너는, 시스템의 개요나 컨셉에 대한 아이디어가 없으므로, 추상성이 매우 떨어진 아이콘이나, 그냥 보기에만 좋은 아이콘들을 기계적으로 찍어낸다. 엔지니어들은 전속 디자이너가 필요하다고 강조하지만, 기획자가 프로젝트 기간내내 거의 아무일도 하지 않고 앉아서 구경만 하는 아티스트에게 돈을 지불할 생각을 갖게 만드는 것은 매우 어렵다.

도저히 디자인 산출물을 사용할 수 없다고 판단한 엔지니어들은 직접 아이콘을 그리기 시작하며, 불만을 축적한다. 결국 기획의도와 전혀 다른 괴물이 태어난다. 운이 좋아 이것이 성공하더라도, 구현자들이 공로를 인정받는 경우는 극히 드물며, 기획자는 제품의 실제 형상을 완벽히 오해하고 있는 상태가 된다. 이 때, 지친 구현자가 직장을 그만두게 되면, 더 이상 이 시스템은 아무도 손을 쓸 수 없게 되고, 완벽한 실패로 다가가게 된다.