"No Silver Bullet" Refired

"กระสุนทุกลูกมีเป้าหมายของมัน" — วิลเลียมที่ 3 แห่งอังกฤษ (WILLIAM III OF ENGLAND)

"ใครก็ตามที่หวังจะได้เห็นผลงานที่ไร้ที่ติ ย่อมคิดถึงสิ่งที่ไม่มีวันเคยเป็น ไม่ได้เป็น และไม่มีวันที่จะเป็น" — อเล็กซานเดอร์ โป๊ป (ALEXANDER POPE), AN ESSAY ON CRITICISM

การประกอบโครงสร้างจากชิ้นส่วนสำเร็จรูป, 1945

On Werewolves and Other Legendary Terrors

"ไม่มีกระสุนเงิน—เนื้อแท้และส่วนประกอบภายนอกของวิศวกรรมซอฟต์แวร์" (ซึ่งตอนนี้คือบทที่ 16) เดิมทีเป็นบทความที่ได้รับเชิญให้นำเสนอในงานประชุม IFIP '86 ที่เมืองดับลิน และได้รับการตีพิมพ์ในเอกสารสรุปการประชุมนั้น นิตยสาร Computer ของ IEEE ได้นำมาพิมพ์ซ้ำโดยใช้หน้าปกสไตล์กอทิก (Gothic) พร้อมภาพประกอบจากภาพยนตร์อย่าง The Werewolf of London พวกเขายังจัดทำคอลัมน์ด้านข้างอธิบายหัวข้อ "เพื่อสังหารมนุษย์หมาป่า" (To Slay the Werewolf) โดยระบุถึงตำนาน (สมัยใหม่) ที่ว่ามีเพียงกระสุนเงินเท่านั้นที่จะปราบมันได้ ผมไม่ทราบเรื่องคอลัมน์ด้านข้างและภาพประกอบเหล่านี้ก่อนการตีพิมพ์ และไม่เคยคาดคิดว่าบทความทางเทคนิคที่จริงจังจะถูกประดับประดาด้วยสิ่งเหล่านี้

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

There is Too a Silver Bullet—AND HERE IT IS!

บทความ "ไม่มีกระสุนเงิน" ยืนยันและโต้แย้งว่า ไม่มีการพัฒนาทางวิศวกรรมซอฟต์แวร์เพียงอย่างเดียวที่จะทำให้เกิดการปรับปรุงผลิตภาพในการเขียนโปรแกรมได้ถึงสิบเท่า (order-of-magnitude) ภายในเวลาสิบปี (นับจากการตีพิมพ์ในปี 1986) ตอนนี้เราผ่านเข้าสู่ปีที่เก้าของทศวรรษนั้นแล้ว จึงเป็นเวลาที่เหมาะสมที่จะมาดูกันว่าคำทำนายนี้ยังคงเป็นจริงอยู่หรือไม่

ในขณะที่หนังสือ The Mythical Man-Month มักจะถูกนำไปอ้างอิงอยู่เสมอแต่มีการโต้แย้งน้อยมาก แต่บทความ "ไม่มีกระสุนเงิน" กลับก่อให้เกิดบทความโต้แย้ง จดหมายถึงบรรณาธิการวารสาร รวมถึงจดหมายและบทความอื่นๆ ที่ยังคงมีมาจนถึงทุกวันนี้ ส่วนใหญ่จะมุ่งโจมตีข้อโต้แย้งหลักที่ว่าไม่มีวิธีการแก้ปัญหาแบบปาฏิหาริย์ และความเห็นที่ชัดเจนของผมที่ว่ามัน "ไม่มีทาง" มีอยู่จริง หลายคนเห็นด้วยกับข้อโต้แย้งส่วนใหญ่ในบทความ แต่แล้วก็ยืนยันว่า "มี" กระสุนเงินสำหรับสัตว์ร้ายตัวนี้จริงๆ ซึ่งผู้เขียนนั่นแหละที่เป็นคนคิดค้นมันขึ้นมา

เมื่อผมได้อ่านคำตอบในช่วงแรกๆ ในตอนนี้ ผมอดไม่ได้ที่จะสังเกตว่า "ยาครอบจักรวาล" ที่ถูกผลักดันอย่างหนักในปี 1986 และ 1987 ไม่ได้ให้ผลลัพธ์ที่น่าทึ่งตามที่กล่าวอ้างเลย ผมมักจะเลือกซื้อฮาร์ดแวร์และซอฟต์แวร์โดยใช้การทดสอบ "ผู้ใช้งานที่มีความสุข" (happy user test) เป็นหลัก นั่นคือการพูดคุยกับลูกค้าที่จ่ายเงินซื้อจริงๆ และพึงพอใจกับผลิตภัณฑ์นั้น ในทำนองเดียวกัน ผมจะเชื่ออย่างสนิทใจว่ากระสุนเงินได้ปรากฏขึ้นแล้ว ก็ต่อเมื่อมีผู้ใช้งานที่เป็นอิสระจริงๆ ก้าวออกมาพูดว่า "ผมใช้ระเบียบวิธี เครื่องมือ หรือผลิตภัณฑ์นี้ และมันช่วยให้ผลิตภาพซอฟต์แวร์ของผมเพิ่มขึ้นถึงสิบเท่าจริงๆ"

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

Obscure Writing Will Be Misunderstood

นักเขียนบางคนแสดงให้เห็นว่าผมล้มเหลวในการอธิบายข้อโต้แย้งบางประการให้ชัดเจน

ส่วนประกอบภายนอก (Accident): ข้อโต้แย้งหลักของ "ไม่มีกระสุนเงิน" (NSB) ได้ถูกระบุไว้อย่างชัดเจนที่สุดเท่าที่ผมจะเขียนได้ในบทคัดย่อของบทที่ 16 อย่างไรก็ตาม บางคนสับสนกับคำว่า accident และ accidental ซึ่งผมใช้อ้างอิงตามความหมายโบราณที่ย้อนกลับไปถึงอริสโตเติล โดยคำว่า "ส่วนประกอบภายนอก" (accidental) นี้ ผมไม่ได้หมายถึงสิ่งที่เกิดขึ้นโดยบังเอิญหรือเป็นโชคร้าย แต่หมายถึงสิ่งที่ "แฝงมาด้วย" หรือเป็น "ส่วนประกอบควบคู่"

ผมไม่ได้ต้องการจะด้อยค่าส่วนที่เป็นงานภายนอกของการสร้างซอฟต์แวร์ แต่ผมยึดตามแนวทางของ Dorothy Sayers นักเขียนบทละคร นักเขียนนิยายสืบสวน และนักเทววิทยาชาวอังกฤษ ที่มองว่ากิจกรรมสร้างสรรค์ทั้งหมดประกอบด้วย (1) การสร้างโครงสร้างทางแนวคิด (conceptual constructs) (2) การนำไปใช้งานในสื่อจริง และ (3) การมีปฏิสัมพันธ์กับผู้ใช้ในการใช้งานจริง ส่วนของการสร้างซอฟต์แวร์ที่ผมเรียกว่า "เนื้อแท้" (essence) คือการประดิษฐ์โครงสร้างทางแนวคิดในระดับจิตใจ ส่วนที่ผมเรียกว่า "ส่วนประกอบภายนอก" (accident) คือกระบวนการในการนำแนวคิดนั้นไปสร้างให้เกิดขึ้นจริง

คำถามในเชิงข้อเท็จจริง (A question of fact): สำหรับผม (แม้จะไม่ใช่สำหรับทุกคน) ความถูกต้องของข้อโต้แย้งหลักสรุปได้ว่าเป็นคำถามในเชิงข้อเท็จจริงว่า: ปัจจุบันสัดส่วนของความพยายามในการสร้างซอฟต์แวร์ทั้งหมดที่เกี่ยวข้องกับการแสดงแทนโครงสร้างแนวคิดอย่างถูกต้องและเป็นระเบียบนั้นมีมากน้อยเพียงใด และสัดส่วนความพยายามในการประดิษฐ์โครงสร้างแนวคิดในจิตใจนั้นมีเท่าไหร่? การค้นหาและแก้ไขข้อบกพร่องนั้นแบ่งอยู่ในทั้งสองส่วน ขึ้นอยู่กับว่าข้อบกพร่องนั้นเป็นทางแนวคิด เช่น การลืมคำนึงถึงข้อยกเว้นบางอย่าง หรือเป็นทางเทคนิคการแสดงแทน เช่น ความผิดพลาดของตัวชี้ (pointer) หรือความผิดพลาดในการจัดสรรหน่วยความจำ

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

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

นับตั้งแต่เขียนบทความ NSB ออกไป Bruce Blum ได้ดึงความสนใจของผมไปยังผลงานปี 1959 ของ Herzberg, Mausner และ Sayderman พวกเขาพบว่า "ปัจจัยด้านแรงจูงใจ" สามารถเพิ่มผลิตภาพได้ ในทางตรงกันข้าม "ปัจจัยด้านสภาพแวดล้อมและปัจจัยภายนอก" ไม่ว่าจะเป็นไปในทางบวกเพียงใด ก็ไม่สามารถเพิ่มผลิตภาพได้ แต่ปัจจัยเหล่านี้สามารถทำให้ผลิตภาพ "ลดลง" ได้เมื่อเป็นไปในทางลบ บทความ NSB โต้แย้งว่า ความก้าวหน้าส่วนใหญ่ของซอฟต์แวร์คือการกำจัดปัจจัยลบดังกล่าว ได้แก่: ภาษาเครื่องที่ใช้งานยากอย่างน่าตกใจ, การประมวลผลแบบแบตช์ที่ใช้เวลาดำเนินการนาน, เครื่องมือที่แย่ และข้อจำกัดของหน่วยความจำที่รุนแรง

ถ้าอย่างนั้นความยากที่เป็นเนื้อแท้คือสิ่งที่สิ้นหวังอย่างนั้นหรือ? บทความที่ยอดเยี่ยมในปี 1990 โดย Brad Cox ชื่อ "มีกระสุนเงินอยู่จริง" (There Is a Silver Bullet) ได้โต้แย้งอย่างมีเหตุมีผลสำหรับแนวทางการใช้ส่วนประกอบที่นำกลับมาใช้ใหม่ได้และสับเปลี่ยนกันได้ (reusable, interchangeable component approach) ว่าเป็นการจัดการกับเนื้อแท้เชิงแนวคิดของปัญหา ซึ่งผมเห็นด้วยอย่างยิ่ง

อย่างไรก็ตาม Cox เข้าใจ NSB ผิดในสองประเด็น ประการแรก เขาอ่านมันและตีความว่าผมยืนยันว่าความยากของซอฟต์แวร์เกิดจาก "ข้อบกพร่องบางอย่างในวิธีที่นักเขียนโปรแกรมสร้างซอฟต์แวร์ในปัจจุบัน" แต่ข้อโต้แย้งของผมคือ ความยากที่เป็นเนื้อแท้นั้นมีอยู่โดยธรรมชาติในความซับซ้อนเชิงแนวคิดของฟังก์ชันซอฟต์แวร์ที่จะถูกออกแบบและสร้างขึ้นไม่ว่าจะในเวลาใดหรือด้วยวิธีการใดก็ตาม ประการที่สอง เขา (และคนอื่นๆ) ตีความ NSB ว่าผมยืนยันว่าไม่มีความหวังในการจัดการกับความยากที่เป็นเนื้อแท้ของการสร้างซอฟต์แวร์เลย นั่นไม่ใช่เจตนาของผม การประดิษฐ์โครงสร้างทางแนวคิดมีความยากที่เป็นเนื้อแท้จริง ได้แก่ ความซับซ้อน, ความสอดคล้อง, ความสามารถในการเปลี่ยนแปลง และความมองไม่เห็น อย่างไรก็ตาม ปัญหาที่เกิดจากความยากแต่ละอย่างเหล่านี้สามารถบรรเทาลงได้

ความซับซ้อนมีหลายระดับ: ตัวอย่างเช่น ความซับซ้อนคือความยากที่เป็นเนื้อแท้ที่ร้ายแรงที่สุด แต่ไม่ใช่ความซับซ้อน "ทั้งหมด" จะเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ความซับซ้อนเชิงแนวคิดส่วนมาก (แต่ไม่ใช่ทั้งหมด) ในโครงสร้างซอฟต์แวร์ของเรา มาจากความซับซ้อนตามอำเภอใจของตัวแอปพลิเคชันเอง อันที่จริง Lars Södahl จาก MYSIGMA Södahl and Partners บริษัทที่ปรึกษาด้านการบริหารจัดการข้ามชาติ เขียนไว้ว่า:

จากประสบการณ์ของผม ความซับซ้อนส่วนใหญ่ที่พบในงานด้านระบบคืออาการของความผิดปกติภายในองค์กร การพยายามจะ...

จำลองความจริงนี้ด้วยโปรแกรมที่มีความซับซ้อนเท่ากัน แท้จริงแล้วคือการรักษาความยุ่งเหยิงนั้นไว้แทนที่จะแก้ปัญหา

Steve Lukasik จาก Northrop โต้แย้งว่า แม้แต่ความซับซ้อนขององค์กรก็อาจไม่ใช่สิ่งที่เกิดขึ้นตามอำเภอใจ แต่อาจจะมีหลักการจัดระเบียบที่รองรับอยู่:

ผมได้รับการฝึกฝนมาเป็นนักฟิสิกส์ จึงมองว่าสิ่งที่ "ซับซ้อน" นั้นสามารถอธิบายได้ด้วยแนวคิดที่เรียบง่ายกว่า คราวนี้คุณอาจจะพูดถูก ผมจะไม่ยืนยันว่าสิ่งที่ซับซ้อนทั้งหมดต้องมีหลักการจัดระเบียบรองรับ... แต่ด้วยกฎเกณฑ์การโต้แย้งแบบเดียวกัน คุณก็ไม่สามารถยืนยันได้ว่ามัน "ไม่มีทาง" มีอยู่... ความซับซ้อนของเมื่อวานคือความเป็นระเบียบของวันพรุ่งนี้ ความซับซ้อนของความไร้ระเบียบในระดับโมเลกุลได้เปิดทางให้แก่ทฤษฎีจลน์ของแก๊สและกฎสามข้อของอุณหพลศาสตร์ ตอนนี้ซอฟต์แวร์อาจจะไม่เคยเผยให้เห็นหลักการจัดระเบียบประเภทนั้นเลย แต่ภาระหน้าที่ในการอธิบายว่า "ทำไมถึงไม่เป็นเช่นนั้น" ตกอยู่ที่คุณ ผมไม่ได้พยายามจะปิดกั้นหรือชอบโต้เถียง แต่ผมเชื่อว่าสักวันหนึ่ง "ความซับซ้อน" ของซอฟต์แวร์จะถูกทำเข้าใจผ่านแนวคิดในระดับที่สูงขึ้น (ซึ่งนักฟิสิกส์เรียกว่า ตัวแปรคงที่ - invariants)

ผมยังไม่ได้ทำการวิเคราะห์ในระดับลึกอย่างที่ Lukasik เรียกร้อง ซึ่งนั่นเป็นสิ่งที่ถูกต้อง ในฐานะที่เป็นสาขาวิชาหนึ่ง เราต้องการ "ทฤษฎีสารสนเทศฉบับขยาย" ที่สามารถวัดปริมาณเนื้อหาสารสนเทศของโครงสร้างที่หยุดนิ่งได้ เช่นเดียวกับที่ทฤษฎีของ Shannon ทำกับกระแสข้อมูลที่สื่อสารกัน แต่นั่นเกินความสามารถของผม สำหรับ Lukasik ผมเพียงแต่ตอบกลับไปว่า ความซับซ้อนของระบบเป็นฟังก์ชันของรายละเอียดจำนวนมหาศาลที่แต่ละอย่างต้องถูกระบุอย่างแม่นยำ ไม่ว่าจะด้วยกฎทั่วไปบางข้อหรือระบุทีละรายละเอียด แต่ต้องไม่ใช่แค่ในเชิงสถิติ มันดูไม่น่าเป็นไปได้ที่ผลงานที่ขาดการประสานงานกันของคนจำนวนมากจะมีความสอดคล้องเพียงพอที่จะถูกอธิบายได้อย่างแม่นยำด้วยกฎทั่วไป

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

• อย่างเป็นลำดับชั้น (Hierarchically) โดยใช้โมดูลหรือวัตถุที่ซ้อนกันเป็นชั้นๆ
• แบบเพิ่มส่วน (Incrementally) เพื่อให้ระบบทำงานได้อยู่เสมอ

Harel's Analysis

David Harel ในบทความปี 1992 ชื่อ "ขบกระสุนเงิน" (Biting the Silver Bullet) ได้ทำการวิเคราะห์บทความ NSB อย่างละเอียดถี่ถ้วนที่สุดเท่าที่เคยมีการตีพิมพ์มา

การมองโลกในแง่ร้าย เทียบกับ แง่ดี เทียบกับ ความเป็นจริง (Pessimism vs. optimism vs. realism): Harel มองว่าทั้งบทความ NSB และบทความปี 1984 ของ Parnas เรื่อง "แง่มุมด้านซอฟต์แวร์ของระบบป้องกันเชิงกลยุทธ์" นั้น "มืดมนเกินไป" เขาจึงตั้งใจที่จะฉายแสงให้เห็นด้านที่สดใสกว่าของเหรียญ โดยตั้งชื่อรองให้บทความของเขาว่า "สู่ทศวรรษที่สดใสกว่าสำหรับการพัฒนาระบบ" ทั้ง Cox และ Harel ต่างอ่าน NSB แล้วตีความว่ามองโลกในแง่ร้าย โดย Cox กล่าวว่า "แต่หากคุณมองข้อเท็จจริงเดียวกันนี้จากมุมมองใหม่ ข้อสรุปที่มองโลกในแง่ดีกว่าก็จะปรากฏออกมา" ทั้งคู่ต่างตีความน้ำเสียงผิดไป

ประการแรก ภรรยา เพื่อนร่วมงาน และบรรณาธิการของผมต่างพบว่าผมมักจะผิดพลาดในการ "มองโลกในแง่ดี" มากกว่าการมองในแง่ร้าย เพราะอย่างไรเสีย พื้นเพเดิมของผมคือนักเขียนโปรแกรม และการมองโลกในแง่ดีเกินไปก็คือโรคติดต่อจากอาชีพในงานฝีมือของเรา

บทความ NSB กล่าวไว้อย่างชัดเจนว่า "เมื่อเรามองไปยังขอบฟ้าในอีกทศวรรษข้างหน้า เราไม่เห็นกระสุนเงิน... อย่างไรก็ตาม ความกังขาไม่ใช่การมองโลกในแง่ร้าย... ไม่มีทางลัดที่โรยด้วยกลีบกุหลาบ แต่มีหนทางที่เดินไปได้" บทความนี้พยากรณ์ว่านวัตกรรมที่กำลังดำเนินอยู่ในปี 1986 หากได้รับการพัฒนาและนำมาใช้ จะร่วมกันสร้างการปรับปรุงผลิตภาพได้ถึงสิบเท่าจริงๆ เมื่อทศวรรษ 1986-1996 ดำเนินไป คำทำนายนี้ดูเหมือนจะ "มองโลกในแง่ดีเกินไป" เสียด้วยซ้ำมากกว่าจะดูหดหู่

ต่อให้ NSB จะถูกมองเป็นการสากลว่ามองโลกในแง่ร้าย แล้วมันผิดตรงไหน? คำกล่าวของไอน์สไตน์ที่ว่าไม่มีสิ่งใดเดินทางได้เร็วกว่าแสงนั้น "มืดมน" หรือ "หดหู่" หรือไม่? แล้วผลลัพธ์ของ Gödel ที่ว่าบางสิ่งไม่สามารถคำนวณได้ล่ะ? บทความ NSB พยายามที่จะพิสูจน์ว่า "ธรรมชาติของซอฟต์แวร์เองทำให้ไม่น่าจะเป็นไปได้ที่จะมีกระสุนเงินใดๆ" Turski ในบทความตอบโต้ที่ยอดเยี่ยมของเขาในงานประชุม IFIP ได้กล่าวไว้อย่างไพเราะว่า:

ในบรรดาความพยายามทางวิทยาศาสตร์ที่หลงทาง ไม่มีอะไรที่น่าเวทนาไปกว่าการตามหา "ศิลานักปราชญ์" (philosophers' stone) สสารที่เชื่อกันว่าสามารถเปลี่ยนโลหะฐานให้กลายเป็นทองคำได้ เป้าหมายสูงสุดของการเล่นแร่แปรธาตุ ซึ่งเป็นที่ต้องการอย่างแรงกล้า...

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

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

ทั้ง Turski และผมต่างยืนยันว่าการเพ้อฝันกลางวันขัดขวางความก้าวหน้าและทำให้เสียความพยายามไปโดยเปล่าประโยชน์

หัวข้อ "ความหดหู่" ("Gloom" themes): Harel มองว่าความหดหู่ใน NSB เกิดจากสามหัวข้อหลัก:

• การแยกส่วนอย่างชัดเจนระหว่างเนื้อแท้ (essence) และส่วนประกอบภายนอก (accident)
• การพิจารณาผู้สมัครเป็นกระสุนเงินแต่ละรายแบบแยกส่วนกัน
• การทำนายระยะเวลาเพียง 10 ปี แทนที่จะเป็นระยะเวลาที่นานพอที่จะ "คาดหวังการปรับปรุงที่สำคัญได้"

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

Glass, Vessey และ Conger ในบทความปี 1992 ได้ให้หลักฐานมากมายว่าการตามหากระสุนเงินที่ไร้ความหมายนั้นยังไม่จบสิ้น

ส่วนเรื่องการเลือก 10 ปี เทียบกับ 40 ปี เป็นระยะเวลาในการทำนายนั้น ระยะเวลาที่สั้นกว่าส่วนหนึ่งเป็นการยอมรับว่าพลังในการพยากรณ์ของเราไม่เคยดีไปกว่าหนึ่งทศวรรษเลย ใครในพวกเราเมื่อปี 1975 ที่ทำนายการปฏิวัติของไมโครคอมพิวเตอร์ในทศวรรษ 1980 ได้ถูกต้อง? ยังมีเหตุผลอื่นสำหรับขีดจำกัดสิบปี คือคำกล่าวอ้างของผู้เสนอตัวเป็นกระสุนเงินล้วนมีความ "ทันทีทันใด" อยู่ในตัว ผมไม่เคยเห็นใครพูดว่า "ลงทุนในยาครอบจักรวาลของผมสิ แล้วคุณจะเริ่มชนะหลังจากผ่านไป 10 ปี" ยิ่งไปกว่านั้น อัตราส่วนประสิทธิภาพต่อราคาของฮาร์ดแวร์ได้ปรับปรุงขึ้นประมาณร้อยเท่าต่อทศวรรษ และการเปรียบเทียบนี้ แม้จะไม่ถูกต้องนัก แต่ก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ในจิตใต้สำนึก เราจะมีความก้าวหน้าอย่างมากในช่วง 40 ปีข้างหน้าอย่างแน่นอน การปรับปรุงหนึ่งเท่าตัวในช่วง 40 ปีนั้นไม่ใช่เรื่องปาฏิหาริย์เลย

การทดลองทางความคิดของฮาเรล (Harel's thought experiment): Harel เสนอการทดลองทางความคิดโดยสมมติว่าบทความ NSB ถูกเขียนขึ้นในปี 1952 แทนที่จะเป็นปี 1986 แต่ยืนยันในข้อเสนอเดิม เขาใช้สิ่งนี้เป็นข้อโต้แย้งแบบ reducto ad absurdum เพื่อค้านการพยายามแยกเนื้อแท้ออกจากส่วนประกอบภายนอก แต่ข้อโต้แย้งนี้ไม่ได้ผล ประการแรก NSB เริ่มต้นด้วยการยืนยันว่าความยากที่เป็นส่วนประกอบภายนอกนั้นครอบงำความยากที่เป็นเนื้อแท้อย่างมากในการเขียนโปรแกรมทศวรรษ 1950 และมันไม่เป็นเช่นนั้นอีกต่อไปแล้ว และการกำจัดพวกมันออกไปได้สร้างการปรับปรุงให้ดีขึ้นได้หลายเท่าตัว การแปลข้อโต้แย้งนั้นย้อนกลับไป 40 ปีจึงเป็นเรื่องไม่สมเหตุสมผล เราแทบจินตนาการไม่ออกเลยว่าจะมีการยืนยันในปี 1952 ว่าความยากที่เป็นส่วนประกอบภายนอกไม่ได้เป็นต้นเหตุของความพยายามส่วนใหญ่

ประการที่สอง สภาพการณ์ที่ Harel จินตนาการว่าเกิดขึ้นในทศวรรษ 1950 นั้นไม่ถูกต้อง:

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

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

แต่ความเป็นจริงในทศวรรษ 1950 ไม่ใช่โปรแกรมขนาดเล็กแบบทำคนเดียว ในปี 1952 เครื่อง Univac กำลังทำงานประมวลผลสำมะโนประชากรปี 1950 ด้วยโปรแกรมที่ซับซ้อนซึ่งพัฒนาโดยคนประมาณแปดคน เครื่องจักรอื่นๆ ก็กำลังคำนวณจลนศาสตร์เคมี, การแพร่กระจายของนิวตรอน, ประสิทธิภาพของขีปนาวุธ ฯลฯ มีการใช้ตัวแอสเซมเบลอร์ ตัวเชื่อมโยงและตัวโหลดแบบย้ายตำแหน่งได้ ระบบแปลคำสั่งแบบเลขทศนิยม (floating-point interpretive systems) ฯลฯ เป็นปกติอยู่แล้ว เมื่อถึงปี 1955 ผู้คนกำลังสร้างโปรแกรมทางธุรกิจที่ต้องใช้แรงงาน 50 ถึง 100 คน-ปี ในปี 1956 General Electric มีระบบจ่ายเงินเดือนที่ใช้งานจริงในโรงงานเครื่องใช้ไฟฟ้าที่ลุยวิลล์ (Louisville) ซึ่งมีโปรแกรมมากกว่า 80,000 เวิร์ด ในปี 1957 คอมพิวเตอร์ป้องกันภัยทางอากาศ SAGE AN/FSQ-7 รันมาได้สองปีแล้ว และระบบเรียลไทม์ที่ทำงานผ่านการสื่อสารและมีระบบสำรองแบบ fail-safe ขนาด 75,000 คำสั่ง ก็เปิดใช้งานอยู่ใน 30 แห่ง เราแทบจะไม่สามารถยืนยันได้เลยว่าวิวัฒนาการของเทคนิคสำหรับโปรแกรมแบบทำคนเดียวคือสิ่งที่อธิบายถึงความพยายามของวิศวกรรมซอฟต์แวร์นับตั้งแต่ปี 1952 เป็นหลัก

และนี่คือมัน (AND HERE IT IS): Harel ยังคงนำเสนอกระสุนเงินของเขาเอง ซึ่งเป็นเทคนิคการสร้างแบบจำลองที่เรียกว่า "The Vanilla Framework" ตัวแนวทางเองไม่ได้อธิบายรายละเอียดเพียงพอที่จะประเมินได้ แต่มีการอ้างอิงถึงบทความและรายงานทางเทคนิคที่จะออกมาในรูปแบบหนังสือในเวลาที่เหมาะสม การสร้างแบบจำลองจัดการกับเนื้อแท้ คือการประดิษฐ์และการแก้ไขข้อผิดพลาดของแนวคิดที่ถูกต้อง ดังนั้นจึงมีความเป็นไปได้ที่ Vanilla Framework จะเป็นการปฏิวัติ ผมหวังว่าจะเป็นเช่นนั้น Ken Brooks รายงานว่าเขาพบว่ามันเป็นระเบียบวิธีที่มีประโยชน์เมื่อเขาลองใช้กับงานจริง

ความมองไม่เห็น (Invisibility): Harel โต้แย้งอย่างหนักแน่นว่าโครงสร้างทางแนวคิดส่วนมากของซอฟต์แวร์นั้นมีลักษณะทางโทโพโลยี (topological) โดยธรรมชาติ และความสัมพันธ์เหล่านี้มีคู่ขนานตามธรรมชาติในการแสดงแทนในเชิงพื้นที่หรือเชิงกราฟิก:

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

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

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

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

ผมชอบถามนักเขียนโปรแกรมที่มาสมัครงานมานานแล้วว่า "เดือนพฤศจิกายนปีหน้าอยู่ที่ไหน?" หากคำถามดูคลุมเครือเกินไป ผมก็จะถามว่า "เล่าเรื่องโมเดลในใจของคุณเกี่ยวกับปฏิทินให้ฟังหน่อย" นักเขียนโปรแกรมที่เก่งจริงๆ มักจะมีประสาทสัมผัสในเชิงพื้นที่ (spatial senses) ที่แข็งแกร่ง พวกเขามักจะมีโมเดลทางเรขาคณิตของเวลา และพวกเขามักจะเข้าใจคำถามแรกได้ทันทีโดยไม่ต้องอธิบายเพิ่มเติม พวกเขามีโมเดลเฉพาะตัวที่โดดเด่นมาก

Jones's Point—Productivity Follows Quality

Capers Jones ซึ่งเขียนบันทึกชุดหนึ่งและต่อมาได้รวบรวมเป็นหนังสือ ได้ให้ข้อมูลเชิงลึกที่แหลมคมซึ่งตรงกับที่ผู้เขียนจดหมายหาผมหลายคนได้กล่าวไว้ บทความ NSB ก็เหมือนกับงานเขียนส่วนใหญ่ในเวลานั้นที่มุ่งเน้นไปที่ "ผลิตภาพ" (productivity) คือปริมาณซอฟต์แวร์ที่ผลิตได้ต่อหน่วยทรัพยากรที่ใช้ แต่ Jones กล่าวว่า "ไม่เลย จงมุ่งเน้นไปที่คุณภาพ แล้วผลิตภาพจะตามมาเอง" เขาโต้แย้งว่าโครงการที่สิ้นเปลืองและล่าช้าส่วนมากทุ่มเทแรงงานและเวลาส่วนเกินไปกับการค้นหาและซ่อมแซมความผิดพลาดในข้อกำหนด ในการออกแบบ และในการนำไปใช้งาน เขาได้เสนอข้อมูลที่แสดงให้เห็นความสัมพันธ์ที่เหนียวแน่นระหว่างการขาดการควบคุมคุณภาพที่เป็นระบบกับหายนะของกำหนดการ ซึ่งผมเชื่อเช่นนั้น

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

แต่จงสังเกตว่า: เป้าหมายของการนำหลักการทางวิศวกรรมมาใช้ในการผลิตซอฟต์แวร์ในทศวรรษ 1970 คือการเพิ่มคุณภาพ ความสามารถในการทดสอบ ความเสถียร และความสามารถในการพยากรณ์ผลลัพธ์ของผลิตภัณฑ์ซอฟต์แวร์—ไม่ใช่เรื่องประสิทธิภาพของการผลิตซอฟต์แวร์เสมอไป

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

So What Has Happened to Productivity?

ตัวเลขผลิตภาพ (Productivity numbers): ตัวเลขผลิตภาพนั้นนิยามยาก วัดผลยาก และหาได้ยาก Capers Jones เชื่อว่าสำหรับโปรแกรม COBOL สองชุดที่เทียบเท่ากันซึ่งเขียนห่างกัน 10 ปี ชุดหนึ่งไม่มีระเบียบวิธีแบบโครงสร้างและอีกชุดหนึ่งมี ผลตอบแทนที่เพิ่มขึ้นคือปัจจัยสามเท่า Ed Yourdon กล่าวว่า "ผมเห็นผู้คนได้รับการปรับปรุงเพิ่มขึ้นห้าเท่าเนื่องจากเวิร์กสเตชันและเครื่องมือซอฟต์แวร์" ส่วน Tom DeMarco เชื่อว่า "ความคาดหวังของคุณต่อการปรับปรุงสิบเท่าใน 10 ปี จากชุดเทคนิคทั้งหมดนั้น เป็นการมองโลกในแง่ดีเกินไป ผมยังไม่เห็นองค์กรใดเลยที่มีการปรับปรุงถึงสิบเท่า"

ซอฟต์แวร์สำเร็จรูป—ซื้อ ไม่ใช่สร้าง (Shrink-wrapped software—Buy; don't build): การประเมินหนึ่งในปี 1986 ใน NSB ผมคิดว่าได้รับการพิสูจน์แล้วว่าถูกต้อง: "การพัฒนาของตลาดมวลชนคือ... แนวโน้มระยะยาวที่ลึกซึ้งที่สุดในวิศวกรรมซอฟต์แวร์" จากมุมมองของสายวิชาการ ซอฟต์แวร์ตลาดมวลชนเกือบจะเป็นอุตสาหกรรมใหม่เมื่อเทียบกับการพัฒนาซอฟต์แวร์แบบสั่งทำ ไม่ว่าจะทำภายในองค์กรหรือจ้างภายนอก เมื่อแพ็กเกจขายได้เป็นล้านหรือแม้แต่เป็นพันชุด คุณภาพ ความทันเวลา ประสิทธิภาพของผลิตภัณฑ์ และต้นทุนการสนับสนุนจะกลายเป็นประเด็นหลัก แทนที่จะเป็นต้นทุนการพัฒนาที่สำคัญมากสำหรับระบบสั่งทำ

เครื่องมือทรงพลังสำหรับจิตใจ (Power tools for the mind): วิธีที่น่าทึ่งที่สุดในการเพิ่มผลิตภาพของนักเขียนโปรแกรมระบบสารสนเทศเพื่อการจัดการ (MIS) คือการเดินไปที่ร้านคอมพิวเตอร์ใกล้บ้านแล้วซื้อซอฟต์แวร์สำเร็จรูปในสิ่งที่พวกเขากำลังจะสร้างขึ้นมา นี่ไม่ใช่เรื่องตลก การมีอยู่ของซอฟต์แวร์สำเร็จรูปราคาถูกและทรงพลังได้ตอบสนองความต้องการมากมายที่แต่ก่อนต้องสั่งทำแพ็กเกจเฉพาะขึ้นมา เครื่องมือทรงพลังสำหรับจิตใจเหล่านี้เปรียบเสมือนสว่านไฟฟ้า เลื่อย และเครื่องขัดกระดาษทราย มากกว่าจะเป็นเครื่องจักรผลิตขนาดใหญ่ที่ซับซ้อน การบูรณาการเครื่องมือเหล่านี้เข้าด้วยกันเป็นชุดที่เข้ากันได้และเชื่อมโยงข้ามกันได้ เช่น Microsoft Works และ ClarisWorks ที่บูรณาการได้ดีกว่า ให้ความยืดหยุ่นมหาศาล และเหมือนกับชุดเครื่องมือไฟฟ้าสำหรับเจ้าของบ้าน การใช้งานชุดเครื่องมือเล็กๆ เป็นประจำสำหรับงานที่หลากหลายจะช่วยสร้างความคุ้นเคย

เครื่องมือดังกล่าวต้องเน้นที่ความง่ายในการใช้งานสำหรับผู้ใช้ทั่วไป ไม่ใช่นักเขียนโปรแกรมมืออาชีพ Ivan Selin ประธานบริษัท American Management Systems, Inc. เขียนจดหมายถึงผมในปี 1987 ว่า:

ผมขอทักท้วงคำกล่าวของคุณที่ว่าแพ็กเกจไม่ได้เปลี่ยนไปมากนัก... ผมคิดว่าคุณมองข้ามความนัยสำคัญของข้อสังเกตที่คุณบอกว่า [แพ็กเกจซอฟต์แวร์] "อาจจะมีความเป็นสากลและปรับแต่งได้มากกว่าเมื่อก่อนบ้างแต่ไม่มากนัก" ต่อให้ยอมรับคำกล่าวนี้ตามความหมายที่เห็น แต่ผมเชื่อว่าผู้ใช้ "มองว่า" แพ็กเกจมีความเป็นสากลมากขึ้นและปรับแต่งได้ง่ายขึ้น และการรับรู้นี้เองที่ทำให้ผู้ใช้ยอมรับแพ็กเกจมากขึ้น ในกรณีส่วนใหญ่ที่บริษัทของผมพบ ผู้ใช้ปลายทาง (end users) ต่างหาก ไม่ใช่คนทำซอฟต์แวร์ ที่ลังเลจะใช้แพ็กเกจเพราะพวกเขาคิดว่าจะสูญเสียฟีเจอร์หรือฟังก์ชันที่สำคัญไป ดังนั้นความเป็นไปได้ของการปรับแต่งที่ง่ายจึงเป็นจุดขายที่สำคัญสำหรับพวกเขา

ผมคิดว่า Selin พูดถูก—ผมประเมินทั้งระดับความสามารถในการปรับแต่งของแพ็กเกจและความสำคัญของมันต่ำเกินไป

Object-Oriented Programming—Will a Brass Bullet Do?

สร้างด้วยชิ้นส่วนที่ใหญ่ขึ้น (Building with bigger pieces): ภาพประกอบตอนต้นบทนี้ย้ำเตือนเราว่า หากเราประกอบชุดของชิ้นส่วนที่แต่ละชิ้นอาจจะซับซ้อน แต่ทั้งหมดถูกออกแบบมาให้มีอินเทอร์เฟซที่ราบรื่น เราจะสามารถสร้างโครงสร้างที่รุ่มรวยได้อย่างรวดเร็ว

มุมมองหนึ่งของการเขียนโปรแกรมเชิงวัตถุคือ มันเป็นระเบียบวินัยที่บังคับให้เกิดความเป็นโมดูลและอินเทอร์เฟซที่สะอาด มุมมองที่สองเน้นไปที่การห่อหุ้ม (encapsulation) คือข้อเท็จจริงที่ว่าเราไม่สามารถมองเห็น อย่าว่าแต่จะออกแบบ โครงสร้างภายในของชิ้นส่วนเหล่านั้นได้ อีกมุมมองหนึ่งเน้นไปที่การสืบทอด (inheritance) พร้อมกับโครงสร้างคลาสแบบลำดับชั้นและฟังก์ชันเสมือน (virtual functions) และอีกมุมมองหนึ่งเน้นไปที่การระบุประเภทข้อมูลนามธรรมที่เข้มงวด (strong abstract data-typing) เพื่อรับประกันว่าประเภทข้อมูลเฉพาะเจาะจงจะถูกจัดการด้วยการดำเนินการที่เหมาะสมกับมันเท่านั้น

จริงๆ แล้ว ระเบียบวินัยเหล่านี้บางอย่างสามารถมีได้โดยไม่ต้องใช้แพ็กเกจ Smalltalk หรือ C++ ทั้งหมด—หลายอย่างมีมาก่อนเทคโนโลยีเชิงวัตถุเสียอีก ความน่าดึงดูดของแนวทางเชิงวัตถุคือมันเหมือนกับ "วิตามินรวม": คือในการเปลี่ยนผ่านเพียงครั้งเดียว (นั่นคือ การฝึกอบรมนักเขียนโปรแกรมใหม่) เราจะได้คุณสมบัติทั้งหมดนั้นมาพร้อมกัน มันจึงเป็นแนวคิดที่น่าสนใจมาก

ทำไมเทคนิคเชิงวัตถุถึงเติบโตช้า?: ในช่วงเก้าปีนับจากบทความ NSB ความคาดหวังได้เติบโตขึ้นอย่างต่อเนื่อง แต่ทำไมการเติบโตถึงล่าช้า? มีทฤษฎีมากมาย James Coggins ผู้เขียนคอลัมน์ "The Best of comp.lang.c++" ในวารสาร The C++ Report ต่อเนื่องสี่ปี ได้ให้คำอธิบายดังนี้:

ปัญหาคือเหล่านักเขียนโปรแกรมในสาย O-O มักจะทดลองในแอปพลิเคชันที่ "วนเวียนอยู่กับตัวเอง" (incestuous applications) และมุ่งเป้าไปที่ระดับนามธรรมที่ต่ำเกินไปแทนที่จะเป็นระดับสูง ตัวอย่างเช่น พวกเขาเอาแต่สร้างคลาสอย่าง linked-list หรือ set แทนที่จะสร้างคลาสอย่าง user-interface หรือ radiation beam หรือ finite-element model แต่น่าเสียดายที่การตรวจสอบประเภทข้อมูลที่เข้มงวดใน...

C++ ซึ่งช่วยให้นักเขียนโปรแกรมหลีกเลี่ยงข้อผิดพลาด ก็ยังทำให้การสร้างสิ่งที่ใหญ่จากสิ่งเล็กๆ นั้นทำได้ยากเช่นกัน

เขากลับไปที่ปัญหาพื้นฐานของซอฟต์แวร์ และโต้แย้งว่าวิธีหนึ่งในการแก้ปัญหาความต้องการซอฟต์แวร์ที่ไม่ได้รับการตอบสนอง คือการเพิ่มขนาดของกำลังคนที่มีสติปัญญาโดยการเปิดทางและดึงลูกค้าของเราเข้ามามีส่วนร่วม ซึ่งนี่คือข้อโต้แย้งสำหรับการออกแบบจากบนลงล่าง:

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

David Parnas ซึ่งบทความของเขาเป็นหนึ่งในต้นกำเนิดของแนวคิดเชิงวัตถุ มองเรื่องนี้แตกต่างออกไป เขาเขียนจดหมายถึงผมว่า:

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

ต้นทุนที่จ่ายก่อน ผลประโยชน์ที่ได้รับทีหลัง (Front-loaded costs, down-stream benefits): ความเชื่อส่วนตัวของผมคือ เทคนิคเชิงวัตถุมีลักษณะอาการรุนแรงของ "โรค" ที่มักพบในการปรับปรุงระเบียบวิธีหลายอย่าง คือต้นทุนในช่วงแรกนั้นสูงมาก—โดยหลักคือการฝึกฝนนักเขียนโปรแกรมใหม่ให้คิดในรูปแบบที่ใหม่หมดจด แต่ยังรวมถึงการลงทุนส่วนเกินในการปรับแต่งฟังก์ชันให้กลายเป็นคลาสที่เป็นสากล ผลประโยชน์ซึ่งผมคิดว่ามีอยู่จริงและไม่ใช่แค่สิ่งที่สมมติขึ้น จะเกิดขึ้นตลอดวงจรการพัฒนา แต่ผลประโยชน์มหาศาลจะคืนทุนในช่วงของการสร้างรุ่นถัดไป การขยายระบบ และการบำรุงรักษา Coggins กล่าวว่า "เทคนิคเชิงวัตถุจะไม่ทำให้การพัฒนาโครงการแรกเร็วขึ้น หรือโครงการถัดไป แต่โครงการที่ห้าในตระกูลนั้นจะไปได้เร็วอย่างสายฟ้าแลบเลยล่ะ"

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

What About Reuse?

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

แน่นอนว่านักเขียนโปรแกรมนำผลงานของตนเองกลับมาใช้ใหม่เสมอ Jones กล่าวว่า:

นักเขียนโปรแกรมที่มีประสบการณ์ส่วนใหญ่จะมีคลังส่วนตัวซึ่งช่วยให้พวกเขาพัฒนาซอฟต์แวร์โดยมีโค้ดที่นำกลับมาใช้ใหม่ได้ประมาณ 30% ของปริมาณทั้งหมด การนำกลับมาใช้ใหม่ในระดับองค์กรมุ่งเป้าไปที่ 75% และต้องมีการสนับสนุนด้านคลังข้อมูลและการบริหารจัดการเป็นพิเศษ โค้ดที่นำกลับมาใช้ใหม่ในระดับองค์กรยังหมายถึงการเปลี่ยนแปลงในระบบบัญชีโครงการและแนวทางการวัดผลเพื่อให้เครดิตกับการนำกลับมาใช้ใหม่ด้วย

W. Huang เสนอการจัดตั้งโรงงานซอฟต์แวร์ด้วยการบริหารจัดการแบบเมทริกซ์ของผู้เชี่ยวชาญตามหน้าที่ เพื่อดึงเอาความโน้มเอียงตามธรรมชาติของแต่ละคนในการนำโค้ดของตนเองกลับมาใช้ใหม่มาใช้ให้เกิดประโยชน์ Van Snyder จาก JPL ชี้ให้ผมเห็นว่าชุมชนซอฟต์แวร์ทางคณิตศาสตร์มีประเพณีการนำซอฟต์แวร์กลับมาใช้ใหม่มาอย่างยาวนาน:

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

การนำกลับมาใช้ใหม่ประสบความสำเร็จในซอฟต์แวร์ทางคณิตศาสตร์ด้วยเหตุผลสองประการ: (1) มันมีความลึกลับซับซ้อน ต้องใช้พละกำลังทางปัญญามหาศาลต่อบรรดาบรรทัดของ...

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

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

การนำกลับมาใช้ใหม่ในระดับองค์กรในปัจจุบันเป็นอย่างไรบ้าง?: มีการศึกษามากมาย แต่มีการปฏิบัติจริงค่อนข้างน้อยในสหรัฐอเมริกา และมีรายงานเป็นครั้งคราวว่ามีการนำกลับมาใช้ใหม่มากกว่าในต่างประเทศ Jones รายงานว่าลูกค้าของบริษัทเขาทุกรายที่มีนักเขียนโปรแกรมมากกว่า 5,000 คน มีการวิจัยเรื่องการนำกลับมาใช้ใหม่เป็นเรื่องเป็นราว ในขณะที่มีลูกค้าเพียงไม่ถึง 10 เปอร์เซ็นต์ของผู้ที่มีนักเขียนโปรแกรมต่ำกว่า 500 คนที่ทำเช่นนั้น เขารายงานว่าในอุตสาหกรรมที่มีศักยภาพสูงสุดในการนำกลับมาใช้ใหม่ การวิจัย (ไม่ใช่การใช้งานจริง) "เป็นไปอย่างกระตือรือร้นและเต็มไปด้วยพลัง แม้จะยังไม่ประสบความสำเร็จอย่างสมบูรณ์ก็ตาม"

Ed Yourdon รายงานถึงบริษัทซอฟต์แวร์แห่งหนึ่งในมะนิลาที่มีนักเขียนโปรแกรม 50 คนจากทั้งหมด 200 คน ทำหน้าที่สร้างโมดูลที่นำกลับมาใช้ใหม่ได้เพียงอย่างเดียวเพื่อให้คนอื่นๆ นำไปใช้ "ผมเห็นมาบ้าง—การยอมรับมาจากการปัจจัยด้านองค์กร เช่น โครงสร้างการให้รางวัล ไม่ใช่ปัจจัยทางเทคนิค" DeMarco บอกผมว่า การมีอยู่ของแพ็กเกจในตลาดมวลชนและความเหมาะสมในการทำหน้าที่ทั่วไป เช่น ระบบฐานข้อมูล ได้ช่วยลดทั้งแรงกดดันและประโยชน์ส่วนขอบของการนำโมดูลของโค้ดแอปพลิเคชันกลับมาใช้ใหม่ไปได้มาก "อย่างไรเสีย โมดูลที่นำกลับมาใช้ใหม่ได้ก็มักจะเป็นฟังก์ชันทั่วไปอยู่แล้ว" Parnas เขียนไว้ว่า:

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

Ken Brooks ให้ความเห็นเกี่ยวกับความยากในการคาดการณ์ว่าการทำให้เป็นสากลในลักษณะใดที่จะจำเป็นจริงๆ: "ผมยังคงต้องปรับแก้อะไรบางอย่างแม้ในการใช้งานครั้งที่ห้าของคลังอินเทอร์เฟซผู้ใช้ส่วนตัวของผมเอง"

การนำกลับมาใช้ใหม่จริงๆ ดูเหมือนจะเพิ่งเริ่มต้นเท่านั้น Jones รายงานว่าเริ่มมีโมดูลโค้ดที่นำกลับมาใช้ใหม่ได้สองสามตัวถูกเสนอขายในตลาดเปิดในราคาที่อยู่ระหว่าง 1 ถึง 20 เปอร์เซ็นต์ของต้นทุนการพัฒนาปกติ DeMarco กล่าวว่า:

ผมเริ่มรู้สึกท้อแท้กับปรากฏการณ์การนำกลับมาใช้ใหม่ทั้งหมด มันแทบไม่มีทฤษฎีการมีอยู่จริง (existence theorem) สำหรับการนำกลับมาใช้ใหม่เลย กาลเวลาได้ยืนยันแล้วว่ามีค่าใช้จ่ายมหาศาลในการทำให้สิ่งต่างๆ สามารถนำกลับมาใช้ใหม่ได้

Yourdon ประมานการค่าใช้จ่ายมหาศาลนั้นว่า: "กฎพื้นฐานที่ดีคือ ส่วนประกอบที่นำกลับมาใช้ใหม่ได้เช่นนี้จะต้องใช้ความพยายามเป็นสองเท่าของส่วนประกอบทั่วไป" ผมมองว่าค่าใช้จ่ายนั้นคือความพยายามในการทำให้ส่วนประกอบกลายเป็นผลิตภัณฑ์ (productizing) ดังที่ได้อภิปรายไว้ในบทที่ 1 ดังนั้นผมจึงประมานการอัตราส่วนความพยายามไว้ที่สามเท่า

ชัดเจนว่าเรากำลังเห็นการนำกลับมาใช้ใหม่ในหลายรูปแบบและหลายประเภท แต่มันยังไม่มากเท่าที่เราคาดหวังไว้ในตอนนี้ เรายังมีอะไรอีกมากที่ต้องเรียนรู้

Learning Large Vocabularies—A Predictable but Unpredicted Problem for Software Reuse

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

ในฐานะสาขาวิชาหนึ่ง เรายังไม่ได้ใคร่ครวญถึงผลกระทบของข้อเท็จจริงนี้ที่มีต่อการนำโปรแกรมกลับมาใช้ใหม่ เพื่อปรับปรุงคุณภาพและผลิตภาพ เราต้องการสร้างโปรแกรมโดยการประกอบชิ้นส่วนของฟังก์ชันที่ผ่านการแก้ไขข้อผิดพลาดแล้ว ซึ่งอยู่ในระดับที่สูงกว่าคำสั่งในภาษาโปรแกรมอย่างมาก ดังนั้น ไม่ว่าเราจะทำเช่นนี้ผ่านคลังคลาสเชิงวัตถุ (object class libraries) หรือคลังรูทีน (procedure libraries) เราต้องเผชิญกับความจริงที่ว่าเรากำลังเพิ่มขนาด "คำศัพท์ในการเขียนโปรแกรม" ของเราอย่างมหาศาล การเรียนรู้คำศัพท์นี้ถือเป็นส่วนสำคัญของอุปสรรคทางปัญญาต่อการนำกลับมาใช้ใหม่

ทุกวันนี้ผู้คนมีคลังคลาสที่มีสมาชิกมากกว่า 3,000 รายการ วัตถุหลายอย่างต้องการการระบุพารามิเตอร์และตัวแปรเสริมถึง 10 ถึง 20 ตัว ใครก็ตามที่เขียนโปรแกรมด้วยคลังข้อมูลนั้นจะต้องเรียนรู้ทั้งไวยากรณ์ (อินเทอร์เฟซภายนอก) และความหมาย (พฤติกรรมของฟังก์ชันโดยละเอียด) ของสมาชิกเหล่านั้น หากพวกเขาต้องการบรรลุศักยภาพในการนำกลับมาใช้ใหม่อย่างเต็มที่

ภารกิจนี้ยังห่างไกลจากความสิ้นหวัง เจ้าของภาษาใช้คำศัพท์มากกว่า 10,000 คำเป็นปกติอยู่แล้ว และผู้ที่มีการศึกษาจะใช้มากกว่านั้นมาก เราสามารถเรียนรู้ไวยากรณ์และความหมายที่ละเอียดอ่อนมากได้ในทางใดทางหนึ่ง เราสามารถแยกแยะความแตกต่างระหว่างคำว่า giant, huge, vast, enormous, mammoth ได้อย่างถูกต้อง คนเรามักไม่พูดถึง "ทะเลทรายที่เหมือนแมมมอธ" (mammoth deserts) หรือ "ช้างที่กว้างใหญ่ไพศาล" (vast elephants) เราต้องการการวิจัยเพื่อนำองค์ความรู้มหาศาลว่ามนุษย์เรียนรู้ภาษาได้อย่างไร มาประยุกต์ใช้กับปัญหาการนำซอฟต์แวร์กลับมาใช้ใหม่ บทเรียนบางอย่างนั้นชัดเจนทันที:

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

Net on Bullets—Position Unchanged

เราจึงกลับมาที่พื้นฐาน ความซับซ้อนคือธุรกิจที่เรากำลังทำอยู่ และความซับซ้อนคือสิ่งที่จำกัดเรา R. L. Glass เขียนไว้ในปี 1988 ซึ่งสรุปทัศนะของผมในปี 1995 ได้อย่างแม่นยำ:

สรุปแล้ว เมื่อมองย้อนกลับไป Parnas และ Brooks บอกอะไรเรา? พวกเขาบอกว่าการพัฒนาซอฟต์แวร์เป็นธุรกิจที่ยากในเชิงแนวคิด ว่าวิธีการแก้ปัญหาแบบปาฏิหาริย์ไม่ได้อยู่แค่เอื้อม ว่าถึงเวลาแล้วที่ผู้ปฏิบัติงานจะต้องพิจารณาการปรับปรุงแบบวิวัฒนาการ (evolutionary improvements) แทนที่จะรอคอย—หรือหวัง—ความก้าวหน้าแบบพลิกผัน (revolutionary ones)

บางคนในแวดวงซอฟต์แวร์พบว่านี่เป็นภาพที่น่าท้อแท้ พวกเขาคือกลุ่มคนที่ยังคงคิดว่าการก้าวข้ามขีดจำกัดครั้งใหญ่กำลังจะเกิดขึ้นในเร็วๆ นี้

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

Propositions of Mythical Man-Month: True or False?

Propositions of The Mythical Man-Month: True or False?

"ความกระชับนั้นดีมาก ไม่ว่าเราจะเป็นที่เข้าใจ หรือไม่เข้าใจก็ตาม" — แซมมวล บัตเลอร์ (SAMUEL BUTLER), Hudibras

ภาพ Brooks กำลังยืนยันข้อเสนอหนึ่ง, 1967

ทุกวันนี้เรามีความรู้เกี่ยวกับวิศวกรรมซอฟต์แวร์มากกว่าที่เคยรู้ในปี 1975 มาก ข้อความยืนยันใดในฉบับดั้งเดิมปี 1975 ที่ได้รับการสนับสนุนจากข้อมูลและประสบการณ์? ข้อไหนที่ถูกพิสูจน์แล้วว่าผิด? และข้อไหนที่ล้าสมัยไปแล้วตามโลกที่เปลี่ยนไป?

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

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