"좋은 프로그래머는 평범한 것보다 10 배나 더 생산적 일 수 있습니다"[닫기]

나는 훌륭한 프로그래머 (영어가 아님)와의 인터뷰를 읽었으며, "좋은 프로그래머는 평범한 프로그래머보다 10 배나 우수 할 수있다"고 말했다. 프로그래밍 회사는 직원에게 많은 시설을 제공합니다. 아이디어는 위와 같은 이유 때문에 훌륭한 프로그래머에 대한 수요가 매우 크다는 것이 었습니다.

이 진술에 동의하십니까? 이를 지원할 수있는 객관적인 사실을 알고 있습니까?

편집 : 질문은 경험과 관련이 없습니다. 1 년의 경험을 가진 훌륭한 프로그래머에 대해 이야기한다면 1 년의 경험을 가진 평범한 프로그래머보다 10 배나 더 생산적이어야합니다. 몇 년 동안 특정 경험에서 일이 사라지기 시작하지만 그것은 질문의 목적이 아니라는 데 동의합니다.

Steve McConnell이 작성한 두 가지 기사에서 생산성 차이에 대한 연구에 대한 철저한 개요와 분석이 제공됩니다 .

• 소프트웨어 개발자 및 팀의 생산성 변화 : "10x"의 기원

• 10X의 기원 – 기초 연구는 얼마나 유효합니까?

첫 번째 기사 ( 생산성 변형 ... )는 다음과 같이 말합니다.

... 1960 년대 후반 Sackman, Erikson, Grant (1968)는 개별 프로그래밍 생산성에서 큰 변화를 발견 한 최초의 연구를 수행했습니다. 그들은 평균 7 년의 경험을 가진 전문 프로그래머를 연구했으며 최고 프로그래머와 최악 프로그래머 사이의 초기 코딩 시간의 비율이 약 20 대 1임을 알았습니다. 25 대 1 이상의 디버깅 시간 비율; 프로그램 크기 5 내지 1; 그리고 프로그램 실행 속도는 약 10 대 1입니다. 프로그래머의 경험과 코드 품질 또는 생산성 사이에는 아무런 관련이 없습니다.

Sackman, Erickson 및 Grant의 연구 결과를 자세히 살펴보면 방법론에 몇 가지 결함이 있지만 ... 결함을 설명한 후에도 데이터는 여전히 최고의 프로그래머와 최악의 차이가 10 배 이상 차이가 나는 것으로 나타났습니다.

최초의 연구 이후 몇 년 동안, "프로그래머들 사이에 크기 차가있다"는 일반적인 발견이 다른 많은 전문 프로그래머 연구에 의해 확인되었다 (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986 , Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000) ...

^{이 기사에는 흥미로운 참고 사항도 있습니다.}

^{이 정도의 차이는 소프트웨어에만 국한되지 않습니다. Norm Augustine의 연구에 따르면 다양한 직업 (작문, 축구, 발명, 경찰 업무 및 기타 직종)에서 상위 20 %의 사람들이 출력의 약 50 %를 생산했습니다. , 해결 된 사례 또는 소프트웨어 (Augustine 1979).}

두 번째 기사 ( ... 기본 연구는 얼마나 유효합니까? )는 주로 Laurent Bossavit 의 첫 번째 기사 에 대한 비판적 검토를 다루기 위해 작성되었습니다 .

• 프랑스어로 된 원래 비평 : Folklore ou fait scientifique, 의견 les différencier
• 영어 번역 : 소프트웨어 공학의 사실과 민속 .

두 번째 기사 인 "10x"를 지원하는 연구에 대한 심층적 인 이해 섹션에서 McConnell은 첫 번째 기사에서 사용 된 참조를보다 자세히 다시 확인하고 결론을 내립니다.

...이 기사를 작성하면서 이러한 인용을 다시 한 번 검토하면서 프로그래머들 사이에 생산성 차이가 10 배라는 일반적인 발견을지지한다고 결론을 내 렸습니다. 이 연구는 다양한 프로그래밍 활동에 걸쳐 수백 명의 전문 프로그래머와 함께 참여했습니다.

... 10 배의 주장을 뒷받침하는 연구는 소프트웨어 공학에서 수행 된 모든 연구만큼 견고합니다. 10 배의 주장을 뒷받침하는 연구는 개별 변동성 자체 (즉, 그림의 왼쪽 만)를 연구하기 때문에 그림 1에 설명 된 방법 론적 제한을받지 않습니다. Bossavit은 10 배의 주장에 대응하는 하나의 연구 (결점 또는 다른 방법)도 인용하지 않았으며, 그러한 연구도 보지 못했습니다. 10 배 클레임과 모순되는 연구 결과가 없다는 사실은 10 배 클레임에 대해 더 많은 확신을 제공합니다. 내가 수행 한 연구의 수를 종합 해보면, 연구 결과는 암시적일뿐만 아니라 결정적인 것으로 엔지니어링 공학 연구에서는 드물다.

완전성을 위해 생산성 변동에 사용 된 참고 문헌 목록 도 아래에 인용되어 있습니다.

참고 문헌

Augustine, NR 1979. "오거스틴의 법과 주요 시스템 개발 프로그램." 방어 시스템 관리 검토 : 50-76.

Boehm, Barry W. 및 Philip N. Papaccio. 1988. "소프트웨어 비용 이해 및 제어." 소프트웨어 공학에 관한 IEEE 거래 SE-14, no. 10 (10 월) : 1462-77.

Boehm, Barry, et al., 2000. Cocomo II를 이용한 소프트웨어 비용 추정 : 매사추세츠 주 보스턴 : Addison Wesley, 2000.

Boehm, Barry W., TE Gray 및 T. Seewaldt. 1984. "프로토 타이핑 대 지정 : 다중 프로젝트 실험." 소프트웨어 공학에 관한 IEEE 거래 SE-10, no. 3 (5 월) : 290-303. 또한 Jones 1986b에서.

Card, David N. 1987. "소프트웨어 기술 평가 프로그램." 정보 및 소프트웨어 기술 29, no. 6 (7 월 / 8 월) : 291-300.

커티스, 빌 1981. "프로그래머 다양성의 입증." IEEE 69의 절차, no. 7 : 846.

Curtis, Bill 등 1986. "소프트웨어 심리학 : 학제 간 프로그램의 필요성." IEEE 74의 절차, no. 8 : 1092-1106.

DeMarco, Tom 및 Timothy Lister. 1985. "프로그래머 성능 및 작업장의 영향." 제 8 회 국제 소프트웨어 공학 회의 진행 워싱턴 DC : IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware : 생산적인 프로젝트 및 팀, 2d Ed. 뉴욕 : 도셋 하우스, 1999.

Mills, Harlan D. 1983. 소프트웨어 생산성. 보스턴, 매사추세츠 : Little, Brown.

Sackman, H., WJ Erikson 및 EE Grant. 1968. "온라인 및 오프라인 프로그래밍 성능을 비교 한 탐험 실험 연구." ACM의 커뮤니케이션 11, no. 1 (1 월) : 3-11.

Valett, J. 및 FE McGarry. 1989. "소프트웨어 엔지니어링 실험실에서의 소프트웨어 측정 경험 요약." 시스템 및 소프트웨어 저널 9, no. 2 (2 월) : 137-48.

와인버그, 제랄드 엠, 에드워드 엘 슐만 1974. "컴퓨터 프로그래밍의 목표와 성과." 휴먼 팩터 16, no. 1 (2 월) : 70-77.

진정으로 끔찍한 프로그래머는 생산성이 0보다 낮을 수 있습니다. 도입 한 버그는 모든 작업을 수행하는 것보다 수정하는 데 시간이 오래 걸립니다.

그리고 진정으로 훌륭한 프로그래머는 시간이 얼마나 걸리더라도 가난한 프로그래머와 평범한 프로그래머는 결코 달성 할 수없는 일을 할 수 있습니다.

따라서 이러한 이유로 "생산적인 10 배"또는 "생산적인 100 배"에 대해서는 말하기가 어렵습니다.

그러나 기억해야 할 것은 대부분의 프로그래머 고용주는 일반 프로그래머가 관리 할 수없는 어려운 작업을 수행 할 필요가 없다는 것입니다. 작성되는 대부분의 코드는 웹 사이트, LOB (Line of Business) 앱, 인트라넷 앱 등이며, 실제로는 그렇게 어렵지 않습니다. 해당 환경의 생산적인 프로그래머는 가장 영리한 코드를 작성할 수있는 사람이 아니라 사용자의 요구를 가장 잘 이해하고 구현하는 사람입니다.

실제로, 대부분의 프로그래머 고용주들은 위대한 프로그래머보다는 좋은 프로그래머보다 더 나을 것입니다. 왜냐하면 위대한 전문가는 지루하고 떠나기 때문입니다. 프로그래머와 직업이 잘 어울립니다.

소프트웨어 엔지니어링 상태 의 사실 및 오류 (사실 2, 아마존 미리보기에서 사용 가능) :

"개인 차이"연구에 따르면 최고의 프로그래머는 최악의 프로그래머보다 최대 28 배 더 우수합니다. 그들의 임금이 결코 적당한 수준이 아니라는 것을 감안할 때, 그들은 소프트웨어 분야에서 가장 큰 거래입니다.

(연구용 소스 목록보기)

물론, 비 프로그래머 (또는 매우 나쁜 프로그래머)의 생산성과 좋은 경험 (경험과 지식의 관점)을 비교하면 그 차이는 무한히 클 수 있지만 ( n/0 == infinity긍정적 인 n것은 아닙니다) 합리적인 비교도 아닙니다.

급여는 여러 가지 요인 (임의 순서)에 따라 달라질 수 있습니다.

• 사용 된 기술
• 근무하는 국가 / 주
• 회사의 부
• 회사의 사업 유형
• 회사의 개발자 수
• 회사에서 근무하는 시간
• 사무실 정치

개인과 함께 ...

• 생산력
• 지식과 경험
• 회사의 사업 참여 (스타트 업)
• 협상 기술
• 성적 매력과 기술, lol (음, 지능은 섹시합니다)

내 대답은 "그렇습니다.하지만 해당 메트릭을 어떻게 사용하는지주의하십시오".

우리가 말하면 최적의 기능을하는 프로그래머는 기능을 위해 만들어 내고 성능이 낮은 형제보다 수정이 필요한 오류가 적은 프로그래머입니다. 이 사람들이 다른 사람들의 확률을 10X로 수행 할 수 있다고 믿기는 어렵습니다. 특히 한 시간에 한 가지 좋은 선택이나 나쁜 선택이 쉽게 10 시간의 영향을 미칠 수 있다고 생각할 때 프로그래머는 많은 선택을합니다. 대부분의 날.

그러나...

이것을 측정하는 데주의를 기울였습니다. 알려진 모든 지표가 팀 생산성에 중요한 것으로 간주되지 않는 끝없는 사례를 보았 기 때문에 생산성에 대한 대부분의 측정을 신뢰하지 않습니다. 그래서 나는 일반적으로 "생산성"이라는 어려운 숫자를 싫어합니다. 몇 가지 예는 다음과 같습니다.

• 코드 라인 (LOC)-생각이없는 프로그래머가 코드 라인을 디버그하기가 끔찍하고, 장황하며, 비효율적이며 많은 코드 라인을 생성 할 수 있기 때문에 일반적으로 증오 메트릭스 더 많은 시간에, 그러나 전체적으로 더 나은 선택입니다.
• 생성 된 버그 및 / 또는 수정 시간-모든 사람이 버그를 생성하며 가장 비싼 버그는 일련의 잘못된 결정에 의해 생성되는 경우가 많습니다. 또한 훌륭한 디버거가 항상 훌륭한 디자이너는 아니지만 둘 다 필요합니다.
• 거의 모든 측정 기준에 따르면 팀에 큰 어려움을 겪는 훌륭한 개발자가 있습니다. 1 명의 "최고 생산적인"개발자는 기본적으로 10 명의 훌륭한 개발자를 몰아 낼 수 있으며 모든 것을 잘 수행 할 수있는 사람은 거의 볼 수 없으므로 프로젝트에서 한 사람 이상.
• 문제가 심각한 CM, 비효율적 인 빌드, 테스트의 격차, 보안 결함 등 프로세스의 격차 인 경우, 심각한 문제가 발생하기 전에 발생하는 문제를보고 해결하는 훌륭한 사람들을 쉽게 설명 할 방법이 없습니다. 재난으로부터 당신을 구할 수 있다는 것을 깨달을 때까지 종종 큰 시간 낭비처럼 보입니다.
• 또한 특정 규모의 팀에서 필연적으로 "응집력 빌더 (cohesion builder)"라고 부르는 사람들이 필요하다고 생각합니다. 생산성의 절대 최고 수준은 아니며, 대개 여전히 상위 20 %에 달하며, 상승을 돕는 귀중한 일을합니다. 새로운 사람들, 점들을 연결하고 올바른 질문을하고 올바른 사람들이 루프에 빠지게하는 것은 올바른 문서 일뿐 아니라 모든 사람이 참조하는 주요 문서를 씁니다. 올바른 방법으로 구성됩니다. 10 명의 사람들이 최고의 효율성으로 일하기를 원한다면이 사람들 중 하나가 반드시 필요하며 10 명의 슈퍼 개발자를 한 방에두면 얻을 수 없습니다.

많은 측정 시스템이 이러한 요소를 고려하려고 시도했지만 아직이 모든 문제를 고려하는 요소가 있다는 것을 아직 알지 못했기 때문에 "좋은 개발자가 10 배나 더 생산적입니다. 메트릭이 실제로 성공적인 지속적인 제품 또는 성공적인 번창 팀에 필요한 모든 작업을 설명하는지 궁금해하기 때문에 평범한 하나 "

내 큰 경고는이 메트릭으로 무엇을 할 것입니까? 올바른 도구와 재능이 작업 수행 방식에 큰 차이를 유발할 수 있다는 점을 알기 위해 이와 같은 것을 사용할 것입니다. 그러나 각 개인이 "일반적인"출력을 10X 생성하는 팀에 최적화하려고하면 좌절의 경우. 더 나은 방법은 팀이 더 잘 협력함으로써 이전보다 2-3 배 더 많은 일을 할 수있는 방법을 찾는 것입니다.

Laurent Bossavit는 자신의 저서 소프트웨어 공학의 레프 러콘 (Leprechauns of Software Engineering )에서 10 배의 생산성 주장을 연구하는 것에 대해 설명합니다. 그는 그 뒤에는 건전한 숫자가 없다는 것을 발견했다. 그 주장은 인용에서 계속해서 더 구체적인 주장 의 전화 게임 에 의해 추측에서 "설립 된 사실"로 넘어 갔다 . 10 배 클레임에 관한 장을 구성하고 관련 인용 및 오인을 포함하는 블로그 게시물 은 소프트웨어 엔지니어링의 사실과 민속입니다 .

그가 찾은 것은 다음과 같습니다. 1968 년 누군가 특정 디버깅 문제를 해결하는 사람들을 비교 한 연구를했으며 그 중 일부는 다른 것보다 10 배 더 빠른 것으로 나타났습니다. 이것으로 우리는 일부 사람들이 그 문제 를 해결하는 데 10 배 더 좋다는 결론을 내릴 수도 있고, 어떤 사람들 은 운이 좋 거나 다양한 다른 것들을 얻었다 고 결론 내릴 수도 있습니다. 어떤 사람들은 이것을“(이것들은 모두 역설 임)“작은 연구 (Sackman et al, 1968)가 일부 프로그래머들은 다른 프로그래머들보다 10 배 더 빠르게 작동한다는 것을 발견했습니다. 그런 다음 "연구에 따르면 우수한 프로그래머가 평균보다 10 배 더 우수하다는 것이 밝혀졌습니다"그리고 마지막으로 "프로그래머 생산성은 개인마다 10 배씩 다르다는 것이 일반적인 지식"입니다. 그런 다음 누군가가 모든 인용을 수집 하여 하나의 원본 출처를 잘못 인용합니다. "많은 연구원들이 믿는다…"

물론 어설 션의 진실성 만 바뀌면 전화 게임이 아닙니다. 승수는 11 이상 입니다.

" 그 환경에서 생산적인 프로그래머는 가장 영리한 코드를 작성할 수있는 사람이 아니라 사용자의 요구를 가장 잘 이해하고 구현하는 사람입니다. "( Carson63000 답변)

베스 락쉬미 와 결합 된 핵심 요점의 요점은 큰 지적입니다. 훌륭한 개발자는 한 조각의 현실에서는 훌륭하지만 세상이 바뀌 자마자 헤어질 수 있습니다. 비즈니스 요구에 부응 할 수있는 것이 무엇보다 중요합니다. 업무가 기술이 아닌 한, 비즈니스는 기술에 관심이 없습니다. 그들은 솔루션이 필요합니다. 따라서 디자인 패턴이 우수하다고해서 웹 페이지에 표시하기 위해 데이터 덤프 만 필요한 최종 사용자에게 쪼그리고 앉는 것은 아닙니다. 나는 평범한 개발자가 자신을 지원하는 비즈니스에 주력하면서 훌륭한 개발자가 지루하고 끊임없는 도전을 찾기 위해 떠날 때 직무를 확보하는 것을 보았습니다. 당신의 조직과 프로젝트에 따라, 도전에 굶주린 개발자들에게 도움을 줄 수는 있지만, 아마도 당신이하지 않은 시점이있을 것입니다. 그 정도의 처리 능력이 필요하지 않습니다. 이 개발자들은 단지 프로세서처럼 유휴 상태가되는 것을 좋아하지 않습니다. 다른 곳에서 종료했다가 다시 부팅합니다.

마지막으로, "핵심"수행자가 누구인지 아는 것은 괜찮지 만 개발 "팀"은 여전히 ​​팀입니다. bethlakshmi를 반복하기 위해 " 이 메트릭으로 무엇을 하시겠습니까?"팀처럼 행동하는 팀이 필요한 경우 이러한 메트릭에 중점을 두지 않을 것입니다. 가장 작은 선수라도 여전히 팀의 중요한 부분입니다. 키의 생산성이 60 % 나 낮아집니다 한 명의 플레이어가 팀에 필요한 것을 줄 수도 있습니다. 무엇을 찾고 그것을 곱하려고 시도하십시오. 다른 플레이어들을 그 위대함으로 오염시킴으로써 이것은 단지 숫자가 아닌 약간의 창의성을 필요로합니다. 아니면 당신이 될 수도 있습니다.