책의 제목으로 미루어 소프트웨어 개발을 창의적으로 하는 방법에 대한 에세이 일 것을 추측했다.

추측과는 달리 이 책은 ‘소프트웨어 개발은 창의적인 작업이다’ 라는 것을 강조한다. 이에 실망했느냐 ? 정반대다.

코드 code 가 아닌 글로 쓰여졌음에도 이 에세이는 초고수 개발자의 우아한(엘레강스) 코드를 읽는 듯한 생각을 가지게 한다.

창의적으로 보느냐 컨베이어 벨트에서의 작업 처럼 일반화된 틀에 가둘 수 있느냐에 따라서 많은 것이 바뀐다. 자동화가 가능할까? , 통제가 가능할까? Top down 방식의 설계가 효과가 있을까?, 정형기법을 적용할 수 있을까?

로버트 L. 글래스는 소프트웨어 개발은 창의적인 작업이며, 외부가 아닌 개발자 자신이 관리할 때 효율적이 된다고 말한다.  이는 엔지니어링 관점과 상반되어 보인다.

대학에서 컴퓨터 공학 전공을 컴퓨터 사이언스 Computer Science   또는, 컴퓨터 엔지니어링 Computer Engineering 이라고 부른다. 이런 이름 뒤에는 소프트웨어 개발은 통제 가능하며, 추측 가능하며, 예측 가능하다는 전제 또는, 가능해야 한다는 당위성을 전제로 하고 있다. 이런 입장은 소프트웨어 개발을 성공하기 위해서는 관리와 통제가 필수적이며, 가능하다는 사고를 요구한다.

글래스는  수십년 간의 경험으로소프트웨어 개발이라는 것이  외부의 관리와 통제가 비효율적이며, 심지어는 불가능하다는 주장을 한다. 이쯤 되면 비관적이 될 수 있다.

위의 논쟁은 산업화 세대와 지식 세대의 논쟁과 흡사하다.

관리자의 입장에서 헝클어진 머리에 찢어진 청바지에 슬리퍼를 끌고 다니는 개발자 라는 놈들을 통제하지 못한다면 소프트웨어 개발의 성공은 불가능해 보인다고 생각되기 때문이다.

글래스가 하고자 하는 말은 개발자 자신이 관리하고 체계를 만들면서 개발할 수 있는 환경이 더 효율적 이라는 것이다.

같은 저자의 이전 책 [소프트웨어 컴플릭트 2.0]이 각론에 가깝다면, 이 책은 좀더 총론에 가까우며, 이전 책이 좀더 공격적이며 흥분된 상태라면, 이 책은 차분하게 우군을 모으는 듯하다.

마지막으로 글래스가  통찰력이 멋져서 공유하고 싶다는 부분을 발췌한다. 이 내용이 상당히 인상적이었다.

“ 워싱턴 포스트 지 1989년 12월 17일자 인사이트란에 실렸던 ‘고르바초프 정신분석’ 이라는 기사다.(글이나 연설을 토대로) 여러 정치 지도자와 그들의 생각을 전문적으로 연구하는 유명한 심리학자 세 명이 고르바초프를 분석한 글이었다. 세 사람중에서 필립 E. 테트락이라는 심리학자는 지도에게 보이는 ‘사고의 복잡성’과 ‘모호성에 대처하는 능력’을 측정하는 시스템을 고안했는데, 그는 뛰어난 지도자를 차별 짓는 특성이 바로 이 두가지라 믿었다.  테트락에 따르면, 고르바초프는 7점 만점에서 거의 최고점을 받았다(미 상원의원 제시 헬름스는 1점을 받았다고 전한다.) 7점을 받은 인물은 문제에 부딧힐 때 대안을 볼 줄 알고, 균형 잡힌 시각으로 각 방안을 판단하며, 조치를 취해서 양분된 이견을 해소하거나 확실히 없애지 못한다면 모호성을 감내하는 능력이 있다. 그런데 흔히 복잡성과 모호성을 능숙하게 처리하는 인물은 약자로 여겨지는 반면(실제로 구 소련 연방에서 일부는 고르바초프를 나약한 인물이라 여겼다) 흑백논리를 강하게 펼치는 인물을 강자로 여겨진다는 사실이 흥미롭다고 테트락은 지적한다. 물론 그는 오히려 반대라고 주장한다.

~

테트락은 대다수 정치가들이 복잡성을 참아내는 인내력이 부족하다고 지적한다. “대개 스트레스를 받다가 단순하고 경직된 이분법적 사고로 돌아선다”고 말한다. “  pp.97. 99

 

위의 인용글은 상당히 중요한 것을 시사한다. 우리는  고르바초프 스타일의 지도자, 관리자, 개발자, 정치가들을 무능력하다고 생각하고, 흑백논리를 펴는 사람들을 생산성 있다고 여기는 경향이 얼마나 강한지 생각해 보자.

현재글 : 소프트웨어 크리에이티비티 2.0 - 소프트웨어 개발은 창의적인 작업이다. posted By - 반더빌트 2009/10/22 09:52

현재글 : 성공과 좌절 - 노무현 대통령 못다 쓴 회고록 posted By - 반더빌트 2009/10/20 10:21

소프트웨어 개발에 있어서, 사용자의 실수를 완벽히 배제하는 경향이 있다.

실수를 허락하도록 개발하는 것은 설계 및 구현에서 1.5~2배 이상의 비용이 발생하기 때문이다. 또는 설계시의 미숙 때문이다.

위의 관점은 인간을 신으로 여기는 상태를 낳는다.

인간은 신이 아니다. 인간은 실수 할 수 있는 존재라는 것을 인정해야 한다. 대부분이 실수를 한다고 가정해야 한다.


CMS Content Management System 에서 실수의 인정은 Revision의 개념이고, 이를 가장 이해 하기 쉽도록 구현된 것이 Wiki 이다.

실수를 인정하지 않는 태도는 실수하는 사용자에 대한 비난을 동반하게 된다. 소프트웨어 자체로서 한계를 짓게 된다.

실수를 허락하되 실수를 보완할 수 있는 툴을 제공하라.
현재글 : 실수를 허락하라! posted By - 반더빌트 2009/10/06 11:39