Preface
คำนำฉบับครบรอบ 20 ปี
สิ่งที่ทำให้ผมประหลาดใจและดีใจเป็นอย่างมากก็คือ The Mythical Man-Month ยังคงได้รับความนิยมอย่างต่อเนื่องหลังจากผ่านมา 20 ปี มียอดพิมพ์มากกว่า 250,000 เล่ม ผู้คนมักถามว่าความคิดเห็นและคำแนะนำที่ผมเสนอไว้ในปี 1975 ข้อใดบ้างที่ผมยังยึดมั่น ข้อใดเปลี่ยนไป และเปลี่ยนไปอย่างไร แม้จะเคยตอบคำถามนี้ในการบรรยายครั้งต่าง ๆ บ้างแล้ว แต่ผมอยากเรียบเรียงมันเป็นลายลักษณ์อักษรมานานแล้ว Peter Gordon ซึ่งปัจจุบันเป็น Publishing Partner ที่ Addison-Wesley ได้ทำงานร่วมกับผมด้วยความอดทนและเป็นประโยชน์ตั้งแต่ปี 1980 เขาเสนอให้จัดทำฉบับครบรอบ เราตัดสินใจไม่แก้ไขต้นฉบับเดิม แต่พิมพ์ซ้ำโดยไม่มีการแตะต้อง (ยกเว้นการแก้ไขเล็กน้อย) แล้วเพิ่มเติมด้วยความคิดเห็นที่ทันสมัยกว่า
บทที่ 16 พิมพ์ซ้ำบทความ "No Silver Bullet: Essence and Accidents of Software Engineering" ซึ่งเป็นบทความสำหรับ IFIPS ปี 1986 ที่เติบโตมาจากประสบการณ์ที่ผมเป็นประธานการศึกษาของ Defense Science Board เกี่ยวกับซอฟต์แวร์ทางทหาร ผู้เขียนร่วมในการศึกษานั้น รวมถึงเลขานุการบริหารของเรา Robert L. Patrick มีคุณค่าอย่างยิ่งในการพาผมกลับมาสัมผัสกับโครงการซอฟต์แวร์ขนาดใหญ่ในโลกความเป็นจริง บทความดังกล่าวได้รับการพิมพ์ซ้ำในปี 1987 ในนิตยสาร IEEE Computer ซึ่งทำให้แพร่หลายอย่างกว้างขวาง
"No Silver Bullet" ได้รับการพิสูจน์ว่าเป็นบทความที่กระตุ้นให้คิด มันทำนายว่าในช่วงทศวรรษหนึ่งจะไม่มีเทคนิคการเขียนโปรแกรมใดที่จะนำมาซึ่งการปรับปรุงผลิตภาพซอฟต์แวร์ในระดับ order-of-magnitude ด้วยตัวมันเองได้ ทศวรรษนั้นเหลืออีกหนึ่งปี การทำนายของผมดูเหมือนจะปลอดภัย "NSB" ได้กระตุ้นการอภิปรายที่คึกคักมากกว่าใน The Mythical Man-Month เสียอีก ดังนั้น บทที่ 17 จึงแสดงความคิดเห็นต่อคำวิจารณ์ที่ตีพิมพ์บางส่วน และปรับปรุงความคิดเห็นที่เสนอไว้ในปี 1986
ในการเขียนบทวิจารณ์ย้อนหลังและการปรับปรุง The Mythical Man-Month ของผม ผมรู้สึกประทับใจว่ามีข้อเสนอน้อยมากในหนังสือที่ได้รับการวิจารณ์ พิสูจน์ หรือหักล้างโดยการวิจัยและประสบการณ์ด้านวิศวกรรมซอฟต์แวร์ที่ดำเนินอยู่ ผมพบว่ามีประโยชน์ที่จะรวบรวมข้อเสนอเหล่านั้นในรูปแบบดิบ โดยปราศจากข้อโต้แย้งและข้อมูลสนับสนุน ด้วยความหวังว่า
ข้อความเหล่านี้จะกระตุ้นให้มีการโต้แย้งและข้อเท็จจริงเพื่อพิสูจน์ หักล้าง ปรับปรุง หรือกลั่นกรองข้อเสนอเหล่านั้น ผมจึงได้รวมโครงร่างนี้ไว้เป็นบทที่ 18 บทที่ 19 คือบทความปรับปรุงตัวมันเอง
ผู้อ่านควรทราบว่าความคิดเห็นใหม่เหล่านี้ไม่ได้รับการสนับสนุนจากประสบการณ์จริงในสนามเท่าที่หนังสือต้นฉบับมี ผมได้ทำงานในมหาวิทยาลัย ไม่ใช่ในอุตสาหกรรม และในโครงการขนาดเล็ก ไม่ใช่โครงการขนาดใหญ่ นับตั้งแต่ปี 1986 ผมเพียงแค่สอนวิศวกรรมซอฟต์แวร์เท่านั้น ไม่ได้ทำวิจัยในนั้นเลย งานวิจัยของผมมุ่งเน้นไปที่ virtual environment และการประยุกต์ใช้ของมันมากกว่า
ในการจัดทำบทวิจารณ์ย้อนหลังนี้ ผมได้แสวงหาความคิดเห็นในปัจจุบันจากเพื่อน ๆ ที่กำลังทำงานด้านวิศวกรรมซอฟต์แวร์อยู่จริง ผมขอขอบคุณ Barry Boehm, Ken Brooks, Dick Case, James Coggins, Tom DeMarco, Jim McCarthy, David Parnas, Earl Wheeler และ Edward Yourdon สำหรับความยินดีอย่างดีเยี่ยมในการแบ่งปันความคิดเห็น แสดงความคิดเห็นต่อร่างอย่างรอบคอบ และให้ความรู้แก่ผมอีกครั้ง Fay Ward ได้จัดการการผลิตทางเทคนิคของบทใหม่ได้อย่างยอดเยี่ยม
ผมขอขอบคุณ Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, เพื่อนร่วมงานใน Defense Science Board Task Force on Military Software และโดยเฉพาะอย่างยิ่ง David Parnas สำหรับข้อมูลเชิงลึกและแนวคิดที่กระตุ้นความคิดสำหรับบทความที่พิมพ์เป็นบทที่ 16 และ Rebekah Bierly สำหรับการผลิตทางเทคนิคของบทความดังกล่าว การวิเคราะห์ปัญหาซอฟต์แวร์ออกเป็นหมวด essence และ accident ได้รับแรงบันดาลใจจาก Nancy Greenwood Brooks ซึ่งใช้การวิเคราะห์ดังกล่าวในบทความเกี่ยวกับการสอนไวโอลิน Suzuki
ธรรมเนียมของ Addison-Wesley ไม่อนุญาตให้ผมขอบคุณบทบาทสำคัญของพนักงานในคำนำฉบับปี 1975 ควรกล่าวถึงผลงานของบุคคลสองท่านเป็นพิเศษ คือ Norman Stanton อดีต Executive Editor และ Herbert Boes อดีต Art Director Boes ได้พัฒนารูปแบบที่สง่างาม ซึ่งนักวิจารณ์รายหนึ่งอ้างถึงโดยเฉพาะว่า "ขอบกระดาษกว้าง [และ] การใช้แบบอักษรและเลย์เอาต์อย่างสร้างสรรค์" ที่สำคัญยิ่งกว่านั้น เขายังให้คำแนะนำสำคัญว่าทุกบทควรมีภาพเปิดตัว (ในขณะนั้นผมมีเพียง Tar Pit และ Reims Cathedral เท่านั้น) การหาภาพเหล่านั้นทำให้ผมต้องใช้เวลาทำงานเพิ่มอีกหนึ่งปี แต่ผมรู้สึกขอบคุณคำแนะนำนั้นอย่างนิรันดร์
Soli Deo gloria — แด่พระเจ้าผู้เดียวเท่านั้นจงมีเกียรติ
F. P. B., Jr. Chapel Hill, N.C. March 1995
คำนำฉบับพิมพ์ครั้งแรก
ในหลาย ๆ ด้าน การบริหารโครงการเขียนโปรแกรมคอมพิวเตอร์ขนาดใหญ่ก็เหมือนกับการบริหารงานขนาดใหญ่อื่น ๆ — ในด้านที่มากกว่าที่นักเขียนโปรแกรมส่วนใหญ่คิด แต่ในหลาย ๆ ด้านมันก็แตกต่างออกไป — ในด้านที่มากกว่าที่ผู้บริหารมืออาชีพส่วนใหญ่คาดคิด ความรู้สะสมของสาขานี้กำลังเพิ่มขึ้นเรื่อย ๆ มีการประชุมหลายครั้ง เซสชันในการประชุม AFIPS หนังสือและบทความบางชิ้น แต่ก็ยังไม่อยู่ในรูปแบบที่เหมาะสมสำหรับการเรียบเรียงเป็นตำราเรียนอย่างเป็นระบบ อย่างไรก็ตาม ดูเหมาะสมที่จะนำเสนอหนังสือเล่มเล็กนี้ ซึ่งสะท้อนมุมมองส่วนตัวเป็นหลัก
แม้ว่าผมจะเติบโตมาจากด้านการเขียนโปรแกรมของวิทยาการคอมพิวเตอร์ แต่ผมมีส่วนร่วมหลักด้านสถาปัตยกรรมฮาร์ดแวร์ในช่วงปี (1956–1963) ที่โปรแกรมควบคุมอิสระและ compiler ภาษาระดับสูงได้รับการพัฒนา เมื่อปี 1964 ผมได้เป็นผู้จัดการ Operating System/360 ผมพบว่าโลกของการเขียนโปรแกรมเปลี่ยนแปลงไปอย่างมากจากความก้าวหน้าในช่วงไม่กี่ปีที่ผ่านมา
การบริหารการพัฒนา OS/360 เป็นประสบการณ์ที่ให้ความรู้อย่างมาก แม้จะน่าหงุดหงิดก็ตาม ทีมงาน รวมถึง F. M. Trapnell ผู้ที่สืบทอดตำแหน่งผู้จัดการต่อจากผม มีสิ่งที่ภาคภูมิใจมากมาย ระบบนี้มีความเป็นเลิศในการออกแบบและการดำเนินการหลายประการ และประสบความสำเร็จในการใช้งานอย่างแพร่หลาย แนวคิดบางอย่าง โดยเฉพาะอย่างยิ่ง device-independent input-output และการจัดการ external library เป็นนวัตกรรมทางเทคนิคที่ถูกนำไปลอกเลียนอย่างกว้างขวางในปัจจุบัน ในตอนนี้มันค่อนอย่างเชื่อถือได้ มีประสิทธิภาพพอสมควร และมีความหลากหลายสูงมาก
อย่างไรก็ตาม ความพยายามนี้ไม่อาจเรียกได้ว่าประสบความสำเร็จโดยสมบูรณ์ ผู้ใช้ OS/360 ทุกคนจะตระหนักอย่างรวดเร็วว่ามันควรจะดีกว่านี้มากเพียงใด ข้อบกพร่องในการออกแบบและการดำเนินการแพร่กระจายโดยเฉพาะใน control program ซึ่งแตกต่างจาก language compiler ข้อบกพร่องเหล่านี้ส่วนใหญ่มีต้นกำเนิดมาจากช่วงเวลาออกแบบปี 1964–65 ดังนั้นจึงต้องตกเป็นความรับผิดชอบของผม นอกจากนี้ ผลิตภัณฑ์ยังล่าช้า ใช้หน่วยความจำมากกว่าที่วางแผนไว้ ต้นทุนสูงกว่าประมาณการหลายเท่า และไม่ทำงานได้ดีมากนักจนกว่าจะผ่านไปหลาย release
หลังจากออกจาก IBM ในปี 1965 เพื่อมาที่ Chapel Hill ตามที่ตกลงไว้แต่แรกเมื่อผมรับช่วงต่อ OS/360 ผมเริ่มวิเคราะห์ประสบการณ์จาก OS/360 เพื่อดูว่าจะได้บทเรียนด้านการบริหารจัดการและเทคนิคอะไรบ้าง โดยเฉพาะอย่างยิ่ง ผมต้องการอธิบายประสบการณ์การบริหารที่แตกต่างกันอย่างมากระหว่างการพัฒนาฮาร์ดแวร์ System/360 และการพัฒนาซอฟต์แวร์ OS/360 หนังสือเล่มนี้คือคำตอบที่ล่าช้าต่อคำถามที่ Tom Watson ถามเจาะลึกถึงสาเหตุที่การเขียนโปรแกรมยากต่อการบริหารจัดการ
ในการค้นหาคำตอบนี้ ผมได้รับประโยชน์จากการสนทนายาว ๆ กับ R. P. Case ผู้ช่วยผู้จัดการปี 1964–65 และ F. M. Trapnell ผู้จัดการปี 1965–68 ผมได้เปรียบเทียบข้อสรุปกับผู้บริหารโครงการเขียนโปรแกรมขนาดยักษ์คนอื่น ๆ รวมถึง F. J. Corbato จาก M.I.T., John Harr และ V. Vyssotsky จาก Bell Telephone Laboratories, Charles Portman จาก International Computers Limited, A. P. Ershov จาก Computation Laboratory ของ Siberian Division สถาบันวิทยาศาสตร์แห่งสหภาพโซเวียต และ A. M. Pietrasanta จาก IBM
ข้อสรุปของผมเองปรากฏอยู่ในบทความที่ตามมา ซึ่งมุ่งหมายสำหรับนักเขียนโปรแกรมมืออาชีพ ผู้บริหารมืออาชีพ และโดยเฉพาะอย่างยิ่งผู้บริหารมืออาชีพของนักเขียนโปรแกรม แม้ว่าจะเขียนเป็นบทความที่แยกออกได้ แต่มีข้อโต้แย้งหลักอยู่โดยเฉพาะในบทที่ 2–7 โดยสรุปคือ ผมเชื่อว่าโครงการเขียนโปรแกรมขนาดใหญ่ประสบปัญหาการบริหารจัดการที่แตกต่างโดยธรรมชาติจากโครงการขนาดเล็ก เนื่องจากการแบ่งงาน ผมเชื่อว่าความต้องการที่สำคัญคือการรักษา conceptual integrity ของตัวผลิตภัณฑ์เอง บทเหล่านี้สำรวจทั้งความยากในการบรรลุความเป็นหนึ่งเดียวนี้และวิธีการที่จะทำให้สำเร็จ บทต่อมาสำรวจแง่มุมอื่น ๆ ของการบริหารวิศวกรรมซอฟต์แวร์
วรรณกรรมในสาขานี้ไม่ได้มีมากมาย แต่กระจัดกระจายอยู่อย่างกว้างขวาง ดังนั้นผมจึงพยายามให้เอกสารอ้างอิงที่จะทั้งให้ความกระจ่างในประเด็นเฉพาะและนำทางผู้อ่านที่สนใจไปยังงานอื่น ๆ ที่มีประโยชน์ เพื่อนมากมายอ่านต้นฉบับ และบางคนได้เตรียมความคิดเห็นที่ช่วยเหลือได้มาก ในที่ที่ดูเหมือนมีคุณค่าแต่ไม่เข้ากับการไหลของข้อความ ผมได้รวมไว้ในหมายเหตุ
เนื่องจากนี่เป็นหนังสือเรียงความและไม่ใช่ตำรา เอกสารอ้างอิงและหมายเหตุทั้งหมดจึงถูกย้ายไปไว้ท้ายเล่ม และขอแนะนำให้ผู้อ่านละเว้นมันในการอ่านครั้งแรก ผมขอขอบคุณอย่างสุดซึ้งต่อ Miss Sara Elizabeth Moore, Mr. David Wagner และ Mrs. Rebecca Burns สำหรับความช่วยเหลือในการจัดเตรียมต้นฉบับ และต่อศาสตราจารย์ Joseph C. Sloane สำหรับคำแนะนำด้านภาพประกอบ
F. P. B., Jr. Chapel Hill, N.C. October 1974