Calling the Shot

"การฝึกฝนคือครูที่ดีที่สุดในบรรดาครูทั้งหลาย" — พูบลิลิอุส (PUBLILIUS)

"ประสบการณ์คือครูที่ราคาแพง แต่คนโง่จะไม่เรียนรู้จากครูคนอื่นเลย" — POOR RICHARD'S ALMANAC

Douglass Crockwell, "Ruth calls his shot," เวิลด์ซีรีส์, 1932 ทำซ้ำโดยได้รับอนุญาตจากนิตยสาร Esquire และ Douglass Crockwell

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

ประการที่สอง ต้องบอกว่าข้อมูลสำหรับการสร้างโปรแกรมขนาดเล็กที่แยกส่วนกันนั้นไม่สามารถนำมาใช้กับผลิตภัณฑ์ระบบการเขียนโปรแกรม (programming systems products) ได้ ตัวอย่างเช่น สำหรับโปรแกรมที่มีขนาดเฉลี่ยประมาณ 3,200 เวิร์ด (words) Sackman, Erikson และ Grant รายงานว่าเวลาเฉลี่ยในการเขียนโค้ดและแก้ไขข้อผิดพลาด (code-plus-debug) อยู่ที่ประมาณ 178 ชั่วโมงสำหรับนักเขียนโปรแกรมคนเดียว ซึ่งเป็นตัวเลขที่จะอนุมานได้ว่ามีผลิตภาพรายปีอยู่ที่ 35,800 คำสั่งต่อปี โปรแกรมที่มีขนาดเพียงครึ่งเดียวของขนาดนั้นใช้เวลาน้อยกว่าหนึ่งในสี่ และผลิตภาพที่อนุมานได้เกือบ 80,000 คำสั่งต่อปี ต้องมีการบวกเวลาในการวางแผน การทำเอกสารประกอบ การทดสอบ การรวมระบบ และการฝึกอบรมเข้าไปด้วย การอนุมานเชิงเส้นจากตัวเลขการ "วิ่งระยะสั้น" เช่นนี้ไม่มีความหมายเลย การอนุมานเวลาจากการวิ่งระยะหนึ่งร้อยหลาจะแสดงให้เห็นว่ามนุษย์สามารถวิ่งหนึ่งไมล์ได้ในเวลาไม่ถึงสามนาที

อย่างไรก็ตาม ก่อนที่จะทิ้งตัวเลขเหล่านี้ไป ให้เราสังเกตว่าตัวเลขเหล่านั้น (แม้จะไม่ใช่สำหรับปัญหาที่เปรียบเทียบกันโดยตรง) แสดงให้เห็นว่าความพยายามนั้นเพิ่มขึ้นตามเลขยกกำลังของขนาด แม้ว่าจะไม่มีการสื่อสารใดๆ มาเกี่ยวข้องเลยก็ตาม ยกเว้นการสื่อสารของคนคนหนึ่งกับความทรงจำของตนเอง

รูปที่ 8.1 เล่าเรื่องราวที่น่าเศร้า มันแสดงให้เห็นผลลัพธ์ที่รายงานจากการศึกษาของ Nanus และ Farr ที่ System Development Corporation (SDC) ซึ่งแสดงให้เห็นเลขยกกำลังที่ 1.5 นั่นคือ:

ความพยายาม (effort) = (ค่าคงที่) x (จำนวนคำสั่ง)$^{1.5}$

การศึกษาอีกชิ้นของ SDC ที่รายงานโดย Weinwurm ก็แสดงเลขยกกำลังใกล้เคียงกับ 1.5 เช่นกัน

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

รูปที่ 8.1 ความพยายามในการเขียนโปรแกรมเป็นฟังก์ชันของขนาดโปรแกรม

Portman's Data

Charles Portman ผู้จัดการฝ่ายซอฟต์แวร์ของ ICL (Computer Equipment Organization ในแมนเชสเตอร์) ได้ให้ข้อมูลเชิงลึกที่มีประโยชน์อีกประการหนึ่ง เขาพบว่าทีมเขียนโปรแกรมของเขาพลาดกำหนดการไปประมาณครึ่งหนึ่ง—กล่าวคือ แต่ละงานใช้เวลาเกือบสองเท่าของที่ประมานการไว้ การประมานการนั้นทำอย่างระมัดระวังมาก โดยทีมที่มีประสบการณ์ได้ประมานการชั่วโมงทำงานสำหรับงานย่อยหลายร้อยงานในแผนภูมิ PERT เมื่อรูปแบบความล่าช้าปรากฏขึ้น เขาจึงขอให้พวกเขาบันทึกการใช้เวลาในแต่ละวันอย่างละเอียด

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

Aron's Data

Joel Aron ผู้จัดการฝ่ายเทคโนโลยีระบบที่ IBM ในเมืองเกเธอร์สเบิร์ก รัฐแมริแลนด์ ได้ศึกษาผลิตภาพของนักเขียนโปรแกรมเมื่อทำงานในระบบขนาดใหญ่เก้าชุด (โดยสังเขป ระบบขนาดใหญ่หมายถึงมีนักเขียนโปรแกรมมากกว่า 25 คน และคำสั่งที่ส่งมอบได้มากกว่า 30,000 คำสั่ง) เขาได้แบ่งระบบดังกล่าวตามระดับการปฏิสัมพันธ์ระหว่างนักเขียนโปรแกรม (และส่วนประกอบของระบบ) และพบผลิตภาพดังนี้:

• มีการปฏิสัมพันธ์น้อยมาก: 10,000 คำสั่งต่อหนึ่งคน-ปี
• มีการปฏิสัมพันธ์บ้าง: 5,000 คำสั่งต่อหนึ่งคน-ปี
• มีการปฏิสัมพันธ์มาก: 1,500 คำสั่งต่อหนึ่งคน-ปี

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

Harr's Data

John Harr ผู้จัดการฝ่ายเขียนโปรแกรมสำหรับระบบสลับสายอิเล็กทรอนิกส์ของ Bell Telephone ได้รายงานประสบการณ์ของเขาและผู้อื่นในบทความที่งาน 1969 Spring Joint Computer Conference ข้อมูลเหล่านี้แสดงอยู่ในรูปที่ 8.2, 8.3 และ 8.4 ในบรรดารูปเหล่านี้ รูปที่ 8.2 มีรายละเอียดมากที่สุดและมีประโยชน์ที่สุด งานสองงานแรกเป็นโปรแกรมควบคุม (control programs) พื้นฐาน ส่วนงานที่สองเป็นตัวแปลภาษา (language translators) พื้นฐาน ผลิตภาพระบุในรูปของเวิร์ดที่แก้ไขข้อผิดพลาดแล้วต่อหนึ่งคน-ปี ซึ่งรวมถึงการเขียนโปรแกรม การทดสอบส่วนประกอบ และการทดสอบระบบ แต่ยังไม่ชัดเจนว่ารวมความพยายามในการวางแผน การสนับสนุนเครื่องจักร การเขียน และอื่นๆ ไว้มากน้อยเพียงใด

โปรแกรม	จำนวนยูนิต	จำนวนนักเขียนโปรแกรม	จำนวนเวิร์ด	เวิร์ด/คน-ปี
ระบบปฏิบัติการ	50	53	52,000	511
การบำรุงรักษา	36	60	51,000	633
คอมไพเลอร์	13	9	38,000	2230
ตัวแปล (Data assembler)	15	11	25,000	2270

รูปที่ 8.2 สรุปงานโปรแกรม No. 1 ESS สี่งาน

ผลิตภาพแบ่งออกเป็นสองประเภทเช่นกัน: สำหรับโปรแกรมควบคุมอยู่ที่ประมาณ 600 เวิร์ดต่อคน-ปี สำหรับตัวแปลภาษาอยู่ที่ประมาณ 2200 เวิร์ดต่อคน-ปี สังเกตว่าโปรแกรมทั้งสี่มีขนาดใกล้เคียงกัน ความแตกต่างอยู่ที่ขนาดของกลุ่มทำงาน ระยะเวลา และจำนวนโมดูล อะไรคือเหตุและอะไรคือผล? โปรแกรมควบคุมต้องการคนมากกว่าเพราะมันซับซ้อนกว่า หรือต้องการโมดูลและคน-เดือนมากกว่าเพราะมีการรับคนเข้ามามากกว่ากัน? พวกมันใช้เวลานานกว่าเพราะความซับซ้อนที่มากกว่า หรือเพราะมีการรับคนเข้ามามากกว่ากัน? เราไม่สามารถแน่ใจได้

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

รูปที่ 8.3 อัตราการเขียนโปรแกรมที่คาดการณ์และที่เกิดขึ้นจริงของ ESS รูปที่ 8.4 อัตราการแก้ไขข้อผิดพลาดที่คาดการณ์และที่เกิดขึ้นจริงของ ESS

OS/360 Data

ประสบการณ์จาก IBM OS/360 แม้จะไม่มีรายละเอียดเท่ากับข้อมูลของ Harr แต่ก็ยืนยันข้อมูลดังกล่าว ผลิตภาพในช่วง 600-800 คำสั่งที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปีถูกพบในกลุ่มโปรแกรมควบคุม ส่วนผลิตภาพในช่วง 2,000-3,000 คำสั่งที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปีนั้นทำได้โดยกลุ่มตัวแปลภาษา ซึ่งตัวเลขเหล่านี้รวมถึงการวางแผนที่ทำโดยกลุ่ม การเขียนโค้ด การทดสอบส่วนประกอบ การทดสอบระบบ และกิจกรรมสนับสนุนบางอย่าง ข้อมูลเหล่านี้สามารถเปรียบเทียบกับข้อมูลของ Harr ได้เท่าที่ผมจะบอกได้

ข้อมูลของ Aron, Harr และ OS/360 ล้วนยืนยันถึงความแตกต่างที่น่าตกใจของผลิตภาพซึ่งสัมพันธ์กับความซับซ้อนและความยากของตัวงานเอง แนวทางของผมในเรื่องความซับซ้อนของการประมานการคือ คอมไพเลอร์มีความยากเป็นสามเท่าของโปรแกรมประยุกต์แบบแบตช์ปกติ และระบบปฏิบัติการมีความยากเป็นสามเท่าของคอมไพเลอร์

Corbató's Data

ทั้งข้อมูลของ Harr และ OS/360 เป็นการเขียนโปรแกรมด้วยภาษาแอสเซมบลี (assembly language) ดูเหมือนจะมีข้อมูลที่ได้รับการเผยแพร่เพียงเล็กน้อยเกี่ยวกับผลิตภาพของการเขียนโปรแกรมระบบด้วยภาษาระดับสูง อย่างไรก็ตาม คอร์บาโต แห่ง Project MAC ของ MIT รายงานผลิตภาพเฉลี่ย 1,200 บรรทัดของคำสั่ง PL/I ที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปี ในระบบ MULTICS (ที่มีขนาดระหว่าง 1 ถึง 2 ล้านเวิร์ด) ตัวเลขนี้มีความน่าตื่นเต้นมาก เช่นเดียวกับโครงการอื่นๆ MULTICS ประกอบด้วยโปรแกรมควบคุมและตัวแปลภาษา และมันผลิตระบบที่เป็นผลิตภัณฑ์การเขียนโปรแกรมระบบที่มีการทดสอบและทำเอกสารประกอบแล้ว ข้อมูลเหล่านี้ดูเหมือนจะสามารถเปรียบเทียบได้ในแง่ของประเภทความพยายามที่รวมไว้ และตัวเลขผลิตภาพก็เป็นค่าเฉลี่ยที่ดีระหว่างผลิตภาพของโปรแกรมควบคุมและตัวแปลภาษาของโครงการอื่นๆ

แต่ตัวเลขของคอร์บาโตคือบรรทัดต่อคน-ปี ไม่ใช่เวิร์ด! คำสั่งแต่ละคำสั่งในระบบของเขาเทียบได้กับโค้ดที่เขียนด้วยมือประมาณสามถึงห้าเวิร์ด! สิ่งนี้ชี้ให้เห็นถึงข้อสรุปที่สำคัญสองประการ:

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

Calling the Shot

"การฝึกฝนคือครูที่ดีที่สุดในบรรดาครูทั้งหลาย" — พูบลิลิอุส (PUBLILIUS)

"ประสบการณ์คือครูที่ราคาแพง แต่คนโง่จะไม่เรียนรู้จากครูคนอื่นเลย" — POOR RICHARD'S ALMANAC

Douglass Crockwell, "Ruth calls his shot," เวิลด์ซีรีส์, 1932 ทำซ้ำโดยได้รับอนุญาตจากนิตยสาร Esquire และ Douglass Crockwell

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

ประการที่สอง ต้องบอกว่าข้อมูลสำหรับการสร้างโปรแกรมขนาดเล็กที่แยกส่วนกันนั้นไม่สามารถนำมาใช้กับผลิตภัณฑ์ระบบการเขียนโปรแกรม (programming systems products) ได้ ตัวอย่างเช่น สำหรับโปรแกรมที่มีขนาดเฉลี่ยประมาณ 3,200 เวิร์ด (words) Sackman, Erikson และ Grant รายงานว่าเวลาเฉลี่ยในการเขียนโค้ดและแก้ไขข้อผิดพลาด (code-plus-debug) อยู่ที่ประมาณ 178 ชั่วโมงสำหรับนักเขียนโปรแกรมคนเดียว ซึ่งเป็นตัวเลขที่จะอนุมานได้ว่ามีผลิตภาพรายปีอยู่ที่ 35,800 คำสั่งต่อปี โปรแกรมที่มีขนาดเพียงครึ่งเดียวของขนาดนั้นใช้เวลาน้อยกว่าหนึ่งในสี่ และผลิตภาพที่อนุมานได้เกือบ 80,000 คำสั่งต่อปี ต้องมีการบวกเวลาในการวางแผน การทำเอกสารประกอบ การทดสอบ การรวมระบบ และการฝึกอบรมเข้าไปด้วย การอนุมานเชิงเส้นจากตัวเลขการ "วิ่งระยะสั้น" เช่นนี้ไม่มีความหมายเลย การอนุมานเวลาจากการวิ่งระยะหนึ่งร้อยหลาจะแสดงให้เห็นว่ามนุษย์สามารถวิ่งหนึ่งไมล์ได้ในเวลาไม่ถึงสามนาที

อย่างไรก็ตาม ก่อนที่จะทิ้งตัวเลขเหล่านี้ไป ให้เราสังเกตว่าตัวเลขเหล่านั้น (แม้จะไม่ใช่สำหรับปัญหาที่เปรียบเทียบกันโดยตรง) แสดงให้เห็นว่าความพยายามนั้นเพิ่มขึ้นตามเลขยกกำลังของขนาด แม้ว่าจะไม่มีการสื่อสารใดๆ มาเกี่ยวข้องเลยก็ตาม ยกเว้นการสื่อสารของคนคนหนึ่งกับความทรงจำของตนเอง

รูปที่ 8.1 เล่าเรื่องราวที่น่าเศร้า มันแสดงให้เห็นผลลัพธ์ที่รายงานจากการศึกษาของ Nanus และ Farr ที่ System Development Corporation (SDC) ซึ่งแสดงให้เห็นเลขยกกำลังที่ 1.5 นั่นคือ:

ความพยายาม (effort) = (ค่าคงที่) x (จำนวนคำสั่ง)$^{1.5}$

การศึกษาอีกชิ้นของ SDC ที่รายงานโดย Weinwurm ก็แสดงเลขยกกำลังใกล้เคียงกับ 1.5 เช่นกัน

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

รูปที่ 8.1 ความพยายามในการเขียนโปรแกรมเป็นฟังก์ชันของขนาดโปรแกรม

Portman's Data

Charles Portman ผู้จัดการฝ่ายซอฟต์แวร์ของ ICL (Computer Equipment Organization ในแมนเชสเตอร์) ได้ให้ข้อมูลเชิงลึกที่มีประโยชน์อีกประการหนึ่ง เขาพบว่าทีมเขียนโปรแกรมของเขาพลาดกำหนดการไปประมาณครึ่งหนึ่ง—กล่าวคือ แต่ละงานใช้เวลาเกือบสองเท่าของที่ประมานการไว้ การประมานการนั้นทำอย่างระมัดระวังมาก โดยทีมที่มีประสบการณ์ได้ประมานการชั่วโมงทำงานสำหรับงานย่อยหลายร้อยงานในแผนภูมิ PERT เมื่อรูปแบบความล่าช้าปรากฏขึ้น เขาจึงขอให้พวกเขาบันทึกการใช้เวลาในแต่ละวันอย่างละเอียด

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

Aron's Data

Joel Aron ผู้จัดการฝ่ายเทคโนโลยีระบบที่ IBM ในเมืองเกเธอร์สเบิร์ก รัฐแมริแลนด์ ได้ศึกษาผลิตภาพของนักเขียนโปรแกรมเมื่อทำงานในระบบขนาดใหญ่เก้าชุด (โดยสังเขป ระบบขนาดใหญ่หมายถึงมีนักเขียนโปรแกรมมากกว่า 25 คน และคำสั่งที่ส่งมอบได้มากกว่า 30,000 คำสั่ง) เขาได้แบ่งระบบดังกล่าวตามระดับการปฏิสัมพันธ์ระหว่างนักเขียนโปรแกรม (และส่วนประกอบของระบบ) และพบผลิตภาพดังนี้:

• มีการปฏิสัมพันธ์น้อยมาก: 10,000 คำสั่งต่อหนึ่งคน-ปี
• มีการปฏิสัมพันธ์บ้าง: 5,000 คำสั่งต่อหนึ่งคน-ปี
• มีการปฏิสัมพันธ์มาก: 1,500 คำสั่งต่อหนึ่งคน-ปี

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

Harr's Data

John Harr ผู้จัดการฝ่ายเขียนโปรแกรมสำหรับระบบสลับสายอิเล็กทรอนิกส์ของ Bell Telephone ได้รายงานประสบการณ์ของเขาและผู้อื่นในบทความที่งาน 1969 Spring Joint Computer Conference ข้อมูลเหล่านี้แสดงอยู่ในรูปที่ 8.2, 8.3 และ 8.4 ในบรรดารูปเหล่านี้ รูปที่ 8.2 มีรายละเอียดมากที่สุดและมีประโยชน์ที่สุด งานสองงานแรกเป็นโปรแกรมควบคุม (control programs) พื้นฐาน ส่วนงานที่สองเป็นตัวแปลภาษา (language translators) พื้นฐาน ผลิตภาพระบุในรูปของเวิร์ดที่แก้ไขข้อผิดพลาดแล้วต่อหนึ่งคน-ปี ซึ่งรวมถึงการเขียนโปรแกรม การทดสอบส่วนประกอบ และการทดสอบระบบ แต่ยังไม่ชัดเจนว่ารวมความพยายามในการวางแผน การสนับสนุนเครื่องจักร การเขียน และอื่นๆ ไว้มากน้อยเพียงใด

โปรแกรม	จำนวนยูนิต	จำนวนนักเขียนโปรแกรม	จำนวนเวิร์ด	เวิร์ด/คน-ปี
ระบบปฏิบัติการ	50	53	52,000	511
การบำรุงรักษา	36	60	51,000	633
คอมไพเลอร์	13	9	38,000	2230
ตัวแปล (Data assembler)	15	11	25,000	2270

รูปที่ 8.2 สรุปงานโปรแกรม No. 1 ESS สี่งาน

ผลิตภาพแบ่งออกเป็นสองประเภทเช่นกัน: สำหรับโปรแกรมควบคุมอยู่ที่ประมาณ 600 เวิร์ดต่อคน-ปี สำหรับตัวแปลภาษาอยู่ที่ประมาณ 2200 เวิร์ดต่อคน-ปี สังเกตว่าโปรแกรมทั้งสี่มีขนาดใกล้เคียงกัน ความแตกต่างอยู่ที่ขนาดของกลุ่มทำงาน ระยะเวลา และจำนวนโมดูล อะไรคือเหตุและอะไรคือผล? โปรแกรมควบคุมต้องการคนมากกว่าเพราะมันซับซ้อนกว่า หรือต้องการโมดูลและคน-เดือนมากกว่าเพราะมีการรับคนเข้ามามากกว่ากัน? พวกมันใช้เวลานานกว่าเพราะความซับซ้อนที่มากกว่า หรือเพราะมีการรับคนเข้ามามากกว่ากัน? เราไม่สามารถแน่ใจได้

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

รูปที่ 8.3 อัตราการเขียนโปรแกรมที่คาดการณ์และที่เกิดขึ้นจริงของ ESS รูปที่ 8.4 อัตราการแก้ไขข้อผิดพลาดที่คาดการณ์และที่เกิดขึ้นจริงของ ESS

OS/360 Data

ประสบการณ์จาก IBM OS/360 แม้จะไม่มีรายละเอียดเท่ากับข้อมูลของ Harr แต่ก็ยืนยันข้อมูลดังกล่าว ผลิตภาพในช่วง 600-800 คำสั่งที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปีถูกพบในกลุ่มโปรแกรมควบคุม ส่วนผลิตภาพในช่วง 2,000-3,000 คำสั่งที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปีนั้นทำได้โดยกลุ่มตัวแปลภาษา ซึ่งตัวเลขเหล่านี้รวมถึงการวางแผนที่ทำโดยกลุ่ม การเขียนโค้ด การทดสอบส่วนประกอบ การทดสอบระบบ และกิจกรรมสนับสนุนบางอย่าง ข้อมูลเหล่านี้สามารถเปรียบเทียบกับข้อมูลของ Harr ได้เท่าที่ผมจะบอกได้

ข้อมูลของ Aron, Harr และ OS/360 ล้วนยืนยันถึงความแตกต่างที่น่าตกใจของผลิตภาพซึ่งสัมพันธ์กับความซับซ้อนและความยากของตัวงานเอง แนวทางของผมในเรื่องความซับซ้อนของการประมานการคือ คอมไพเลอร์มีความยากเป็นสามเท่าของโปรแกรมประยุกต์แบบแบตช์ปกติ และระบบปฏิบัติการมีความยากเป็นสามเท่าของคอมไพเลอร์

Corbató's Data

ทั้งข้อมูลของ Harr และ OS/360 เป็นการเขียนโปรแกรมด้วยภาษาแอสเซมบลี (assembly language) ดูเหมือนจะมีข้อมูลที่ได้รับการเผยแพร่เพียงเล็กน้อยเกี่ยวกับผลิตภาพของการเขียนโปรแกรมระบบด้วยภาษาระดับสูง อย่างไรก็ตาม คอร์บาโต แห่ง Project MAC ของ MIT รายงานผลิตภาพเฉลี่ย 1,200 บรรทัดของคำสั่ง PL/I ที่แก้ไขข้อผิดพลาดแล้วต่อคน-ปี ในระบบ MULTICS (ที่มีขนาดระหว่าง 1 ถึง 2 ล้านเวิร์ด) ตัวเลขนี้มีความน่าตื่นเต้นมาก เช่นเดียวกับโครงการอื่นๆ MULTICS ประกอบด้วยโปรแกรมควบคุมและตัวแปลภาษา และมันผลิตระบบที่เป็นผลิตภัณฑ์การเขียนโปรแกรมระบบที่มีการทดสอบและทำเอกสารประกอบแล้ว ข้อมูลเหล่านี้ดูเหมือนจะสามารถเปรียบเทียบได้ในแง่ของประเภทความพยายามที่รวมไว้ และตัวเลขผลิตภาพก็เป็นค่าเฉลี่ยที่ดีระหว่างผลิตภาพของโปรแกรมควบคุมและตัวแปลภาษาของโครงการอื่นๆ

แต่ตัวเลขของคอร์บาโตคือบรรทัดต่อคน-ปี ไม่ใช่เวิร์ด! คำสั่งแต่ละคำสั่งในระบบของเขาเทียบได้กับโค้ดที่เขียนด้วยมือประมาณสามถึงห้าเวิร์ด! สิ่งนี้ชี้ให้เห็นถึงข้อสรุปที่สำคัญสองประการ:

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