Why We Write에서 쓰기의 중요성은 충분히 얘기한 것 같다. 소프트웨어 개발에서도 쓰기의 역할과 중요성은 다르지 않다. 하지만, 그 중요성을 인지하지 못하는 경우, 소프트웨어 개발에서는 여러가지 문제들이 발생할 수 있다. 이 글은 쓰지 않는 것이 소프트웨어 개발에 어떤 악영향을 미치는 지에 관한 개인적인 경험을 기술한다. 이 글은 소프트웨어 개발에 있어서 어떤 것을 써야하는가, 어떻게 써야하는가를 다루지는 않는다.
1. 명확하지 않은 명세(specification)
10페이지 내지 100페이지 짜리 Microsoft Word 명세 문서를 써내야한다고 주장하는 것은 아니다. 단 하나의 문장으로 쓰더라도, 명세는 글로 쓰여질 필요가 있다. 구두를 통한 명세와 그 전달은 애초에 명세가 불명확하거나, 그러한 불명확한 점을 쉽게 짚어낼 수 없고, 전달과정에서 왜곡되거나 손실되며, 이후에도 잘못된 점을 알아차리기 힘들다. 반대로, 명세가 글로 쓰여진다면, 처음부터 불명확할 가능성이 줄어들 것이며, 불명확함을 누구든 그것을 읽는 사람이 알아차리기 쉬울 것이며, 적어도 전달과정에서는 왜곡되거나 손실되지 않을 것이며, 나중에 다른 누군가가 보더라도 잘못된 점을 알아차릴 것이다.
2. 비효율적인 의사소통
구두를 통한 의사소통(직접 대면한 상태의 대화, 전화, 회의)의 커다란 단점 중의 하나는 바로 의사소통 참가자의 시간을 배타적으로 점유한다는 것이다. 의사소통이 언제 어디에서 일어날 것인지가 결정되면, 또는 이미 의사소통이 일어난 후에는, 다른 중요한 일이 있더라도 의사소통의 우선순위를 재조정하기는 매우 힘들다는 것이다. 쓰기를 통한 의사소통은 그렇지 않다. 의사소통의 참가자들은 자신이 원하는 시간과 장소를 사용할 수 있다. 우선순위의 조정이 매우 자유롭다. 물론, 구두를 통해서만 할 수 있는 활동(즉각적인 피드백, 상대방 의지의 확인 등)이 존재하기 때문에, 모든 의사소통이 쓰기를 통해야한다는 것은 아니다. 다만, 구두를 통해서만 할 수 있는 활동이 아닐 경우에는 쓰기를 선호해야한다는 것이다.
특정 시간과 장소에 국한된다는 구두를 통한 의사소통의 단점에서 파생되는 다른 문제는 바로 참여한 당사자 외에는 의사소통의 내용을 알기 힘들다는 것에 있다. 회의록을 남기는 이유는 바로 이러한 문제를 해결하기 위한 것이다. 공식적인 회의가 아니라고 하더라도 구두를 통한 의사소통을 쓰는 것은 같은 이유로 중요하다.
쓰기가 없는 구두를 통한 의사소통이 비효율적인 점을 보여주는 단편적인 예로, 한사람과 의사소통한 내용을, 다른 한 사람, 그리고 또 한 사람 이렇게 차례대로 의사소통하는 경우를 볼 수 있다. 그야말로 코미디가 아닌가.
3. 과거의 활동/결정에 대한 회고 불가능
쓰지 않는 조직해서 흔히 볼 수 있는 광경은 다음과 같은 것이다.
“이렇게 하기로 결정/생각/디자인했었는데, 실제로 반영/작업/구현을 했었던가?”
“대체 왜 우리가 그런 결정을 했더라?” “내가 왜 그렇게 작업/디자인/구현했지?”
한달 내지는 두달 만에 끝나고 다시는 쳐다보지 않을 소프트웨어 개발 프로젝트에서는 이러한 경우는 별로 없다. 하지만, 단기 프로젝트가 아니라면, 현대의 소프트웨어 개발의 특성상 환경과 요구사항은 빠르게 변화하기 때문에, 과거의 결정을 회고하고 다시 결정해야하는 경우가 자주 발생한다. 쓰지 않는 조직은 그 때마다 위와 같은 질문들을 하기 마련이다.