“ โปรแกรมเมอร์ที่ดีสามารถสร้างผลงานได้ดีกว่าแบบธรรมดาถึง 10 เท่า” [ปิด]


54

ฉันได้อ่านบทสัมภาษณ์กับโปรแกรมเมอร์ที่ยอดเยี่ยม (ไม่ใช่ภาษาอังกฤษ) และในนั้นเขากล่าวว่า "โปรแกรมเมอร์ที่ยอดเยี่ยมสามารถทำได้ดีถึง 10 เท่าและปานกลาง" ให้เหตุผลว่าทำไมโปรแกรมเมอร์ที่ดีถึงได้รับค่าตอบแทนที่ดีและทำไม บริษัท การเขียนโปรแกรมให้สิ่งอำนวยความสะดวกมากมายสำหรับพนักงานของพวกเขา แนวคิดก็คือมีความต้องการโปรแกรมเมอร์ที่ดีจำนวนมากเนื่องจากเหตุผลข้างต้นและนั่นเป็นสาเหตุที่ บริษัท ต่างๆต้องจ่ายเงินจำนวนมากเพื่อนำมาใช้

คุณเห็นด้วยกับคำสั่งนี้หรือไม่? คุณรู้ข้อเท็จจริงวัตถุประสงค์ใด ๆ ที่สามารถรองรับได้

แก้ไข: คำถามไม่มีส่วนเกี่ยวข้องกับประสบการณ์ ถ้าคุณพูดคุยเกี่ยวกับโปรแกรมเมอร์ที่ยอดเยี่ยมหนึ่งคนที่มีประสบการณ์ 1 ปีดังนั้นเขาควรจะทำงานได้ดีกว่าโปรแกรมเมอร์ธรรมดาที่มีประสบการณ์ 1 ปีเป็น 10 เท่า ฉันเห็นด้วยว่าจากประสบการณ์บางปีเป็นต้นไปสิ่งต่างๆเริ่มกระจายไป แต่นั่นไม่ใช่จุดประสงค์ของคำถาม


คุณสามารถโพสต์ลิงค์ในการสัมภาษณ์ได้หรือไม่?
Mirco

1
@ area404 อย่างที่ฉันพูดมันไม่ได้เป็นภาษาอังกฤษ: economie.hotnews.ro/…
m3th0dman


9
10X แตกต่างผลผลิตเป็นความจริงรู้จักวัดสำหรับโปรแกรมเมอร์ (McConnell 1 , 2 )
ริ้น

คำตอบ:


41

ภาพรวมอย่างละเอียดและการวิเคราะห์งานวิจัยเกี่ยวกับความแตกต่างของผลผลิตมีอยู่ในบทความสองบทความที่เขียนโดยSteve McConnell :

บทความแรก ( รูปแบบการเพิ่มประสิทธิภาพ ... ):

... การศึกษาต้นฉบับที่พบว่ามีความแตกต่างอย่างมากในการเพิ่มประสิทธิภาพการเขียนโปรแกรมส่วนบุคคลได้ดำเนินการในช่วงปลายทศวรรษ 1960 โดย Sackman, Erikson และ Grant (1968) พวกเขาศึกษาโปรแกรมเมอร์มืออาชีพที่มีประสบการณ์โดยเฉลี่ย 7 ปีและพบว่าอัตราส่วนของเวลาการเข้ารหัสเริ่มต้นระหว่างโปรแกรมเมอร์ที่ดีที่สุดและแย่ที่สุดคือประมาณ 20 ต่อ 1 อัตราส่วนของการดีบักคูณ 25 ต่อ 1 ขนาดโปรแกรม 5 ต่อ 1; และความเร็วในการทำงานของโปรแกรมประมาณ 10 ถึง 1 พวกเขาไม่พบความสัมพันธ์ระหว่างจำนวนประสบการณ์ของโปรแกรมเมอร์และคุณภาพของโค้ดหรือผลผลิต

การตรวจสอบอย่างละเอียดเกี่ยวกับ Sackman, Erickson และการค้นพบของ Grant แสดงข้อบกพร่องบางอย่างในวิธีการของพวกเขา ... อย่างไรก็ตามแม้หลังจากการบัญชีสำหรับข้อบกพร่องข้อมูลของพวกเขายังคงแสดงให้เห็นถึงความแตกต่างมากกว่า 10 เท่าระหว่างโปรแกรมเมอร์ที่ดีที่สุดและแย่ที่สุด

ในปีที่ผ่านมานับตั้งแต่การศึกษาดั้งเดิมพบว่า "มีความแตกต่างในลำดับความสำคัญของโปรแกรมเมอร์" ได้รับการยืนยันโดยการศึกษาอื่น ๆ ของโปรแกรมเมอร์มืออาชีพ (Curtis 1981, Mills 1983, DeMarco และ Lister 1985, Curtis et al. 1986 , บัตร 1987, Boehm และ Papaccio 1988, Valett และ McGarry 1989, Boehm et al 2000) ...

บทความนี้ยังมีข้อความด้านที่น่าสนใจ:

ระดับของการเปลี่ยนแปลงนี้ไม่ซ้ำกับซอฟต์แวร์ จากการศึกษาของนอร์มออกัสพบว่าในอาชีพที่หลากหลายไม่ว่าจะเป็นงานเขียน, ฟุตบอล, สิ่งประดิษฐ์, งานตำรวจและอาชีพอื่น ๆ - 20% แรกของคนที่ผลิตออกมาประมาณ 50 เปอร์เซ็นต์ของผลผลิตไม่ว่าจะเป็นทัชดาวน์สิทธิบัตร แก้ไขกรณีหรือซอฟต์แวร์ (Augustine 1979)


บทความที่สอง ( ... การวิจัยอ้างอิงที่ถูกต้องเป็นอย่างไร ) ได้ถูกเขียนขึ้นเพื่อเน้นการตรวจสอบที่สำคัญของบทความแรกโดยLaurent Bossavit :

ในบทความที่สองในหมวดA ลึกลงไปในการสนับสนุนการวิจัย“ 10x” McConnell ตรวจสอบรายละเอียดเพิ่มเติมเกี่ยวกับการอ้างอิงที่ใช้ในบทความแรกและสรุป:

... เมื่อฉันตรวจสอบการอ้างอิงเหล่านี้อีกครั้งในการเขียนบทความนี้ฉันได้ข้อสรุปอีกครั้งว่าพวกเขาสนับสนุนการค้นพบโดยทั่วไปว่าโปรแกรมเมอร์มีความแตกต่างกัน 10 เท่า การศึกษาดังกล่าวเกี่ยวข้องกับโปรแกรมเมอร์มืออาชีพหลายร้อยคนในกิจกรรมการเขียนโปรแกรม

... เนื้อหาของการวิจัยที่สนับสนุนการอ้างสิทธิ์ 10 เท่านั้นแข็งแกร่งพอ ๆ กับการวิจัยใด ๆ ที่ทำในวิศวกรรมซอฟต์แวร์ การศึกษาที่สนับสนุนการอ้างสิทธิ์ 10 เท่านั้นไม่ได้อยู่ภายใต้ข้อ จำกัด ของระเบียบวิธีที่อธิบายไว้ในรูปที่ 1 เพราะพวกเขากำลังศึกษาความแปรปรวนของตัวเอง (เช่นเฉพาะด้านซ้ายของภาพ) Bossavit ไม่ได้อ้างแม้แต่การศึกษาเดียว - มีข้อบกพร่องหรืออื่น ๆ - ที่เคาน์เตอร์เรียกร้อง 10x และฉันไม่ได้เห็นการศึกษาดังกล่าวเช่นกัน ความจริงที่ว่าไม่มีการศึกษาใดที่ค้นพบที่ขัดแย้งกับข้อเรียกร้อง 10x ทำให้เกิดความมั่นใจมากขึ้นในการเรียกร้อง 10x เมื่อฉันพิจารณาจำนวนการศึกษาที่ได้ทำไปโดยรวมแล้วฉันพบว่างานวิจัยนั้นไม่เพียง แต่เป็นการชี้นำเท่านั้น แต่ยังได้ข้อสรุปซึ่งหาได้ยากในการวิจัยทางวิศวกรรมซอฟต์แวร์


เพื่อความสมบูรณ์รายการอ้างอิงที่ใช้ในรูปแบบผลผลิต ...ยังมีการอ้างอิงด้านล่าง:

อ้างอิง

ออกัสติน NR 2522 ได้ "กฎหมายของออกัสตินและโครงการพัฒนาระบบที่สำคัญ" การทบทวนการจัดการระบบป้องกัน: 50-76

Boehm, Barry W. , และ Philip N. Papaccio 2531 ได้ "การทำความเข้าใจและควบคุมต้นทุนซอฟต์แวร์" ธุรกรรม IEEE ในวิศวกรรมซอฟต์แวร์ SE-14, ฉบับที่ 10 (ตุลาคม): 1462-77

Boehm, Barry, et al, 2000. การประมาณราคาซอฟต์แวร์กับ Cocomo II, Boston, Mass: Addison Wesley, 2000

Boehm, Barry W. , TE Gray และ T. Seewaldt 2527 ได้ "การทำต้นแบบกับการระบุ: การทดลองแบบหลายขั้นตอน" ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์ SE-10 เลขที่ 3 (พฤษภาคม): 290-303 นอกจากนี้ใน Jones 1986b

Card, David N. 1987. "โปรแกรมประเมินเทคโนโลยีซอฟต์แวร์" เทคโนโลยีสารสนเทศและซอฟต์แวร์ 29, 6 (กรกฎาคม / สิงหาคม): 291-300

เคอร์ติสบิล 2524 ได้ "ความแปรปรวนโปรแกรมเมอร์ Substantiating" การดำเนินการของ IEEE 69, no. 7: 846

เคอร์ติสบิลและคณะ 2529 ได้ "จิตวิทยาซอฟต์แวร์: ความต้องการโปรแกรมสหวิทยาการ" การดำเนินการของ IEEE 74 หมายเลข 8: 1092-1106

DeMarco, Tom และ Timothy Lister 2528 ได้ "ประสิทธิภาพของโปรแกรมเมอร์และผลกระทบของที่ทำงาน" การประชุมวิชาการวิศวกรรมซอฟต์แวร์นานาชาติครั้งที่ 8 Washington, DC: IEEE Computer Society Press, 268-72

DeMarco, Tom และ Timothy Lister, 1999. Peopleware: โครงการผลิตและทีม, 2d Ed นิวยอร์ก: บ้านดอร์เซ็ท 2542

Mills, Harlan D. 1983. ประสิทธิภาพของซอฟต์แวร์ บอสตัน, แมสซาชูเซต: น้อย, สีน้ำตาล

Sackman, H. , WJ Erikson และ EE Grant 2511 ได้ "การศึกษาเชิงทดลองเชิงเปรียบเทียบการเขียนโปรแกรมออนไลน์และออฟไลน์" การสื่อสารของ ACM 11 หมายเลข 1 (มกราคม): 3-11

Valett, J. และ FE McGarry 1989. "สรุปประสบการณ์การวัดซอฟต์แวร์ในห้องปฏิบัติการวิศวกรรมซอฟต์แวร์" วารสารระบบและซอฟต์แวร์ 9 หมายเลข 2 (กุมภาพันธ์): 137-48

Weinberg, Gerald M. , และ Edward L. Schulman 2517 ได้ "เป้าหมายและประสิทธิภาพในการเขียนโปรแกรมคอมพิวเตอร์" ปัจจัยมนุษย์ 16, ไม่มี 1 (กุมภาพันธ์): 70-77


13
"ร่างกายของการวิจัยที่สนับสนุนการเรียกร้อง 10x นั้นแข็งแกร่งพอ ๆ กับการวิจัยใด ๆ ที่ทำในวิศวกรรมซอฟต์แวร์" - ใช่มันเลวร้ายจริงๆ :)

ดูการสนทนาระหว่าง Bossavit และ McConnell (และคนอื่น ๆ ) ในความคิดเห็นภายใต้บทความที่ 2
DNA

92

โปรแกรมเมอร์ที่น่ากลัวอย่างแท้จริงสามารถมีประสิทธิภาพการผลิตต่ำกว่าศูนย์ (ข้อบกพร่องที่พวกเขาแนะนำใช้เวลาในการแก้ไขนานกว่าที่จะต้องใช้เพื่อทำงานทั้งหมดให้พวกเขา)

และโปรแกรมเมอร์ผู้ยิ่งใหญ่อย่างแท้จริงสามารถทำสิ่งต่าง ๆ ที่โปรแกรมเมอร์ผู้น่าสงสารและคนทั่วไปไม่เคยทำได้สำเร็จ

ดังนั้นด้วยเหตุผลเหล่านี้จึงเป็นเรื่องยากที่จะพูดถึง "10x เป็นผลผลิต" หรือ "100x เป็นประสิทธิผล"

สิ่งที่ต้องจดจำก็คือนายจ้างส่วนใหญ่ของโปรแกรมเมอร์ไม่ต้องการให้พวกเขาทำสิ่งที่ยากที่โปรแกรมเมอร์ทั่วไปไม่สามารถจัดการได้ โค้ดส่วนใหญ่ที่เขียนคือเว็บไซต์แอปธุรกิจแอปอินทราเน็ต ฯลฯ ส่วนใหญ่ไม่ยาก โปรแกรมเมอร์ที่มีประสิทธิผลในสภาพแวดล้อมนั้นเป็นผู้ที่เข้าใจและนำความต้องการของผู้ใช้ไปใช้ได้ดีที่สุดไม่ใช่ผู้ที่สามารถเขียนรหัสที่ฉลาดที่สุดได้

แน่นอนนายจ้างส่วนใหญ่ของโปรแกรมเมอร์จะดีกว่ากับโปรแกรมเมอร์ที่ดีแทนที่จะเป็นโปรแกรมเมอร์ที่ดีเพราะคนดีจะเบื่อและออกไป ต้องหาคู่ที่ดีระหว่างโปรแกรมเมอร์และงาน


33
เช่นเดียวกับโปรแกรมเมอร์ที่แย่มากที่สามารถลดประสิทธิภาพของคนรอบข้างพวกเขาโปรแกรมเมอร์ที่ยอดเยี่ยมสามารถปรับปรุงประสิทธิภาพของคนรอบข้างได้ พวกเขาสร้างรหัสที่ง่ายต่อการขยายและการสนทนาห้านาทีกับพวกเขาสามารถรับโปรแกรมเมอร์อื่น ๆ ในการติดตามที่ดีขึ้น
Gort the Robot

8
เมื่อเทียบกับโปรแกรมเมอร์ที่ยอดเยี่ยมของคุณจริง ๆ แล้วโปรแกรมเมอร์ที่มีผลผลิตไม่เป็นศูนย์
glenatron

คุณจะวัดกวีที่ดีที่มีประสิทธิผลมากกว่ากวีที่ไม่ดีได้อย่างไร หากคุณต้องการผลผลิตที่มีคุณภาพสูงสุดบางคนอาจจะสามารถผลิตได้และคนอื่นอาจไม่สามารถผลิตได้ ตอนนี้ บริษัท ของคุณกำลังผลิตกวีนิพนธ์หรือส่งอีเมลเตือนความจำถึงลูกค้า : P
mika

30

ข้อเท็จจริงและความล้มเหลวของรัฐวิศวกรรมซอฟต์แวร์ (Fact 2 มีให้ใน amazon preview):

โปรแกรมเมอร์ที่ดีที่สุดนั้นดีกว่าโปรแกรมเมอร์ที่แย่ที่สุดถึง 28 เท่าจากการวิจัย "ความแตกต่างระหว่างบุคคล" ระบุว่าการจ่ายเงินของพวกเขาไม่เคยสมน้ำสมเนื้อ

(ดูรายการแหล่งข้อมูลที่นั่นเพื่อการวิจัย)

แน่นอนถ้าคุณเปรียบเทียบผลผลิตของผู้ที่ไม่ใช่โปรแกรมเมอร์ (หรือโปรแกรมเมอร์ที่แย่มาก) กับผู้ที่ดี (ในแง่ของประสบการณ์และความรู้) ความแตกต่างอาจมีขนาดใหญ่มาก ( n/0 == infinityสำหรับบวกn) แต่ก็ไม่ยุติธรรม หรือการเปรียบเทียบที่สมเหตุสมผล

เงินเดือนของคุณอาจขึ้นอยู่กับหลายปัจจัย (เรียงลำดับแบบสุ่ม):

  • เทคโนโลยีที่ใช้
  • ประเทศ / รัฐที่คุณทำงาน
  • ความมั่งคั่งของ บริษัท
  • ประเภทธุรกิจของ บริษัท
  • จำนวนผู้พัฒนาใน บริษัท
  • คุณทำงานใน บริษัท นานแค่ไหน
  • การเมืองสำนักงาน

พร้อมกับส่วนบุคคลของคุณ ...

  • ผลผลิต
  • ความรู้และประสบการณ์
  • การมีส่วนร่วมในธุรกิจของ บริษัท (สำหรับ startups)
  • ทักษะการเจรจาต่อรอง
  • ความน่าดึงดูดใจและทักษะทางเพศ lol (ดีความฉลาดก็เซ็กซี่)

20

คำตอบของฉันคือ "ใช่ แต่ระวังวิธีที่คุณใช้เมตริกนั้น"

โปรแกรมเมอร์ที่เราจะพูดว่าทำงานได้ดีที่สุดคือผู้ที่สร้างฟังก์ชั่นการใช้งานและทำให้เกิดข้อผิดพลาดน้อยกว่าที่ต้องแก้ไขมากกว่าเบรเทอเรนที่มีประสิทธิภาพต่ำกว่าของเขา ฉันจะไม่พบว่ามันยากที่จะเชื่อว่าคนเหล่านี้สามารถแสดงผลได้ที่ 10 เท่าของผู้อื่นโดยเฉพาะอย่างยิ่งเมื่อคุณพิจารณาว่าตัวเลือกที่ดีหรือไม่ดีที่ทำในหนึ่งชั่วโมงสามารถมีผลกระทบได้ 10 ชั่วโมง วันส่วนใหญ่

แต่...

คุณต้องระวังในการวัดนี้ ฉันไม่เชื่อถือการวัดผลส่วนใหญ่ในการผลิตเนื่องจากฉันได้เห็นกรณีไม่รู้จบที่ตัวชี้วัดที่รู้จักทุกตัวไม่สามารถพิจารณาสิ่งที่ฉันพิจารณาว่ามีความสำคัญต่อประสิทธิภาพการทำงานของทีม ดังนั้นโดยทั่วไปฉันจึงเกลียดจำนวนที่ยากเช่นนี้สำหรับ "ผลิตภาพ" นี่คือตัวอย่างบางส่วน:

  • Lines of code (LOC) - ตัวชี้วัดที่มีความเกลียดชังโดยทั่วไปเนื่องจากโปรแกรมเมอร์ที่ไม่มีความคิดสามารถสร้างบรรทัดที่น่ากลัว, verbose, ไม่มีประสิทธิภาพ, ยากที่จะดีบั๊กบรรทัดของโค้ดในขณะที่โปรแกรมเมอร์ที่ดีจะสร้างบรรทัดที่ไม่ซับซ้อน ในเวลามากขึ้น แต่โดยรวมแล้วเป็นตัวเลือกที่ดีกว่า
  • ข้อบกพร่องที่สร้างขึ้นและ / หรือเวลาในการแก้ไข - ทุกคนจะสร้างข้อบกพร่องบางอย่างและบ่อยครั้งข้อผิดพลาดที่แพงที่สุดจะถูกสร้างขึ้นโดยชุดของการตัดสินใจที่ไม่ดีซึ่งกำเนิดของปัญหาเป็นเพียงคนสุดท้ายในผลกระทบโดมิโน นอกจากนี้นักแก้จุดบกพร่องที่ยอดเยี่ยมของคุณไม่ใช่นักออกแบบที่ยอดเยี่ยมของคุณเสมอ - คุณต้องการทั้งคู่
  • เกือบทุกเมตริกมีผู้พัฒนาที่ยอดเยี่ยมที่มีความเจ็บปวดในทีมผู้พัฒนา 1 "super productive" จะขับนักพัฒนาที่ดี 10 คนออกไปและฉันไม่ค่อยเห็นใครที่สามารถทำทุกอย่างได้ดีดังนั้นเราจึงต้องการ มากกว่า 1 คนในโครงการ
  • ไม่มีวิธีที่จะอธิบายถึงคนที่ยอดเยี่ยมเหล่านั้นที่เห็นปัญหาที่เกิดขึ้นก่อนที่พวกเขาจะจริงจังและมุ่งหน้าไปโดยเฉพาะเมื่อปัญหาคือช่องว่างในกระบวนการ - CM ที่ผิดพลาด, การสร้างที่ไม่มีประสิทธิภาพ, ช่องว่างในการทดสอบ มักจะดูเหมือนเสียเวลามากจนกว่าคุณจะรู้ว่าพวกเขาช่วยคุณให้รอดพ้นจากภัยพิบัติ - ไม่มีวิธีการวัด
  • นอกจากนี้ยังมีหลายคนที่ฉันคิดว่าจำเป็นต้องมีทีมงานที่มีขนาดที่ฉันจะเรียกว่า "ผู้สร้างการทำงานร่วมกัน" - ไม่ค่อยได้ผลงานสูงสุดแน่นอนพวกเขามักจะยังอยู่ในระดับสูงกว่า 20% และพวกเขาทำงานที่ทรงคุณค่า ผู้คนใหม่การเชื่อมต่อจุดต่าง ๆ และทำให้แน่ใจว่าคำถามที่ถูกต้องถูกถามและคนที่เหมาะสมถูกเก็บไว้ในลูปพวกเขาเขียน (ไม่ได้รับการถาม!) เอกสารสำคัญชิ้นหนึ่งที่ทุกคนอ้างถึงเพราะไม่ใช่แค่เอกสารที่ถูกต้องเท่านั้น มันถูกรวบรวมเข้าด้วยกันอย่างถูกวิธี หากคุณต้องการให้คน 10 คนทำงานอย่างมีประสิทธิภาพสูงสุดคุณต้องมีหนึ่งในกลุ่มคนเหล่านี้และคุณจะไม่ได้รับมันหากคุณใส่นักพัฒนาระดับสูง 10 คนไว้ในห้อง

ระบบการวัดจำนวนมากพยายามที่จะคำนึงถึงปัจจัยเหล่านี้ แต่ฉันยังไม่เห็นว่ามีสิ่งใดที่จะนำมาพิจารณาปัญหาเหล่านี้ดังนั้นฉันจึงไม่เคยประทับใจกับปัจจัยเช่น "นักพัฒนาที่ดีคือ 10X ที่มีประสิทธิภาพมากกว่า ปานกลาง "เพราะฉันต้องสงสัยว่าการวัดจริงหรือไม่สำหรับการทำงานทั้งหมดที่ต้องไปสู่ผลิตภัณฑ์ที่ประสบความสำเร็จอย่างต่อเนื่องหรือทีมที่ประสบความสำเร็จและเฟื่องฟู

ดังนั้นข้อแม้ใหญ่ของฉันคือ - คุณจะทำอะไรกับตัวชี้วัดนี้? ฉันจะใช้สิ่งนี้เพื่อให้ทราบว่าเครื่องมือและความสามารถที่เหมาะสมสามารถทำให้เกิดความแตกต่างอย่างมากในการทำงาน แต่ถ้าคุณพยายามเพิ่มประสิทธิภาพให้กับทีมที่แต่ละคนสร้าง 10X ให้ได้ผลลัพธ์ที่ "ปกติ" คุณต้องผูกมัด กรณีของความยุ่งยาก ดีกว่าคือหาวิธีทำให้ทีมของคุณทำ 2-3X สิ่งที่พวกเขาทำมาก่อนด้วยการทำงานร่วมกันให้ดีขึ้น


ฉันก็มีเช่นกัน :)
bethlakshmi

นั่นเป็นจุดที่ดีมากที่ควรเห็นได้ชัดสำหรับผู้ที่สร้างและเชื่อว่าการเรียกร้อง 10x คุณวัดผลการทำงานของโปรแกรมเมอร์อย่างไร จนกว่าเราจะสามารถทำสิ่งนั้นได้อย่างถูกต้องแม่นยำและเชื่อถือได้การกล่าวอ้างนั้นเป็นเพียงตำนาน
Jordan Rieger

มันไม่ได้เป็นตำนานดูการอ้างอิงในคำตอบอื่น ๆ จุดที่ทำที่นี่ไม่ใช่การพิสูจน์ แต่ให้ขอบเขตที่กว้างขึ้นเกี่ยวกับการผลิต
foo

10

ในหนังสือของเขาชื่อLeprechauns ของวิศวกรรมซอฟต์แวร์ Laurent Bossavit อธิบายการค้นคว้าเรื่องการเพิ่มผลิตผล 10 เท่า เขาค้นพบว่าไม่มีตัวเลขด้านหลัง - การอ้างสิทธิ์ได้เปลี่ยนจากการเก็งกำไรเป็น "ความจริงที่ยอมรับ" โดยเกมโทรศัพท์ที่มีการอ้างสิทธิ์ที่เป็นรูปธรรมมากขึ้นอย่างต่อเนื่องในการอ้างอิง โพสต์บล็อกที่ประกอบด้วยบทที่เกี่ยวกับการเรียกร้อง 10x และรวมถึงการอ้างอิงที่เกี่ยวข้องและ misquotes เป็นความจริงและชาวบ้านในวิศวกรรมซอฟต์แวร์

สิ่งที่เขาพบคือสิ่งนี้: บางคนในปี 2511 ทำการศึกษาเปรียบเทียบผู้คนที่แก้ปัญหาการแก้จุดบกพร่องโดยเฉพาะและพบว่าบางคนในนั้นเร็วกว่าคนอื่น 10 เท่า จากนี้เราสามารถสรุปได้ว่าบางคนดีกว่า 10 เท่าในการแก้ปัญหานั้นหรือเราสามารถสรุปได้ว่าบางคนโชคดีหรือมีสิ่งต่าง ๆ มากมาย บางคนเลือกที่จะอ้างถึงสิ่งนี้เพราะ (นี่คือการถอดความทั้งหมด) "การศึกษา (Sackman et al, 1968) พบว่าโปรแกรมเมอร์บางคนทำงานได้เร็วกว่าคนอื่น 10 เท่า" จากนั้นก็กลายเป็น "การศึกษาแสดงให้เห็นว่าโปรแกรมเมอร์ที่ดีนั้นดีกว่าค่าเฉลี่ย 10 เท่า" และสุดท้าย "มันเป็นความรู้ทั่วไปที่ความสามารถในการผลิตโปรแกรมเมอร์แตกต่างกันไป 10 เท่าระหว่างบุคคล" จากนั้นมีคนรวบรวมการอ้างอิงทั้งหมดเหล่านี้โดยอ้างถึงแหล่งที่มาดั้งเดิมอย่างผิด ๆ จะพูดว่า "นักวิจัยหลายคนเชื่อว่า ... "

แน่นอนว่ามันจะไม่ใช่เกมโทรศัพท์หากความจริงของการยืนยันเปลี่ยนไปเท่านั้นตัวทวีคูณไปที่ 11ขึ้นไป


ดูการสนทนาระหว่าง Bossavit และ McConnell (และคนอื่น ๆ ) ในความคิดเห็นภายใต้บทความที่ 2
DNA

2

" โปรแกรมเมอร์ที่มีประสิทธิผลในสภาพแวดล้อมนั้นเป็นผู้ที่เข้าใจและนำความต้องการของผู้ใช้ไปใช้ดีที่สุดไม่ใช่ผู้ที่สามารถเขียนรหัสที่ฉลาดที่สุดได้ " (จากคำตอบCarson63000 )

จุดสำคัญนั้นควบคู่ไปกับเบ ธ ลัคซีมีจุดสำคัญมาก นักพัฒนาที่ยอดเยี่ยมนั้นเก่งในความเป็นจริงเพียงชิ้นเดียวของเขา / เธอ แต่แตกสลายทันทีที่โลกเปลี่ยนแปลง ความสามารถในการติดตามความต้องการของธุรกิจมีความสำคัญมากกว่าสิ่งอื่นใด ในตอนท้ายของวันยกเว้นว่าธุรกิจของคุณเป็นเทคโนโลยีธุรกิจจะไม่สนใจเทคโนโลยี พวกเขาต้องการโซลูชั่น ดังนั้นการมีรูปแบบการออกแบบที่ยอดเยี่ยมจึงไม่ได้หมายถึงการหมอบอย่างเต็มที่ต่อผู้ใช้ปลายทางซึ่งต้องการเพียงแค่การถ่ายโอนข้อมูลเพื่อแสดงบนหน้าเว็บ ฉันเคยเห็นนักพัฒนาที่มีความปลอดภัยระดับปานกลางทำหน้าที่ดูแลตนเองโดยธุรกิจที่สนับสนุนพวกเขาในขณะที่นักพัฒนาที่ยอดเยี่ยมเบื่อหน่ายและเดินออกไปเพื่อค้นหาความท้าทายที่ไม่มีที่สิ้นสุด ขึ้นอยู่กับองค์กรและโครงการของคุณเป็นไปได้ที่จะเลี้ยงนักพัฒนาที่ท้าทายเหล่านี้ แต่น่าจะมีจุดในเวลาที่คุณเพิ่ง ' ไม่จำเป็นต้องใช้กำลังประมวลผลจำนวนมาก นักพัฒนาเหล่านี้ไม่ชอบนั่งเฉยๆเหมือนโปรเซสเซอร์ พวกเขาจะปิดและรีบูตที่อื่น

สุดท้ายฉันจะบอกว่ามันโอเคที่จะรู้ว่า "นักแสดง" คนสำคัญของคุณคือใคร แต่ทีม "การพัฒนา" ยังคงเป็นทีมอยู่ เพื่อย้ำถึงเบ ธ ลัคซี " คุณจะทำอย่างไรกับการวัดนี้?“ หากคุณต้องการทีมที่ทำงานเหมือนทีมฉันจะไม่มุ่งเน้นไปที่ตัวชี้วัดเช่นนี้ฉันจะรู้ว่าแม้ผู้เล่นที่เล็กที่สุดยังคงเป็นส่วนสำคัญของทีมแม้ประสิทธิภาพการทำงานของกุญแจของคุณจะลดลง 60% ผู้เล่นคนหนึ่งอาจให้บางสิ่งบางอย่างกับทีมของคุณต้องการค้นหาว่ามันคืออะไรและพยายามที่จะเพิ่มจำนวนมันอย่าทำให้ผู้เล่นคนสำคัญของคุณเบื่อถ้าคุณคิดว่าเขาควรเป็นผู้นำทีม โดยการทำให้ผู้เล่นคนอื่นปนเปื้อนด้วยความยิ่งใหญ่นั่นต้องใช้ความคิดสร้างสรรค์นิดหน่อยไม่ใช่แค่ตัวเลขในท้ายที่สุดคุณอาจเรียนรู้ว่าสิ่งที่ทำให้โปรแกรมเมอร์ที่ดีไม่ได้เป็นโปรแกรมเมอร์แม้แต่เพื่อนคนนั้นโอกาสของเขาในที่ทำงาน หรืออาจเป็นคุณก็ได้


ขอบคุณสำหรับการแก้ไข ตอนนี้ทำไมถึงลงคะแนน? เรากำลังบอกว่าพลวัตของทีมนั้นไร้ค่าในการตรวจสอบคุณค่าของนักพัฒนาและผลผลิตหรือไม่?
Draghon
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.