카고 컬트 소프트웨어 엔지니어링

남해에는 사람들의 카고 컬트가 있다. 전쟁 중에 그들은 좋은 재료를 많이 가진 비행기를 보았고,그들은 지금 같은 일이 일어나기를 원합니다. 그래서 그들은 활주로와 같은 것들을 만들고,활주로의 측면을 따라 불을 붙이고,사람이 앉을 나무 오두막을 만들고,머리에 두 개의 나무 조각을 헤드폰과 대나무로 만든 막대기가 안테나처럼 튀어 나와 컨트롤러입니다. 그들은 모든 것을 올바르게하고 있습니다. 양식은 완벽합니다. 그것은 전에 보았던 것과 정확히 같습니다. 그러나 그것은 작동하지 않습니다. 비행기가 착륙하지 않습니다. 그래서 저는 이런 것들을 카고 컬트 과학이라고 부릅니다.왜냐하면 그것들은 과학적 조사의 모든 명백한 교훈과 형태를 따르기 때문입니다.그러나 그들은 필수적인 것을 놓치고 있습니다.왜냐하면 비행기는 착륙하지 않기 때문입니다.
-리처드 파인만

나는 두 개의 서로 다른 조직 개발 스타일 사이의 대조를 그리는 것이 유용 찾을:”프로세스 지향”과”헌신 지향”개발. 프로세스 중심의 개발은 숙련 된 계획,신중하게 정의 된 프로세스의 사용,사용 가능한 시간의 효율적인 사용 및 소프트웨어 엔지니어링 모범 사례의 숙련 된 적용을 통해 효율성을 달성합니다. 이 개발 스타일은 그것을 사용하는 조직이 지속적으로 개선되고 있기 때문에 성공합니다. 비록 그것의 초기 시도가 효과가 없더라도,과정에 꾸준한 주의는 각 계속되는 시도가 이전 시도 보다는 잘 작동할 것이라는 점을 의미한다.

헌신 중심 개발은”영웅 중심 개발”과”개인 권한 부여”를 포함한 여러 이름으로 진행됩니다.”헌신 지향적 인 조직은 가능한 한 최고의 사람들을 고용하고,프로젝트에 대한 완전한 헌신을 요청하고,거의 완전한 자율성을 발휘하고,극단적 인 동기를 부여한 다음,프로젝트가 끝날 때까지 일주일에 60 시간,80 시간 또는 100 시간을 일하는 것을 보는 것이 특징입니다. 헌신 지향적 인 개발은 엄청난 동기 부여 능력에서 그 힘을 파생—연구 후 연구는 개인의 동기 부여는 지금까지 생산성에 가장 큰 단일 기여자 것을 발견했다. 개발자들은 그들이 일하는 프로젝트에 자발적이고 개인적인 약속을하고,종종 프로젝트를 성공시키기 위해 특별한 노력을 기울입니다.

조직 사기꾼

지식적으로 사용하면 어느 개발 스타일이든 고품질의 소프트웨어를 경제적이고 신속하게 생산할 수 있습니다. 그러나 두 가지 개발 스타일 모두 거의 작동하지 않는 병리학 적 외관을 가지고 있으며 정품 기사와 구별하기가 어려울 수 있습니다.

프로세스-사기꾼 조직은 프로세스를 위한 프로세스에 대한 노예적 헌신에 그 관행을 기초한다. 이러한 조직은 미항공 우주국의 소프트웨어 공학 연구소와 아이비엠의 전 연방 시스템 부서와 같은 프로세스 중심 조직을 살펴봅니다. 그들은 그 조직이 문서를 많이 생성하고 자주 회의를 개최 것을 관찰한다. 그들은 동일한 수의 문서를 생성하고 비슷한 수의 회의를 개최하면 유사하게 성공할 것이라고 결론 지었다. 그들이 문서를 더 생성하고 회의를 더 붙들면,훨씬 성공적 이을 것이다! 그러나 그들은 문서와 회의가 성공에 대한 책임이 없다는 것을 이해하지 못합니다; 그들은 몇 가지 특정 효과적인 프로세스의 부작용입니다. 그들은 물질 위에 소프트웨어 프로세스의 형태를 넣어 때문에 우리는 관료 이러한 조직을 호출합니다. 그들의 프로세스 오용은 동기를 떨어 뜨리고 생산성을 떨어 뜨립니다. 그리고 그들은 일하는 것이 즐겁지 않습니다.

헌신-사기꾼 조직은 주로 사람들이 오랜 시간 일하도록 동기를 부여하는 데 중점을 둡니다. 이 조직은 마이크로 소프트와 같은 성공적인 회사를 보면;그들은 아주 작은 문서를 생성하는 것을 관찰;직원들에게 스톡 옵션을 제공; 그리고 그들에게 초과 근무의 산을 일하도록 요구하십시오. 그들은,너무,문서를 최소화 스톡 옵션을 제공하고,광범위한 초과 근무를 필요로하는 경우,그들은 성공할 것이라고 결론 지었다. 적은 문서 및 더 많은 초과 근무,더 나은! 그러나 이 조직은 마이크로소프트와 다른 성공적인 투입 동쪽으로 향하게 한 회사가 초과 근무를 요구하지 않는다 는 사실을 놓친다. 그들은 소프트웨어를 만드는 것을 좋아하는 사람들을 고용합니다. 그들은 이 사람들을 다른 사람들과 팀을 이루어 그들이 하는 것만큼이나 소프트웨어를 만드는 것을 좋아합니다. 그들은 소프트웨어를 만들기위한 호화로운 조직 지원과 보상을 제공합니다. 그리고 그들은 그들을 풀어줍니다. 자연스러운 결과는 소프트웨어 개발자와 관리자가 자발적으로 오랜 시간 일하도록 선택하는 것입니다. 사기꾼 조직은 효과(긴 시간)와 원인(높은 동기 부여)을 혼동합니다. 우리는 사기꾼 조직을 착취 공장이라고 부릅니다.왜냐하면 그들은 똑똑하기보다는 열심히 일하는 것을 강조하기 때문입니다.그리고 그들은 혼란스럽고 비효율적 인 경향이 있습니다. 그들은 또한 일하는 것이 즐겁지 않습니다.

카고 컬트 소프트웨어 엔지니어링

언뜻 보면,이 두 종류의 사기꾼 조직은 정반대 인 것처럼 보입니다. 하나는 엄청나게 관료적이며 다른 하나는 엄청나게 혼란 스럽습니다. 그러나 하나의 핵심 유사성은 표면적 차이보다 실제로 더 중요합니다. 둘 다 매우 효과적이며 그 이유는 프로젝트가 실제로 성공하거나 실패하게 만드는 것을 이해하지 못하기 때문입니다. 그들은 문체로 유사한 효과적인 조직 보기의 동의로 간다. 그러나 관행이 작동하는 이유의 실제 이해하지 않고,그들은 본질적으로 단지 그들의 귀에 대나무 조각을 고집하고 자신의 프로젝트가 안전하게 착륙 바라고 있습니다. 이 소프트웨어 프로젝트가 작동하게 무엇에 대한 이해의 부족 유사 컬트 소프트웨어 엔지니어링화물,단지 두 개의 서로 다른 종류이기 때문에 자신의 프로젝트의 대부분은 충돌 결국.

카고 컬트 소프트웨어 엔지니어링은 쉽게 식별 할 수 있습니다. 카고 컬트 소프트웨어 엔지니어들은”우리는 항상 과거에 이런 식으로 해왔습니다.”또는”우리 회사 표준은 우리가 이런 식으로 할 것을 요구합니다.”라고 말함으로써 그들의 관행을 정당화합니다. 그들은 프로세스 지향 또는 헌신 지향 개발에 관련된 트레이드 오프를 인정하기를 거부합니다. 둘 다 강점과 약점이 있습니다. 보다 효과적이고 새로운 관행을 제시 할 때,카고 컬트 소프트웨어 엔지니어는 친숙하고 편안하며 반드시 효과적이지 않은 작업 습관의 나무 오두막에 머무르는 것을 선호합니다. “동일한 일을 몇번이고 하고 다른 결과를 예기함것은 광기의 표시 이다,”오래 되는 말은 간다. 또한 카고 컬트 소프트웨어 엔지니어링의 표시이기도합니다.

실제 토론

이 잡지와 다른 많은 출판물에서 우리는 프로세스가 좋은지 또는 개인의 권한 부여(즉,헌신 지향적 인 개발)가 더 나을 수 있는지에 대해 토론하는 데 시간을 보냅니다. 이것은 거짓 이분법입니다. 과정은 좋다,그래서 개인적인 허가이다. 이 두 가지가 나란히 존재할 수 있습니다. 프로세스 지향 조직은 특정 프로젝트에 대한 극단적 인 헌신을 요청할 수 있습니다. 헌신 지향적 인 조직은 소프트웨어 엔지니어링 관행을 능숙하게 사용할 수 있습니다.

이 두 가지 접근 방식의 차이는 스타일과 개성의 차이로 귀결됩니다. 나는 각 스타일의 여러 프로젝트를 수행했으며 각 스타일에 대해 다른 것을 좋아했습니다. 일부 개발자는 프로세스 지향 회사에서 더 일반적인 8~5 일정에 체계적으로 작업을 즐길 수 있습니다. 다른 개발자들은 프로젝트에 24,000,000,000 의 헌신과 함께 제공되는 초점과 흥분을 즐길 수 있습니다. 헌신 지향적 인 프로젝트는 평균적으로 더 흥미 진진하지만 프로세스 지향적 인 프로젝트는 잘 정의되고 고무적인 임무를 수행 할 때 흥미 진진 할 수 있습니다. 프로세스 중심의 조직은 헌신 지향적 인 조직보다 덜 자주 자신의 병리학 적 닮은 것으로 변질되는 것처럼 보이지만,어느 스타일이든 능숙하게 계획되고 실행되면 잘 작동 할 수 있습니다.

프로세스 중심의 프로젝트와 약속 중심의 프로젝트 모두 병리학 적 외관을 가지고 있다는 사실은 논쟁을 뒤흔들었다. 각 스타일로 수행되는 일부 프로젝트는 성공하고 일부는 실패합니다. 이를 통해 프로세스 옹호자는 프로세스 성공 및 헌신 실패를 지적하고 프로세스가 성공의 열쇠라고 주장 할 수 있습니다. 그것은 헌신 옹호자가 같은 일을 할 수 있습니다.

우리가 공약 대 과정을 토론하고있는 동안 길가에 의해 떨어진 문제는 너무 뻔뻔 스럽기 때문에,에드가 앨런 포의 도적질 편지처럼,우리가 그것을 간과했다는 것이 너무 명백했을 수도 있습니다. 우리는 투입대 과정을 토론하면 안된다;우리는 무능력대 적성을 토론해야 한다. 진정한 차이점은 어떤 스타일이 선택되는 것이 아니라 어떤 교육,훈련 및 이해가 프로젝트에 적용되는지에 있습니다. 공약대 과정을 토론하기 오히려,우리는 개발자와 매니저 적성의 평균 수준을 올리는 방법을 찾아야 한다. 이는 우리가 선택한 개발 스타일에 관계없이 성공 가능성을 향상시킬 것입니다.