No Silver Bullet—Essence and Accident in Software Engineering
ไม่มีการพัฒนาใดเพียงอย่างเดียว ไม่ว่าจะเป็นในด้านเทคโนโลยีหรือเทคนิคการบริหารจัดการ ที่โดยตัวมันเองจะรับรองการปรับปรุงได้ถึงสิบเท่า (order-of-magnitude) ภายในทศวรรษเดียว ทั้งในด้านผลิตภาพ ความน่าเชื่อถือ หรือความเรียบง่าย
มนุษย์หมาป่าแห่งเอสเชนบัค (Eschenbach), เยอรมนี: ภาพแกะสลักเส้น, 1685
Abstract
การสร้างซอฟต์แวร์ทั้งหมดประกอบด้วยงานที่เป็น "เนื้อแท้" (essential tasks) คือการสร้างโครงสร้างทางแนวคิดที่ซับซ้อนซึ่งประกอบขึ้นเป็นตัวตนของซอฟต์แวร์ที่เป็นนามธรรม และงานที่เป็น "ส่วนประกอบภายนอก" (accidental tasks) คือการแสดงแทนตัวตนที่เป็นนามธรรมเหล่านั้นในภาษาโปรแกรม และการแมปสิ่งเหล่านั้นลงในภาษาเครื่องภายใต้ข้อจำกัดของพื้นที่และความเร็ว ความก้าวหน้าครั้งใหญ่ในผลิตภาพของซอฟต์แวร์ในอดีตส่วนมากมาจากการกำจัดอุปสรรคที่สร้างขึ้นมาเองซึ่งทำให้งานส่วนประกอบภายนอกนั้นยากเกินความจำเป็น เช่น ข้อจำกัดของฮาร์ดแวร์ที่รุนแรง ภาษาโปรแกรมที่ใช้งานยาก และการขาดแคลนเวลาของเครื่องจักร
ปัจจุบันวิศวกรซอฟต์แวร์ยังคงทุ่มเทให้กับงานส่วนประกอบภายนอกมากน้อยเพียงใดเมื่อเทียบกับงานที่เป็นเนื้อแท้? หากงานส่วนประกอบภายนอกไม่ได้กินเวลาไปมากกว่า 9 ใน 10 ของความพยายามทั้งหมด การลดเวลาของกิจกรรมส่วนประกอบภายนอกทั้งหมดให้เหลือศูนย์ก็จะไม่ทำให้เกิดการปรับปรุงขึ้นถึงสิบเท่า ดังนั้นจึงดูเหมือนว่าถึงเวลาแล้วที่จะต้องจัดการกับส่วนที่เป็นเนื้อแท้ของงานซอฟต์แวร์ ซึ่งเกี่ยวข้องกับการสร้างโครงสร้างแนวคิดนามธรรมที่มีความซับซ้อนอย่างยิ่ง ผมขอเสนอ:
-
ใช้ประโยชน์จากตลาดมวลชน (
mass market) เพื่อหลีกเลี่ยงการสร้างในสิ่งที่สามารถหาซื้อได้ -
ใช้การสร้างต้นแบบที่รวดเร็ว (
rapid prototyping) เป็นส่วนหนึ่งของการวนรอบที่วางแผนไว้ในการกำหนดข้อกำหนดของซอฟต์แวร์ - พัฒนาซอฟต์แวร์แบบออร์แกนิก โดยค่อยๆ เพิ่มหน้าที่การทำงานให้กับระบบเมื่อมีการรัน ใช้งาน และทดสอบ
- ค้นหาและพัฒนานักออกแบบแนวคิดที่ยอดเยี่ยมในคนรุ่นใหม่
Introduction
ในบรรดาสัตว์ประหลาดที่เติมเต็มฝันร้ายในตำนานพื้นบ้านของเรา ไม่มีอะไรน่าสะพรึงกลัวไปกว่า "มนุษย์หมาป่า" เพราะพวกมันสามารถกลายร่างจากสิ่งที่คุ้นเคยไปเป็นสิ่งที่สยดสยองได้อย่างไม่คาดคิด สำหรับสัตว์ประหลาดเหล่านี้ เราจึงตามหา "กระสุนเงิน" (silver bullet) ที่สามารถกำจัดพวกมันให้สิ้นซากได้ราวกับมีเวทมนตร์
โครงการซอฟต์แวร์ที่คุ้นเคยก็มีลักษณะเช่นนี้ (อย่างน้อยก็ในสายตาของผู้จัดการที่ไม่มีความรู้ทางเทคนิค) ปกติแล้วมันดูไร้เดียงสาและตรงไปตรงมา แต่สามารถกลายเป็นสัตว์ประหลาดที่ทำให้กำหนดการล่าช้า งบประมาณบานปลาย และได้ผลิตภัณฑ์ที่มีข้อบกพร่อง ดังนั้นเราจึงได้ยินเสียงร้องขอ "กระสุนเงิน" อย่างสิ้นหวัง บางสิ่งที่จะทำให้ต้นทุนซอฟต์แวร์ลดลงอย่างรวดเร็วเหมือนกับต้นทุนฮาร์ดแวร์คอมพิวเตอร์
แต่เมื่อเรามองไปยังขอบฟ้าในอีกทศวรรษข้างหน้า เราไม่เห็นกระสุนเงินนั้นเลย ไม่มีการพัฒนาใดเพียงอย่างเดียว ไม่ว่าจะเป็นด้านเทคโนโลยีหรือเทคนิคการบริหารจัดการ ที่โดยตัวมันเองจะรับรองการปรับปรุงผลิตภาพ ความน่าเชื่อถือ หรือความเรียบง่ายได้ถึงสิบเท่า ในบทนี้เราจะพยายามหาคำตอบว่า "ทำไม" โดยการตรวจสอบทั้งธรรมชาติของปัญหาซอฟต์แวร์และคุณสมบัติของกระสุนที่ถูกนำเสนอ อย่างไรก็ตาม ความกังขาไม่ใช่การมองโลกในแง่ร้าย แม้เราจะไม่เห็นความก้าวหน้าที่น่าตกใจ และเชื่อว่าความก้าวหน้าเช่นนั้นไม่สอดคล้องกับธรรมชาติของซอฟต์แวร์ แต่นวัตกรรมที่น่าส่งเสริมหลายอย่างกำลังดำเนินการอยู่ ความพยายามที่มีระเบียบและสม่ำเสมอในการพัฒนา เผยแพร่ และใช้ประโยชน์จากนวัตกรรมเหล่านั้น ควรจะให้ผลลัพธ์เป็นการปรับปรุงที่ดีขึ้นถึงสิบเท่าได้จริงๆ ไม่มีทางลัดที่โรยด้วยกลีบกุหลาบ แต่มีหนทางที่เดินไปได้
ขั้นตอนแรกสู่การจัดการกับโรคร้ายคือการแทนที่ทฤษฎีเรื่องปีศาจและทฤษฎีเรื่องธาตุเจ้าเรือนด้วย "ทฤษฎีเชื้อโรค" ขั้นตอนนั้นเองที่เป็นจุดเริ่มต้นของความหวัง แต่ในขณะเดียวกันก็ทำลายความหวังในเรื่องวิธีการแก้ปัญหาแบบปาฏิหาริย์ลงไป มันบอกกับคนทำงานว่าความก้าวหน้าจะเกิดขึ้นทีละขั้น ด้วยความพยายามอย่างมหาศาล และต้องใช้ความดูแลเอาใจใส่ที่สม่ำเสมอและไม่ย่อท้อต่อระเบียบวินัยแห่งความสะอาด วิศวกรรมซอฟต์แวร์ในปัจจุบันก็เป็นเช่นนั้น
Does It Have to Be Hard?—Essential Difficulties
ไม่เพียงแต่จะไม่มีกระสุนเงินปรากฏให้เห็นในตอนนี้เท่านั้น แต่ธรรมชาติของซอฟต์แวร์เองยังทำให้ไม่น่าจะมีนวัตกรรมใดที่สามารถสร้างผลกระทบต่อผลิตภาพ ความน่าเชื่อถือ และความเรียบง่ายของซอฟต์แวร์ได้เหมือนกับที่อิเล็กทรอนิกส์ ทรานซิสเตอร์ และการรวมวงจรขนาดใหญ่ (LSI) ทำได้กับฮาร์ดแวร์คอมพิวเตอร์ เราไม่สามารถคาดหวังว่าจะได้เห็นการปรับปรุงเพิ่มขึ้นเป็นสองเท่าในทุกๆ สองปีอีกต่อไป
ประการแรก เราต้องสังเกตว่าความผิดปกติไม่ใช่การที่ความก้าวหน้าของซอฟต์แวร์นั้นช้ามาก แต่คือการที่ความก้าวหน้าของฮาร์ดแวร์คอมพิวเตอร์นั้นเร็วมากต่างหาก ไม่มีเทคโนโลยีอื่นใดนับตั้งแต่อารยธรรมเริ่มต้นขึ้นที่ได้เห็นการปรับปรุงอัตราส่วนราคาต่อประสิทธิภาพถึงหกหลัก (orders of magnitude) ภายในเวลา 30 ปี ไม่มีเทคโนโลยีอื่นใดที่คนเราสามารถเลือกได้ว่าจะรับผลประโยชน์ในรูปแบบของประสิทธิภาพที่เพิ่มขึ้นหรือต้นทุนที่ลดลง ผลประโยชน์เหล่านี้เกิดจากการเปลี่ยนผ่านของการผลิตคอมพิวเตอร์จากอุตสาหกรรมการประกอบไปสู่อุตสาหกรรมกระบวนการ (process industry)
ประการที่สอง เพื่อให้เห็นว่าเราสามารถคาดหวังอัตราความก้าวหน้าในเทคโนโลยีซอฟต์แวร์ได้มากเพียงใด ให้เราลองพิจารณาความยากลำบากของมัน ตามแนวทางของอริสโตเติล ผมแบ่งความยากออกเป็น "เนื้อแท้" (essence) ซึ่งคือความยากที่มีอยู่โดยธรรมชาติในตัวซอฟต์แวร์ และ "ส่วนประกอบภายนอก" (accidents) ซึ่งคือความยากที่เกิดขึ้นในการผลิตซอฟต์แวร์ในปัจจุบันแต่ไม่ได้มีอยู่โดยธรรมชาติ
ผมจะพูดถึงส่วนประกอบภายนอกในหัวข้อถัดไป ก่อนอื่นให้เราพิจารณาเรื่องเนื้อแท้กันก่อน
เนื้อแท้ของตัวตนซอฟต์แวร์คือโครงสร้างของแนวคิดที่เชื่อมโยงกัน: ได้แก่ ชุดข้อมูล ความสัมพันธ์ระหว่างรายการข้อมูล อัลกอริทึม และการเรียกใช้ฟังก์ชัน เนื้อแท้นี้เป็นนามธรรม ในแง่ที่ว่าโครงสร้างแนวคิดจะยังคงเหมือนเดิมภายใต้รูปแบบการแสดงแทนที่แตกต่างกันมากมาย กระนั้นมันก็มีความแม่นยำสูงและมีรายละเอียดที่ซับซ้อน ผมเชื่อว่าส่วนที่ยากที่สุดของการสร้างซอฟต์แวร์คือการกำหนดข้อกำหนด (specification) การออกแบบ และการทดสอบโครงสร้างแนวคิดนี้ ไม่ใช่แรงงานในการแสดงแทนมันออกมาและทดสอบความถูกต้องของการแสดงแทนนั้น แน่นอนว่าเรายังคงทำผิดทางไวยากรณ์ (syntax errors) อยู่บ้าง แต่นั่นเป็นเพียงเรื่องเล็กน้อยเมื่อเทียบกับความผิดพลาดทางแนวคิด (conceptual errors) ในระบบส่วนใหญ่
หากเรื่องนี้เป็นจริง การสร้างซอฟต์แวร์ก็จะยังคงเป็นงานที่ยากเสมอไป โดยเนื้อแท้แล้วมันจะไม่มีกระสุนเงิน
ให้เราพิจารณาคุณสมบัติที่มีอยู่โดยธรรมชาติของเนื้อแท้ที่ไม่อาจลดทอนได้ของระบบซอฟต์แวร์สมัยใหม่: ความซับซ้อน (complexity), ความสอดคล้อง (conformity), ความสามารถในการเปลี่ยนแปลง (changeability) และความมองไม่เห็น (invisibility)
ความซับซ้อน (Complexity): ตัวตนซอฟต์แวร์มีความซับซ้อนมากกว่าสิ่งก่อสร้างอื่นใดของมนุษย์เมื่อเทียบกับขนาดของมัน เพราะไม่มีส่วนประกอบสองส่วนใดที่เหมือนกันทุกประการ (อย่างน้อยก็ในระดับที่เหนือกว่าคำสั่งโปรแกรมขึ้นไป) หากมันเหมือนกัน เราก็จะรวมส่วนที่คล้ายกันสองส่วนนั้นเข้าเป็นหนึ่งเดียว คือเป็นรูทีนย่อย (subroutine) ทั้งแบบเปิดหรือปิด ในแง่นี้ระบบซอฟต์แวร์จึงแตกต่างอย่างสิ้นเชิงจากคอมพิวเตอร์ อาคาร หรือรถยนต์ ซึ่งมีองค์ประกอบที่ซ้ำกันอยู่มากมาย
คอมพิวเตอร์ดิจิทัลนั้นมีความซับซ้อนมากกว่าสิ่งของส่วนใหญ่ที่มนุษย์สร้างขึ้นอยู่แล้ว พวกมันมีจำนวนสถานะ (states) ที่มหาศาล ซึ่งทำให้การจินตนาการ การอธิบาย และการทดสอบพวกมันเป็นเรื่องยาก แต่ระบบซอฟต์แวร์มีจำนวนสถานะมากกว่าคอมพิวเตอร์ถึงหลายหลัก (orders of magnitude) ในทำนองเดียวกัน การขยายขนาดของตัวตนซอฟต์แวร์ไม่ใช่เพียงการทำซ้ำองค์ประกอบเดิมในขนาดที่ใหญ่ขึ้น แต่มันคือการเพิ่มจำนวนขององค์ประกอบที่ "แตกต่างกัน" อย่างหลีกเลี่ยงไม่ได้ ในกรณีส่วนใหญ่องค์ประกอบเหล่านี้จะมีปฏิสัมพันธ์ต่อกันในรูปแบบที่ไม่เป็นเส้นตรง (nonlinear) และความซับซ้อนของภาพรวมทั้งหมดก็จะเพิ่มขึ้นมากกว่าสัดส่วนที่เป็นเส้นตรงอย่างมาก
ความซับซ้อนของซอฟต์แวร์คือคุณสมบัติที่เป็นเนื้อแท้ ไม่ใช่ส่วนประกอบภายนอก ดังนั้นคำอธิบายใดๆ ของตัวตนซอฟต์แวร์ที่ละทิ้งความซับซ้อนของมันไป มักจะเท่ากับการละทิ้งเนื้อแท้ของมันไปด้วย คณิตศาสตร์และวิทยาศาสตร์กายภาพมีความก้าวหน้าอย่างมากตลอดสามศตวรรษที่ผ่านมาด้วยการสร้างแบบจำลองที่เรียบง่ายของปรากฏการณ์ที่ซับซ้อน อนุมานคุณสมบัติต่างๆ จากแบบจำลองเหล่านั้น และตรวจสอบคุณสมบัติเหล่านั้นด้วยการทดลอง วิธีนี้ใช้ได้ผลเพราะความซับซ้อนที่ถูกละทิ้งไปในแบบจำลองไม่ใช่คุณสมบัติที่เป็นเนื้อแท้ของปรากฏการณ์นั้น แต่วิธีนี้จะใช้ไม่ได้ผลเมื่อความซับซ้อนคือเนื้อแท้
ปัญหาคลาสสิกหลายประการในการพัฒนาผลิตภัณฑ์ซอฟต์แวร์เกิดจากความซับซ้อนที่เป็นเนื้อแท้นี้ และการเพิ่มขึ้นแบบไม่เป็นเส้นตรงตามขนาด จากความซับซ้อนนำไปสู่ความยากลำบากในการสื่อสารระหว่างสมาชิกในทีม ซึ่งนำไปสู่ข้อบกพร่องของผลิตภัณฑ์ ต้นทุนที่บานปลาย และกำหนดการที่ล่าช้า จากความซับซ้อนนำไปสู่ความยากในการระบุสถานะที่เป็นไปได้ทั้งหมดของโปรแกรม (อย่าว่าแต่การจะทำความเข้าใจสถานะเหล่านั้นเลย) และจากจุดนั้นก็นำไปสู่ความไม่น่าเชื่อถือ จากความซับซ้อนของฟังก์ชันนำไปสู่ความยากในการเรียกใช้ฟังก์ชันเหล่านั้น ซึ่งทำให้โปรแกรมใช้งานยาก จาก...
ความซับซ้อนของโครงสร้างนำไปสู่ความยากในการขยายโปรแกรมให้รองรับฟังก์ชันใหม่โดยไม่ให้เกิดผลข้างเคียง จากความซับซ้อนของโครงสร้างนำไปสู่สถานะที่คาดไม่ถึงซึ่งกลายเป็นช่องโหว่ด้านความปลอดภัย ไม่เพียงแต่ปัญหาทางเทคนิคเท่านั้น แต่ปัญหาด้านการบริหารจัดการก็มาจากความซับซ้อนนี้เช่นกัน ความซับซ้อนทำให้ยากต่อการมองเห็นภาพรวม จึงขัดขวางความสอดคล้องทางแนวคิด มันทำให้ยากต่อการค้นหาและควบคุมรายละเอียดที่ตกหล่นอยู่ มันสร้างภาระมหาศาลในการเรียนรู้และทำความเข้าใจ จนทำให้การเปลี่ยนถ่ายบุคลากรกลายเป็นหายนะ
ความสอดคล้อง (Conformity): คนในสายงานซอฟต์แวร์ไม่ใช่กลุ่มเดียวที่ต้องเผชิญกับความซับซ้อน นักฟิสิกส์ต้องจัดการกับวัตถุที่ซับซ้อนอย่างยิ่งแม้แต่ในระดับอนุภาคพื้นฐาน อย่างไรก็ตาม นักฟิสิกส์ยังคงทำงานต่อไปด้วยความเชื่อมั่นอันแรงกล้าว่ามีหลักการที่เป็นเอกภาพให้ค้นพบ ไม่ว่าจะเป็นในควาร์กหรือในทฤษฎีสนามรวม ไอน์สไตน์เคยโต้แย้งซ้ำๆ ว่าธรรมชาติจะต้องมีคำอธิบายที่เรียบง่าย เพราะพระเจ้าไม่ได้ทรงทำอะไรตามอำเภอใจหรือไร้เหตุผล
ไม่มีความเชื่อเช่นนั้นมาปลอบประโลมวิศวกรซอฟต์แวร์ ความซับซ้อนส่วนใหญ่ที่เขาต้องเอาชนะคือ "ความซับซ้อนตามอำเภอใจ" (arbitrary complexity) ที่ถูกบังคับโดยไม่มีเหตุผลจากสถาบันและระบบต่างๆ ของมนุษย์ที่อินเทอร์เฟซของเขาต้องไปสอดคล้องด้วย สิ่งเหล่านี้แตกต่างกันไปตามแต่ละอินเทอร์เฟซ และเปลี่ยนไปตามกาลเวลา ไม่ใช่เพราะความจำเป็น แต่เป็นเพราะพวกมันถูกออกแบบโดยคนละคนกัน ไม่ได้ถูกออกแบบโดยพระเจ้า ในหลายกรณีซอฟต์แวร์ต้องยอมสอดคล้องเพราะมันมาถึงทีหลังสุด ในกรณีอื่นๆ มันต้องสอดคล้องเพราะมันถูกมองว่าเป็นสิ่งที่ "ยอมตามได้ง่ายที่สุด" แต่ในทุกกรณี ความซับซ้อนส่วนมากเกิดจากการต้องปรับตัวให้เข้ากับอินเทอร์เฟซอื่นๆ ซึ่งไม่สามารถทำให้เรียบง่ายลงได้ด้วยการออกแบบซอฟต์แวร์ใหม่เพียงอย่างเดียว
ความสามารถในการเปลี่ยนแปลง (Changeability): ตัวตนซอฟต์แวร์ต้องเผชิญกับแรงกดดันให้เปลี่ยนแปลงอยู่ตลอดเวลา แน่นอนว่าอาคาร รถยนต์ หรือคอมพิวเตอร์ก็เช่นกัน แต่สิ่งของที่ผ่านกระบวนการผลิตมาแล้วมักจะมีการเปลี่ยนแปลงไม่บ่อยนักหลังจากผลิตเสร็จ พวกมันจะถูกแทนที่ด้วยรุ่นใหม่กว่า หรือมีการปรับปรุงสำคัญในสินค้าลอตถัดๆ ไปของงานออกแบบพื้นฐานเดิม การเรียกคืนรถยนต์นั้นเกิดขึ้นไม่บ่อยนัก การเปลี่ยนชิ้นส่วนฮาร์ดแวร์คอมพิวเตอร์ในหน้างานก็น้อยยิ่งกว่า ทั้งสองอย่างนี้เกิดขึ้นน้อยกว่าการแก้ไขซอฟต์แวร์ที่ถูกนำไปใช้งานแล้วอย่างมาก ส่วนหนึ่งเป็นเพราะซอฟต์แวร์ในระบบคือสิ่งที่รวบรวมฟังก์ชันการทำงานเอาไว้ และฟังก์ชันคือส่วนที่ได้รับแรงกดดันจากการเปลี่ยนแปลงมากที่สุด อีกส่วนหนึ่งเป็นเพราะซอฟต์แวร์สามารถเปลี่ยนแปลงได้ง่ายกว่า—เพราะมันเป็นผลิตผลทางความคิดบริสุทธิ์...
สามารถปรับเปลี่ยนได้ไม่สิ้นสุด อันที่จริงอาคารก็มีการเปลี่ยนแปลง แต่ต้นทุนการเปลี่ยนแปลงที่สูงซึ่งทุกคนเข้าใจกันดี ช่วยยับยั้งความต้องการเปลี่ยนตามอำเภอใจของผู้เปลี่ยนได้ แต่ซอฟต์แวร์ที่ประสบความสำเร็จทุกตัวต้องถูกเปลี่ยนเสมอ โดยมีสองกระบวนการที่ทำงานอยู่: เมื่อผลิตภัณฑ์ซอฟต์แวร์ถูกพบว่ามีประโยชน์ ผู้คนจะพยายามนำมันไปใช้ในกรณีใหม่ๆ ที่ขอบเขตหรือนอกเหนือไปจากโดเมนดั้งเดิม แรงกดดันในการขยายฟังก์ชันการทำงานส่วนใหญ่มาจากผู้ใช้ที่ชอบฟังก์ชันพื้นฐานและคิดค้นการใช้งานใหม่ๆ ให้กับมัน
ประการที่สอง ซอฟต์แวร์ที่ประสบความสำเร็จจะอยู่รอดเกินอายุการใช้งานปกติของเครื่องจักรที่เป็นพาหนะซึ่งมันถูกเขียนขึ้นเพื่อใช้งานในตอนแรก หากไม่ใช้คอมพิวเตอร์เครื่องใหม่ อย่างน้อยก็จะมีดิสก์ใหม่ จอภาพใหม่ เครื่องพิมพ์ใหม่ตามมา และซอฟต์แวร์ต้องถูกปรับให้สอดคล้องกับพาหนะใหม่ที่เป็นโอกาสเหล่านี้ กล่าวโดยสรุป ผลิตภัณฑ์ซอฟต์แวร์ถูกฝังอยู่ในเมทริกซ์ทางวัฒนธรรมของแอปพลิเคชัน ผู้ใช้ กฎหมาย และเครื่องจักรพาหนะ สิ่งเหล่านี้ล้วนเปลี่ยนแปลงอยู่ตลอดเวลา และการเปลี่ยนแปลงของพวกมันก็บังคับให้ผลิตภัณฑ์ซอฟต์แวร์ต้องเปลี่ยนตามอย่างไม่อาจหลีกเลี่ยงได้
ความมองไม่เห็น (Invisibility): ซอฟต์แวร์เป็นสิ่งที่มองไม่เห็นและเป็นนามธรรมทางเรขาคณิต ซึ่งปกติแล้วการเป็นนามธรรมทางเรขาคณิตเป็นเครื่องมือที่ทรงพลังมาก ผังพื้นของอาคารช่วยให้ทั้งสถาปนิกและลูกค้าประเมินพื้นที่ การไหลเวียนของการสัญจร และมุมมองได้ ความขัดแย้งจะปรากฏชัดเจน และจุดที่ตกหล่นไปจะสามารถตรวจพบได้ ภาพร่างตามมาตราส่วนของชิ้นส่วนเครื่องกล และโมเดลโครงร่างของโมเลกุล แม้จะเป็นนามธรรม แต่ก็ตอบสนองวัตถุประสงค์เดียวกัน คือความจริงทางเรขาคณิตถูกบันทึกไว้ในการเป็นนามธรรมทางเรขาคณิต
ความจริงของซอฟต์แวร์ไม่ได้ถูกฝังอยู่ในอวกาศโดยธรรมชาติ ดังนั้นมันจึงไม่มีการแสดงแทนทางเรขาคณิตที่พร้อมใช้งาน เหมือนที่ดินมีแผนที่ แผ่นซิลิคอนมีไดอะแกรม หรือคอมพิวเตอร์มีแผนผังการเชื่อมต่อ ทันทีที่เราพยายามทำไดอะแกรมโครงสร้างซอฟต์แวร์ เราจะพบว่ามันไม่ได้ประกอบด้วยกราฟระบุทิศทางเพียงอันเดียว แต่มีหลายอันซ้อนทับกัน กราฟหลายชุดนั้นอาจแสดงถึงทิศทางของการควบคุม (flow of control) ทิศทางของข้อมูล รูปแบบของการพึ่งพากัน ลำดับเวลา หรือความสัมพันธ์ของเนมสเปซ (name-space relationships) สิ่งเหล่านี้มักจะไม่ใช่รูปทรงระนาบ (planar) อย่าว่าแต่จะเป็นลำดับชั้น (hierarchical) เลย อันที่จริง วิธีหนึ่งในการสร้างการควบคุมเชิงแนวคิดเหนือโครงสร้างดังกล่าวคือการบังคับให้ตัดการเชื่อมโยงออก จนกว่ากราฟชุดหนึ่งหรือมากกว่านั้นจะกลายเป็นลำดับชั้น
แม้จะมีความก้าวหน้าในการจำกัดและทำให้โครงสร้างซอฟต์แวร์เรียบง่ายลง แต่มันก็ยังคงเป็นสิ่งที่ไม่สามารถสร้างภาพในจินตนาการได้โดยธรรมชาติ ซึ่งทำให้จิตใจขาดเครื่องมือทางแนวคิดที่ทรงพลังที่สุดบางอย่างไป การขาดสิ่งนี้ไม่เพียงแต่ขัดขวางกระบวนการออกแบบภายในจิตใจดวงเดียว แต่มันยังขัดขวางการสื่อสารระหว่างจิตใจหลายดวงอย่างรุนแรงอีกด้วย
Past Breakthroughs Solved Accidental Difficulties
หากเราตรวจสอบขั้นตอนสำคัญสามประการในเทคโนโลยีซอฟต์แวร์ที่ให้ผลตอบแทนคุ้มค่าที่สุดในอดีต เราจะพบว่าแต่ละขั้นตอนมุ่งจัดการกับความยากลำบากหลักที่แตกต่างกันในการสร้างซอฟต์แวร์ แต่มันล้วนเป็นความยากที่เป็นส่วนประกอบภายนอก (accidental difficulties) ไม่ใช่ความยากที่เป็นเนื้อแท้ (essential difficulties) นอกจากนี้เรายังสามารถเห็นขีดจำกัดตามธรรมชาติของการขยายผลจากความก้าวหน้าแต่ละอย่างเหล่านั้นด้วย
ภาษาระดับสูง (High-level languages): แน่นอนว่าเครื่องมือที่ทรงพลังที่สุดสำหรับผลิตภาพ ความน่าเชื่อถือ และความเรียบง่ายของซอฟต์แวร์ คือการใช้ภาษาระดับสูงในการเขียนโปรแกรมอย่างต่อเนื่อง ผู้สังเกตการณ์ส่วนใหญ่ให้เครดิตการพัฒนานี้ว่าช่วยเพิ่มผลิตภาพได้อย่างน้อยห้าเท่า พร้อมกับความน่าเชื่อถือ ความเรียบง่าย และความเข้าใจที่เพิ่มขึ้นตามมา ภาษาระดับสูงทำอะไรได้สำเร็จ? มันช่วยปลดปล่อยโปรแกรมจากความซับซ้อนที่เป็นส่วนประกอบภายนอกจำนวนมาก โปรแกรมในเชิงนามธรรมประกอบด้วยโครงสร้างทางแนวคิด ได้แก่ การดำเนินการ ประเภทข้อมูล ลำดับขั้นตอน และการสื่อสาร ส่วนโปรแกรมในระดับเครื่องจักรจริงๆ จะเกี่ยวข้องกับ บิต, รีจิสเตอร์, เงื่อนไข, การแตกแขนง, ช่องสัญญาณ, ดิสก์ และอื่นๆ ตราบเท่าที่ภาษาระดับสูงรวบรวมโครงสร้างที่ต้องการในโปรแกรมเชิงนามธรรมเอาไว้ และหลีกเลี่ยงสิ่งที่อยู่ในระดับต่ำกว่าทั้งหมด มันจะช่วยกำจัดระดับของความซับซ้อนทั้งหมดที่ไม่ได้มีอยู่โดยเนื้อแท้ในโปรแกรมออกไปได้
สิ่งที่ภาษาระดับสูงสามารถทำได้มากที่สุดคือการจัดเตรียมโครงสร้างทั้งหมดที่นักเขียนโปรแกรมจินตนาการไว้ในโปรแกรมเชิงนามธรรม แน่นอนว่าระดับความซับซ้อนในการคิดของเราเกี่ยวกับโครงสร้างข้อมูล ประเภทข้อมูล และการดำเนินการนั้นกำลังเพิ่มขึ้นอย่างต่อเนื่อง แต่อยู่ในอัตราที่ลดลงเรื่อยๆ และการพัฒนาภาษาเข้าใกล้ระดับความซับซ้อนของผู้ใช้มากขึ้นเรื่อยๆ ยิ่งไปกว่านั้น ณ จุดหนึ่ง การลงรายละเอียดที่มากเกินไปของภาษาระดับสูงกลับกลายเป็นภาระที่เพิ่มขึ้น แทนที่จะลดภาระทางปัญญาของผู้ใช้ที่แทบไม่ได้ใช้โครงสร้างที่ซับซ้อนเหล่านั้นเลย
การแบ่งเวลา (Time-sharing): ผู้สังเกตการณ์ส่วนใหญ่ให้เครดิตการแบ่งเวลาว่าช่วยปรับปรุงผลิตภาพของนักเขียนโปรแกรมและคุณภาพของผลิตภัณฑ์ได้อย่างมาก แม้จะไม่มากเท่ากับสิ่งที่ภาษาระดับสูงทำได้ การแบ่งเวลาช่วยจัดการกับความยากลำบากที่แตกต่างออกไป คือมันรักษาความ "ต่อเนื่องทันที" (immediacy) และช่วยให้เราสามารถรักษาภาพรวมของความซับซ้อนไว้ได้ เวลาดำเนินการ (turnaround) ที่ช้าของการเขียนโปรแกรมแบบแบตช์หมายความว่าเราจะลืมรายละเอียดเล็กๆ น้อยๆ หรือแม้แต่ทิศทางหลักของสิ่งที่เรากำลังคิดเมื่อตอนที่เราหยุดเขียนโปรแกรมเพื่อสั่งคอมไพล์และรัน การขัดจังหวะความต่อเนื่องของความคิดนี้มีต้นทุนเป็นเวลา เพราะเราต้องรื้อฟื้นความทรงจำใหม่ ผลกระทบที่ร้ายแรงที่สุดอาจเป็นการสูญเสียความเข้าใจในภาพรวมของสิ่งที่เกิดขึ้นในระบบที่ซับซ้อน เวลาดำเนินการที่ช้าก็เหมือนกับความซับซ้อนของภาษาเครื่อง ซึ่งเป็นความยากที่เป็นส่วนประกอบภายนอกมากกว่าจะเป็นความยากที่เป็นเนื้อแท้ของกระบวนการซอฟต์แวร์ ขีดจำกัดของการแบ่งเวลาคือการลดเวลาตอบสนองของระบบให้สั้นลง เมื่อมันเข้าใกล้ศูนย์จนถึงระดับที่ประสาทสัมผัสของมนุษย์แยกแยะไม่ออก (ประมาณ 100 มิลลิวินาที) หลังจากจุดนั้นเราก็ไม่สามารถคาดหวังผลประโยชน์เพิ่มเติมได้อีก
สภาพแวดล้อมการเขียนโปรแกรมแบบเป็นเอกภาพ (Unified programming environments): Unix และ Interlisp ซึ่งเป็นสภาพแวดล้อมการเขียนโปรแกรมแบบบูรณาการรุ่นแรกๆ ที่มีการใช้งานอย่างแพร่หลาย ถูกมองว่าช่วยเพิ่มผลิตภาพได้หลายเท่าตัว ทำไม? เพราะพวกมันจัดการความยากที่เป็นส่วนประกอบภายนอกในการใช้โปรแกรมร่วมกัน โดยการจัดเตรียมคลังโปรแกรมที่บูรณาการเข้าด้วยกัน รูปแบบไฟล์ที่เป็นเอกภาพ รวมถึงท่อ (pipes) และตัวกรอง (filters) ผลที่ได้คือ โครงสร้างทางแนวคิดที่ในทางทฤษฎีสามารถเรียกใช้งาน ส่งข้อมูล และใช้ประโยชน์ซึ่งกันและกันได้เสมอนั้น สามารถทำเช่นนั้นได้ง่ายๆ ในทางปฏิบัติ ความก้าวหน้านี้ได้กระตุ้นให้เกิดการพัฒนาชุดเครื่องมือ (toolbenches) ทั้งชุด เพราะเครื่องมือใหม่แต่ละชิ้นสามารถนำไปใช้กับโปรแกรมใดๆ ก็ตามที่ใช้รูปแบบมาตรฐานได้
จากความสำเร็จเหล่านี้ สภาพแวดล้อมจึงกลายเป็นหัวข้อสำคัญของการวิจัยวิศวกรรมซอฟต์แวร์ในปัจจุบัน เราจะมาดูโอกาสและข้อจำกัดของพวกมันในหัวข้อถัดไป
Hopes for the Silver
คราวนี้ให้เราพิจารณาการพัฒนาทางเทคนิคที่มักถูกยกย่องว่าเป็น "กระสุนเงิน" ที่มีศักยภาพ พวกมันจัดการกับปัญหาอะไร? พวกมันแก้ปัญหาที่เป็นเนื้อแท้ หรือเป็นเพียงเศษเสี้ยวที่เหลืออยู่ของความยากที่เป็นส่วนประกอบภายนอก? พวกมันนำเสนอความก้าวหน้าที่พลิกผัน หรือเป็นเพียงการพัฒนาแบบค่อยเป็นค่อยไป?
Ada และความก้าวหน้าของภาษาระดับสูงอื่นๆ: หนึ่งในการพัฒนาที่ได้รับการกล่าวขวัญถึงมากที่สุดในช่วงที่ผ่านมาคือภาษาโปรแกรม Ada ซึ่งเป็นภาษาระดับสูงอเนกประสงค์ของทศวรรษ 1980 อันที่จริง Ada ไม่เพียงสะท้อนถึงการปรับปรุงวิวัฒนาการในแนวคิดเรื่องภาษาเท่านั้น แต่มันยังรวมถึงคุณสมบัติที่ส่งเสริมการออกแบบสมัยใหม่และแนวคิดเรื่องความเป็นโมดูลด้วย บางทีปรัชญาของ Ada อาจจะเป็นความก้าวหน้ายิ่งกว่าตัวภาษา Ada เองเสียอีก เพราะมันคือปรัชญาของความเป็นโมดูล (modularization) ประเภทข้อมูลนามธรรม (abstract data types) และการจัดโครงสร้างแบบลำดับชั้น Ada อาจจะดู "รุ่มรวย" เกินไป ซึ่งเป็นผลผลิตตามธรรมชาติของกระบวนการที่ความต้องการต่างๆ ถูกวางลงในงานออกแบบของมัน แต่นั่นไม่ใช่เรื่องร้ายแรงถึงตาย เพราะการใช้คำสั่งเฉพาะส่วน (subset working vocabularies) สามารถแก้ปัญหาการเรียนรู้ได้ และความก้าวหน้าของฮาร์ดแวร์จะทำให้เรามี MIPS ราคาถูกมาชดเชยต้นทุนการคอมไพล์ การพัฒนาโครงสร้างของระบบซอฟต์แวร์ให้ก้าวหน้าคือการใช้ MIPS ที่เพิ่มขึ้นให้เกิดประโยชน์อย่างแท้จริง ระบบปฏิบัติการซึ่งเคยถูกประณามอย่างหนักในทศวรรษ 1960 เรื่องต้นทุนหน่วยความจำและรอบการทำงาน ได้รับการพิสูจน์แล้วว่าเป็นรูปแบบที่ยอดเยี่ยมในการใช้ประโยชน์จาก MIPS และหน่วยความจำราคาถูกจากยุคฮาร์ดแวร์เฟื่องฟูที่ผ่านมา
อย่างไรก็ตาม Ada จะไม่เป็นกระสุนเงินที่สังหารสัตว์ประหลาดด้านผลิตภาพซอฟต์แวร์ได้ เพราะอย่างไรเสียมันก็เป็นเพียงภาษาระดับสูงอีกภาษาหนึ่ง และผลตอบแทนที่ยิ่งใหญ่ที่สุดจากภาษาประเภทนี้ได้เกิดขึ้นไปแล้วในการเปลี่ยนผ่านครั้งแรก คือการเลื่อนระดับจากความซับซ้อนที่เป็นส่วนประกอบภายนอกของเครื่องจักรไปสู่การระบุขั้นตอนการแก้ปัญหาที่เป็นนามธรรมมากขึ้น เมื่อส่วนประกอบภายนอกเหล่านั้นถูกกำจัดออกไปแล้ว ส่วนที่เหลือย่อมมีขนาดเล็กลง และผลตอบแทนจากการกำจัดพวกมันย่อมลดลงตามไปด้วย ผมทำนายว่าในอีกหนึ่งทศวรรษนับจากนี้ เมื่อมีการประเมินประสิทธิภาพของ Ada เราจะเห็นว่ามันสร้างความแตกต่างที่สำคัญได้จริง แต่ไม่ใช่เพราะคุณสมบัติของภาษาเพียงบางอย่าง หรือแม้แต่คุณสมบัติทั้งหมดรวมกัน และสภาพแวดล้อมใหม่ของ Ada ก็จะไม่กลายเป็น...
สาเหตุของการปรับปรุงเหล่านั้น ผลงานที่ยิ่งใหญ่ที่สุดของ Ada จะเป็นการที่การเปลี่ยนมาใช้มันเป็นโอกาสให้นักเขียนโปรแกรมได้รับการฝึกฝนในเทคนิคการออกแบบซอฟต์แวร์สมัยใหม่
การเขียนโปรแกรมเชิงวัตถุ (Object-oriented programming): ผู้ศึกษาในศาสตร์นี้หลายคนตั้งความหวังกับการเขียนโปรแกรมเชิงวัตถุมากกว่ากระแสทางเทคนิคอื่นๆ ในปัจจุบัน ผมเองก็เป็นหนึ่งในนั้น Mark Sherman จาก Dartmouth สังเกตว่าเราต้องระมัดระวังในการแยกแยะความคิดสองอย่างที่อยู่ภายใต้ชื่อนี้ ได้แก่ ประเภทข้อมูลนามธรรม (abstract data types) และประเภทข้อมูลแบบลำดับชั้น (hierarchical types) หรือที่เรียกว่า "คลาส" (classes)
แนวคิดของประเภทข้อมูลนามธรรมคือ ประเภทของวัตถุควรถูกกำหนดโดยชื่อ ชุดของค่าที่เหมาะสม และชุดของการดำเนินการที่เหมาะสม แทนที่จะเป็นโครงสร้างการจัดเก็บข้อมูลซึ่งควรจะถูกซ่อนไว้ ตัวอย่างเช่น Ada packages (ที่ใช้ private types) หรือโมดูลของ Modula ส่วนประเภทข้อมูลแบบลำดับชั้น เช่น คลาสใน Simula-67 ช่วยให้นิยามอินเทอร์เฟซทั่วไปที่สามารถขัดเกลาเพิ่มเติมได้โดยการจัดหาประเภทย่อยลงไป แนวคิดทั้งสองนี้แยกจากกัน (orthogonal)—คืออาจมีลำดับชั้นโดยไม่มีการซ่อนข้อมูล และมีการซ่อนข้อมูลโดยไม่มีลำดับชั้น
แนวคิดทั้งสองเป็นตัวแทนความก้าวหน้าที่แท้จริงในการสร้างซอฟต์แวร์ แต่ละอย่างช่วยกำจัดความยากที่เป็นส่วนประกอบภายนอกออกไปจากกระบวนการอีกชั้นหนึ่ง ช่วยให้ผู้ออกแบบสามารถถ่ายทอดเนื้อแท้ของงานออกแบบได้โดยไม่ต้องระบุรายละเอียดทางไวยากรณ์จำนวนมากที่ไม่ได้เพิ่มเนื้อหาข้อมูลใหม่ สำหรับทั้งประเภทข้อมูลนามธรรมและประเภทข้อมูลแบบลำดับชั้น ผลลัพธ์คือการกำจัดความยากที่เป็นส่วนประกอบภายนอกในระดับที่สูงขึ้น และยอมให้มีการถ่ายทอดงานออกแบบในระดับที่สูงขึ้น กระนั้นก็ตาม ความก้าวหน้าเหล่านี้ทำได้เพียงแค่กำจัดความยากที่เป็นส่วนประกอบภายนอก "ทั้งหมด" ออกไปจากการถ่ายทอดงานออกแบบเท่านั้น แต่ความซับซ้อนของงานออกแบบเองนั้นเป็นเรื่องเนื้อแท้ และการจัดการเหล่านี้ไม่ได้เปลี่ยนแปลงสิ่งนั้นเลย การเขียนโปรแกรมเชิงวัตถุจะช่วยให้เกิดการปรับปรุงถึงสิบเท่าได้ก็ต่อเมื่อ "พงหนาม" ที่ไม่จำเป็นของการระบุประเภทข้อมูลที่ยังเหลืออยู่ในภาษาโปรแกรมปัจจุบันนั้น เป็นตัวการของงานถึง 9 ใน 10 ส่วนในการออกแบบผลิตภัณฑ์โปรแกรม ซึ่งผมสงสัยว่ามันไม่ใช่เช่นนั้น
ปัญญาประดิษฐ์ (Artificial intelligence): หลายคนคาดหวังว่าความก้าวหน้าในด้านปัญญาประดิษฐ์จะนำมาซึ่งการก้าวขวัญครั้งยิ่งใหญ่ที่จะช่วยเพิ่มผลิตภาพและคุณภาพของซอฟต์แวร์ได้ถึงสิบเท่า แต่ผมไม่คิดอย่างนั้น เพื่อให้เห็นว่าทำไม เราต้องแยกส่วนสิ่งที่เรียกว่า "ปัญญาประดิษฐ์" ออกมาดูว่ามันถูกนำมาใช้อย่างไร Parnas ได้ช่วยทำให้ความสับสนในเรื่องนิยามศัพท์ชัดเจนขึ้น:
"นิยามสองประการที่แตกต่างกันมากของ AI ถูกนำมาใช้ทั่วไปในปัจจุบัน AI-1: การใช้คอมพิวเตอร์เพื่อแก้ปัญหาที่ก่อนหน้านี้สามารถแก้ได้โดยการใช้สติปัญญาของมนุษย์เท่านั้น AI-2: การใช้ชุดเทคนิคการเขียนโปรแกรมเฉพาะที่เรียกว่าการเขียนโปรแกรมแบบเฮิวริสติก (
heuristic) หรือแบบใช้กฎ (rule-based programming) ในแนวทางนี้ ผู้เชี่ยวชาญที่เป็นมนุษย์จะถูกศึกษาเพื่อกำหนดว่าพวกเขาใช้เฮิวริสติกหรือกฎเกณฑ์การตัดสินใจแบบใดในการแก้ปัญหา... โปรแกรมจะถูกออกแบบให้แก้ปัญหาในแบบที่มนุษย์ดูเหมือนจะแก้นิยามแรกมีความหมายที่เลื่อนไหล... บางสิ่งอาจตรงตามนิยามของ AI-1 ในวันนี้ แต่เมื่อเราเห็นว่าโปรแกรมทำงานอย่างไรและเข้าใจปัญหาแล้ว เราจะไม่คิดว่ามันเป็น AI อีกต่อไป... น่าเสียดายที่ผมไม่สามารถระบุกลุ่มเทคโนโลยีที่เป็นเอกลักษณ์เฉพาะของสาขานี้ได้... งานส่วนใหญ่เป็นเรื่องเฉพาะเจาะจงกับปัญหา และต้องใช้นามธรรมหรือความคิดสร้างสรรค์บางอย่างเพื่อดูว่าจะถ่ายโอนมันไปใช้ที่อื่นได้อย่างไร"
ผมเห็นด้วยกับคำวิจารณ์นี้อย่างยิ่ง เทคนิคที่ใช้ในการรู้จำเสียงพูดดูเหมือนจะมีจุดร่วมเพียงเล็กน้อยกับเทคนิคที่ใช้ในการรู้จำภาพ และทั้งคู่ก็แตกต่างจากเทคนิคที่ใช้ในระบบผู้เชี่ยวชาญ ผมมองภาพไม่ออกว่าการรู้จำภาพ ตัวอย่างเช่น จะสร้างความแตกต่างที่วัดผลได้ในการปฏิบัติงานเขียนโปรแกรมได้อย่างไร เช่นเดียวกับการรู้จำเสียงพูด สิ่งที่ยากเกี่ยวกับการสร้างซอฟต์แวร์คือการตัดสินใจว่า "จะพูดอะไร" ไม่ใช่ "การพูดออกมา" ไม่มีการอำนวยความสะดวกในการถ่ายทอดคำพูดใดที่จะให้ผลตอบแทนได้มากกว่าผลตอบแทนส่วนขอบเพียงเล็กน้อย ส่วนเทคโนโลยีระบบผู้เชี่ยวชาญ หรือ AI-2 นั้น สมควรได้รับการอภิปรายในหัวข้อของมันเอง
ระบบผู้เชี่ยวชาญ (Expert systems): ส่วนที่ก้าวหน้าที่สุดของศาสตร์ปัญญาประดิษฐ์ และมีการนำไปใช้งานอย่างกว้างขวางที่สุด คือเทคโนโลยีสำหรับการสร้างระบบผู้เชี่ยวชาญ นักวิทยาศาสตร์ซอฟต์แวร์จำนวนมากกำลังทำงานอย่างหนักเพื่อนำเทคโนโลยีนี้มาใช้กับสภาพแวดล้อมการสร้างซอฟต์แวร์ แนวคิดคืออะไร และโอกาสเป็นอย่างไร?
ระบบผู้เชี่ยวชาญคือโปรแกรมที่ประกอบด้วยเครื่องมืออนุมานทั่วไป (generalized inference engine) และฐานกฎเกณฑ์ (rule base) ซึ่งถูกออกแบบมาเพื่อรับข้อมูลอินพุตและสมมติฐาน แล้วสำรวจผลลัพธ์ทางตรรกะผ่านการอนุมานที่ได้จากฐานกฎเกณฑ์ โดยให้ข้อสรุปและคำแนะนำ พร้อมทั้งเสนอที่จะอธิบายผลลัพธ์ของมันโดยการย้อนรอยการให้เหตุผลแก่ผู้ใช้ เครื่องมืออนุมาน...
โดยปกติจะสามารถจัดการกับข้อมูลและกฎเกณฑ์ที่คลุมเครือหรือเป็นไปตามความน่าจะเป็นได้ นอกเหนือไปจากตรรกะแบบกำหนดล่วงหน้าที่แน่นอน ระบบดังกล่าวมีข้อดีที่ชัดเจนเหนืออัลกอริทึมที่เขียนโปรแกรมขึ้นมาเพื่อหาทางแก้ปัญหาเดียวกัน:
-
เทคโนโลยีเครื่องมืออนุมานถูกพัฒนาขึ้นแบบไม่ขึ้นกับแอปพลิเคชัน (
application-independent) แล้วนำไปปรับใช้ได้หลายงาน เราจึงสามารถทุ่มเทแรงกายแรงใจให้กับเครื่องมืออนุมานได้มากกว่า ซึ่งปัจจุบันเทคโนโลยีนี้นับว่าก้าวหน้าไปมากแล้ว - ส่วนที่เปลี่ยนแปลงได้ของเนื้อหาเฉพาะเจาะจงในแต่ละแอปพลิเคชันจะถูกเข้ารหัสไว้ในฐานกฎเกณฑ์ในรูปแบบที่เป็นมาตรฐาน และมีเครื่องมือสำหรับการพัฒนา เปลี่ยนแปลง ทดสอบ และทำเอกสารประกอบของฐานกฎเกณฑ์นั้น สิ่งนี้ช่วยจัดระเบียบความซับซ้อนของตัวแอปพลิเคชันเองได้มาก
Edward Feigenbaum กล่าวว่า พลังของระบบดังกล่าวไม่ได้มาจากกลไกการอนุมานที่หรูหราขึ้นเรื่อยๆ แต่มาจากฐานความรู้ที่รุ่มรวยขึ้นเรื่อยๆ ซึ่งสะท้อนโลกแห่งความเป็นจริงได้อย่างแม่นยำยิ่งขึ้น ผมเชื่อว่าความก้าวหน้าที่สำคัญที่สุดที่เทคโนโลยีนี้นำเสนอคือ "การแยกความซับซ้อนของแอปพลิเคชันออกจากตัวโปรแกรม"
สิ่งนี้จะนำมาใช้กับงานซอฟต์แวร์ได้อย่างไร? ในหลายทาง: เช่น การแนะนำกฎเกณฑ์ของอินเทอร์เฟซ, ให้คำปรึกษาเรื่องกลยุทธ์การทดสอบ, จดจำความถี่ของประเภทบั๊กที่พบบ่อย, ให้คำแนะนำในการปรับให้เหมาะสม (optimization), ฯลฯ ลองจินตนาการถึงที่ปรึกษาด้านการทดสอบดู ตัวอย่างเช่น ในรูปแบบเริ่มต้นที่ง่ายที่สุด ระบบผู้เชี่ยวชาญเพื่อการวินิจฉัยจะคล้ายกับรายการตรวจสอบของนักบิน โดยพื้นฐานแล้วจะเสนอคำแนะนำเกี่ยวกับสาเหตุที่เป็นไปได้ของปัญหา เมื่อฐานกฎเกณฑ์ถูกพัฒนาขึ้น คำแนะนำก็จะเจาะจงมากขึ้น โดยพิจารณาจากอาการของปัญหาที่รายงานเข้ามาอย่างละเอียดถี่ถ้วนมากขึ้น เราสามารถจินตนาการถึงผู้ช่วยแก้ไขข้อผิดพลาด (debugging assistant) ที่ในช่วงแรกจะเสนอคำแนะนำทั่วไป แต่เมื่อมีการนำโครงสร้างของระบบใส่เข้าไปในฐานกฎเกณฑ์มากขึ้นเรื่อยๆ มันก็จะยิ่งเฉพาะเจาะจงมากขึ้นในสมมติฐานที่มันสร้างขึ้นและการทดสอบที่มันแนะนำ ระบบผู้เชี่ยวชาญดังกล่าวอาจแตกต่างจากระบบทั่วไปอย่างสิ้นเชิงตรงที่ฐานกฎเกณฑ์ของมันควรถูกแบ่งเป็นโมดูลแบบลำดับชั้นในแบบเดียวกับที่ผลิตภัณฑ์ซอฟต์แวร์นั้นๆ เป็น เพื่อให้เมื่อผลิตภัณฑ์ถูกแก้ไขแบบโมดูล ฐานกฎเกณฑ์เพื่อการวินิจฉัยก็สามารถถูกแก้ไขแบบโมดูลตามไปด้วย
งานที่จำเป็นในการสร้างกฎเกณฑ์การวินิจฉัยคือสิ่งที่ต้องทำอยู่แล้วในการสร้างชุดกรณีทดสอบสำหรับโมดูลและสำหรับระบบ หากงานนี้ถูกทำในรูปแบบที่ทั่วไปพอ โดยมีโครงสร้างกฎเกณฑ์ที่เป็นมาตรฐานและมีเครื่องมืออนุมานที่ดี มันอาจจะช่วยลดแรงงานทั้งหมดในการสร้างกรณีทดสอบเบื้องต้นได้จริงๆ รวมถึงช่วยในการทดสอบเพื่อบำรุงรักษาและแก้ไขตลอดอายุการใช้งาน ในทำนองเดียวกัน เราสามารถตั้งสมมติฐานถึงที่ปรึกษาด้านอื่นๆ —ซึ่งอาจมีจำนวนมากและอาจเป็นที่ปรึกษาที่เรียบง่าย — สำหรับส่วนอื่นๆ ของงานสร้างซอฟต์แวร์
อุปสรรคหลายประการขวางกั้นการทำให้ที่ปรึกษาผู้เชี่ยวชาญที่เป็นประโยชน์ต่อเหล่านักพัฒนาซอฟต์แวร์เกิดขึ้นได้จริงในช่วงแรก ส่วนสำคัญของสถานการณ์ในอุดมคติของเราคือการพัฒนาวิธีง่ายๆ ในการเปลี่ยนจากข้อกำหนดโครงสร้างโปรแกรมไปสู่การสร้างกฎเกณฑ์การวินิจฉัยแบบอัตโนมัติหรือกึ่งอัตโนมัติ สิ่งที่ยากและสำคัญยิ่งกว่าคือภารกิจสองด้านของการรวบรวมความรู้ (knowledge acquisition): คือการค้นหาผู้เชี่ยวชาญที่สามารถอธิบายและวิเคราะห์ตนเองได้ว่าทำไมพวกเขาถึงทำสิ่งต่างๆ ในแบบที่ทำ และการพัฒนาเทคนิคที่มีประสิทธิภาพในการดึงเอาสิ่งที่พวกเขารู้มากลั่นกรองให้เป็นฐานกฎเกณฑ์ สิ่งจำเป็นพื้นฐานสำหรับการสร้างระบบผู้เชี่ยวชาญคือ "ต้องมีผู้เชี่ยวชาญ"
ผลงานที่ทรงพลังที่สุดของระบบผู้เชี่ยวชาญคือการนำประสบการณ์และภูมิปัญญาที่สะสมมาของนักเขียนโปรแกรมที่เก่งที่สุด มาให้บริการแก่นักเขียนโปรแกรมที่ยังไม่มีประสบการณ์ นี่ไม่ใช่ผลงานเล็กๆ น้อยๆ เลย ช่องว่างระหว่างแนวปฏิบัติทางวิศวกรรมซอฟต์แวร์ที่ดีที่สุดกับแนวปฏิบัติโดยเฉลี่ยนั้นกว้างมาก —ซึ่งอาจจะกว้างกว่าในสาขาวิศวกรรมอื่นๆ เครื่องมือที่ช่วยเผยแพร่แนวปฏิบัติที่ดีจึงเป็นสิ่งสำคัญมาก
การเขียนโปรแกรมแบบ "อัตโนมัติ" ("Automatic" programming): เป็นเวลาเกือบ 40 ปีที่ผู้คนต่างเฝ้ารอและเขียนถึง "การเขียนโปรแกรมอัตโนมัติ" ซึ่งคือการสร้างโปรแกรมเพื่อแก้ปัญหาจากการระบุข้อกำหนดของปัญหาเท่านั้น ปัจจุบันบางคนเขียนราวกับว่าพวกเขาคาดหวังให้เทคโนโลยีนี้นำมาซึ่งความก้าวหน้าครั้งสำคัญถัดไป Parnas บอกเป็นนัยว่าคำนี้ถูกใช้เพื่อความหรูหรามากกว่าความหมายทางวิชาการ โดยยืนยันว่า:
กล่าวโดยย่อ การเขียนโปรแกรมอัตโนมัติเป็นเพียงคำเรียกที่ดูดี (euphemism) สำหรับการเขียนโปรแกรมด้วยภาษาที่มีระดับสูงกว่าที่นักเขียนโปรแกรมมีอยู่ในขณะนั้นเสมอมา
เขาโต้แย้งโดยเนื้อแท้ว่า ในกรณีส่วนใหญ่มันคือ "วิธีการแก้ปัญหา" ไม่ใช่ "ตัวปัญหา" ที่เราต้องระบุข้อกำหนดลงไป ข้อเว้นพอจะหาได้บ้าง เทคนิคการสร้างโปรแกรมสร้างอัตโนมัติ (generators) นั้นทรงพลังมาก และถูกใช้อย่างสม่ำเสมอจนเกิดประโยชน์ในโปรแกรมจัดเรียงข้อมูล บางระบบสำหรับการรวมสมการเชิงอนุพันธ์ก็อนุญาตให้ระบุตัวปัญหาได้โดยตรง ระบบจะประเมินพารามิเตอร์ เลือกจากคลังวิธีการแก้ปัญหา และสร้างโปรแกรมออกมา แอปพลิเคชันเหล่านี้มีคุณสมบัติที่เอื้ออำนวยอย่างยิ่ง:
- ตัวปัญหาสามารถระบุลักษณะเด่นได้ด้วยพารามิเตอร์เพียงไม่กี่ตัว
- มีวิธีการแก้ปัญหาที่รู้จักกันดีมากมายเพื่อใช้เป็นคลังทางเลือก
- การวิเคราะห์อย่างละเอียดนำไปสู่กฎเกณฑ์ที่ชัดเจนในการเลือกเทคนิคการแก้ปัญหาตามพารามิเตอร์ของปัญหาที่กำหนด
มันยากที่จะจินตนาการว่าเทคนิคดังกล่าวจะขยายผลไปสู่โลกที่กว้างขึ้นของระบบซอฟต์แวร์ทั่วไปได้อย่างไร ในเมื่อกรณีที่มีคุณสมบัติที่ลงตัวเช่นนี้ถือเป็นข้อยกเว้น และมันยากยิ่งกว่าที่จะจินตนาการว่าการก้าวข้ามขีดจำกัดไปสู่การใช้งานทั่วไปนี้จะเกิดขึ้นได้อย่างไร
การเขียนโปรแกรมแบบกราฟิก (Graphical programming): หัวข้อยอดนิยมสำหรับวิทยานิพนธ์ปริญญาเอกในสาขาวิศวกรรมซอฟต์แวร์คือ การเขียนโปรแกรมแบบกราฟิกหรือแบบภาพ ซึ่งเป็นการประยุกต์ใช้กราฟิกคอมพิวเตอร์กับการออกแบบซอฟต์แวร์ บางครั้งมีการตั้งสมมติฐานถึงความสำเร็จของแนวทางนี้โดยเปรียบเทียบกับการออกแบบชิป VLSI ซึ่งกราฟิกคอมพิวเตอร์มีบทบาทสำคัญมาก บางครั้งแนวทางนี้ก็ถูกให้เหตุผลโดยการมองว่าผังงาน (flowcharts) เป็นสื่อกลางในการออกแบบโปรแกรมในอุดมคติ และจัดหาเครื่องมือทรงพลังเพื่อสร้างมันขึ้นมา
ยังไม่มีอะไรที่น่าเชื่อถือ อย่าว่าแต่จะน่าตื่นเต้นเลย ที่ปรากฏออกมาจากความพยายามเหล่านั้น ผมเชื่อมั่นว่ามันจะไม่มีอะไรเกิดขึ้นด้วยเหตุผลหลายประการ: ประการแรก ดังที่ผมได้แย้งไว้ในที่อื่น ผังงานเป็นการสรุปโครงสร้างซอฟต์แวร์ในระดับนามธรรมที่แย่มาก อันที่จริง มันควรถูกมองว่าเป็นความพยายามของ Burks, von Neumann และ Goldstine ในการสร้างภาษาควบคุมระดับสูงที่จำเป็นอย่างยิ่งสำหรับคอมพิวเตอร์ที่พวกเขานำเสนอ ในรูปแบบที่น่าอนาถ มีหลายหน้า และเต็มไปด้วยกล่องเชื่อมต่อ ซึ่งเป็นสิ่งที่ผังงานถูกพัฒนามาจนถึงทุกวันนี้ มันได้พิสูจน์แล้วว่าไร้ประโยชน์อย่างยิ่งในฐานะเครื่องมือออกแบบ...
นักเขียนโปรแกรมมักจะวาดผังงาน "หลังจาก" ไม่ใช่ "ก่อนหน้า" การเขียนโปรแกรมที่พวกมันอธิบาย
ประการที่สอง หน้าจอในปัจจุบันมีขนาดเล็กเกินไปในแง่ของพิกเซล ที่จะแสดงทั้งขอบเขตและความละเอียดของไดอะแกรมซอฟต์แวร์ที่ละเอียดและจริงจัง สิ่งที่เรียกว่า "อุปมาแบบโต๊ะทำงาน" (desktop metaphor) ของเวิร์กสเตชันในปัจจุบัน กลับเป็นเหมือน "อุปมาแบบที่นั่งบนเครื่องบิน" เสียมากกว่า ใครก็ตามที่เคยต้องจัดการกับกองเอกสารเต็มตักในขณะที่นั่งชั้นประหยัดระหว่างผู้โดยสารร่างท้วมสองคนจะเข้าใจความแตกต่าง—เราสามารถเห็นสิ่งต่างๆ ได้เพียงไม่กี่อย่างในเวลาเดียวกัน โต๊ะทำงานจริงๆ ช่วยให้เห็นภาพรวมและเข้าถึงหน้ากระดาษนับสิบหน้าได้อย่างอิสระ ยิ่งไปกว่านั้น เมื่อความสร้างสรรค์พลุ่งพล่าน นักเขียนโปรแกรมหรือนักเขียนหลายคนมักจะละทิ้งโต๊ะทำงานไปใช้พื้นที่บนวันที่กว้างขวางกว่า เทคโนโลยีฮาร์ดแวร์จะต้องก้าวหน้าไปอีกมากก่อนที่ขอบเขตการมองเห็นของเราจะเพียงพอสำหรับงานออกแบบซอฟต์แวร์
ที่สำคัญกว่านั้น ดังที่ผมได้แย้งไว้ข้างต้น ซอฟต์แวร์เป็นสิ่งที่สร้างภาพในจินตนาการได้ยากมาก ไม่ว่าเราจะทำไดอะแกรมแสดงทิศทางของการควบคุม, การซ้อนกันของขอบเขตตัวแปร, การอ้างอิงข้ามของตัวแปร, ทิศทางของข้อมูล, โครงสร้างข้อมูลแบบลำดับชั้น หรืออะไรก็ตาม เราจะสัมผัสได้เพียงมิติเดียวของ "ช้างซอฟต์แวร์" ที่เชื่อมโยงกันอย่างซับซ้อน หากเรานำไดอะแกรมทั้งหมดที่สร้างจากมุมมองต่างๆ มาวางซ้อนกัน มันก็ยากที่จะสรุปภาพรวมออกมาได้ การเปรียบเทียบกับ VLSI นั้นทำให้เข้าใจผิดอย่างมาก—การออกแบบชิปคือวัตถุสองมิติที่มีการวางเป็นชั้นๆ ซึ่งรูปทรงเรขาคณิตของมันสะท้อนถึงเนื้อแท้ของมัน แต่ระบบซอฟต์แวร์ไม่ใช่เช่นนั้น
การพิสูจน์ความถูกต้องของโปรแกรม (Program verification): ความพยายามส่วนใหญ่ในการเขียนโปรแกรมสมัยใหม่หมดไปกับการทดสอบและซ่อมแซมบั๊ก เป็นไปได้ไหมที่จะมีกระสุนเงินจากการกำจัดความผิดพลาดตั้งแต่ต้นทางในขั้นตอนการออกแบบระบบ? ผลิตภาพและความน่าเชื่อถือของผลิตภัณฑ์จะเพิ่มขึ้นอย่างมหาศาลได้ไหม หากเราใช้กลยุทธ์ที่แตกต่างออกไปอย่างสิ้นเชิง คือการ "พิสูจน์" ว่างานออกแบบนั้นถูกต้องก่อนจะทุ่มเทแรงกายมหาศาลไปในการนำไปใช้งานและการทดสอบ?
ผมไม่เชื่อว่าเราจะพบปาฏิหาริย์ที่นี่ การพิสูจน์ความถูกต้องของโปรแกรมเป็นแนวคิดที่ทรงพลังมาก และมันจะสำคัญมากสำหรับสิ่งต่างๆ เช่น เคอร์เนลของระบบปฏิบัติการที่มีความปลอดภัยสูง อย่างไรก็ตาม เทคโนโลยีนี้นไม่ได้ให้สัญญาว่าจะช่วยประหยัดแรงงาน การพิสูจน์ความถูกต้องเป็นงานที่หนักหนาสาหัสจนมีโปรแกรมขนาดใหญ่เพียงไม่กี่โปรแกรมเท่านั้นที่เคยถูกพิสูจน์ การพิสูจน์ความถูกต้องไม่ได้หมายถึงโปรแกรมที่ไม่มีข้อผิดพลาด ที่นี่ก็ไม่มีปาฏิหาริย์เช่นกัน การพิสูจน์ทางคณิตศาสตร์ก็สามารถผิดพลาดได้ ดังนั้นแม้ว่าการพิสูจน์ความถูกต้องอาจช่วยลดภาระการทดสอบโปรแกรมลงได้ แต่มันก็ไม่สามารถกำจัดภาระนั้นไปได้ทั้งหมด
ที่ร้ายแรงกว่านั้นคือ แม้การพิสูจน์ความถูกต้องของโปรแกรมจะทำได้อย่างสมบูรณ์แบบ แต่มันก็ทำได้เพียงยืนยันว่าโปรแกรมนั้นตรงตาม "ข้อกำหนด" เท่านั้น ส่วนที่ยากที่สุดของงานซอฟต์แวร์คือการสร้างข้อกำหนดที่ครบถ้วนและสอดคล้องกัน และเนื้อแท้ส่วนใหญ่ของการสร้างโปรแกรมก็คือการแก้ไขข้อผิดพลาดในตัวข้อกำหนดนั่นเอง
สภาพแวดล้อมและเครื่องมือ (Environments and tools): เราสามารถคาดหวังผลตอบแทนเพิ่มขึ้นได้อีกเท่าไหร่จากการวิจัยที่แพร่หลายในเรื่องสภาพแวดล้อมการเขียนโปรแกรมที่ดีขึ้น? ปฏิกิริยาตอบโต้โดยสัญชาตญาณคือ ปัญหาที่ให้ผลตอบแทนสูงได้ถูกจัดการเป็นลำดับแรกๆ และได้รับการแก้ไขไปแล้ว ได้แก่: ระบบไฟล์แบบลำดับชั้น, รูปแบบไฟล์ที่เป็นเอกภาพเพื่อให้มีอินเทอร์เฟซของโปรแกรมที่สอดคล้องกัน และเครื่องมืออเนกประสงค์ ส่วนตัวแก้ไขข้อความอัจฉริยะที่เจาะจงตามภาษา (Language-specific smart editors) เป็นการพัฒนาที่ยังไม่มีการใช้งานอย่างแพร่หลายนักในทางปฏิบัติ แต่สิ่งที่พวกมันสัญญาได้มากที่สุดคือการปลดปล่อยเราจากความผิดพลาดทางไวยากรณ์และความผิดพลาดทางความหมายแบบง่ายๆ
บางทีผลตอบแทนที่ยิ่งใหญ่ที่สุดที่ยังไม่เกิดขึ้นจริงในสภาพแวดล้อมการเขียนโปรแกรม คือการใช้ระบบฐานข้อมูลแบบบูรณาการเพื่อติดตามรายละเอียดมหาศาลที่นักเขียนโปรแกรมแต่ละคนต้องจดจำอย่างแม่นยำ และต้องทำให้ทันสมัยอยู่เสมอในกลุ่มผู้ร่วมงานที่ทำงานบนระบบเดียวกัน แน่นอนว่างานนี้คุ้มค่าที่จะทำ และมันจะให้ผลบางประการในด้านผลิตภาพและความน่าเชื่อถือ แต่โดยธรรมชาติของมัน ผลตอบแทนจากจุดนี้เป็นต้นไปย่อมมีจำกัด (marginal)
เวิร์กสเตชัน (Workstations): เราสามารถคาดหวังผลประโยชน์อะไรให้กับศาสตร์แห่งซอฟต์แวร์จากการเพิ่มขึ้นของพลังประมวลผลและหน่วยความจำของเวิร์กสเตชันส่วนบุคคลอย่างรวดเร็วและแน่นอน? เราจะใช้ MIPS ได้คุ้มค่าแค่ไหนกัน? การเขียนและแก้ไขโปรแกรมและเอกสารนั้นได้รับการสนับสนุนอย่างเพียงพอด้วยความเร็วในปัจจุบันแล้ว การคอมไพล์อาจต้องการการส่งเสริมบ้าง แต่การเพิ่มความเร็วของเครื่องขึ้น 10 เท่า ย่อมจะทำให้ "เวลาที่ใช้คิด" กลายเป็นกิจกรรมหลักในแต่ละวันของนักเขียนโปรแกรมอย่างแน่นอน อันที่จริงตอนนี้มันก็เป็นเช่นนั้นอยู่แล้ว เวิร์กสเตชันที่ทรงพลังขึ้นเป็นสิ่งที่เรายินดีต้อนรับอย่างแน่นอน แต่เราไม่สามารถคาดหวังการปรับปรุงแบบปาฏิหาริย์จากพวกมันได้
Promising Attacks on the Conceptual Essence
แม้ว่าจะไม่มีความก้าวหน้าทางเทคโนโลยีใดที่รับรองว่าจะให้ผลลัพธ์ที่น่าอัศจรรย์เหมือนที่เราคุ้นเคยในด้านฮาร์ดแวร์ แต่ปัจจุบันก็มีผลงานที่ดีอยู่มากมาย และมีแนวโน้มของความก้าวหน้าที่มั่นคง แม้จะไม่หวือหวานัก
การจัดการทางเทคโนโลยีทั้งหมดที่มุ่งเน้นไปที่ส่วนประกอบภายนอก (accidents) ของกระบวนการซอฟต์แวร์นั้นถูกจำกัดโดยพื้นฐานด้วยสมการผลิตภาพ:
หากส่วนประกอบทางแนวคิด (conceptual components) ของงานเป็นสิ่งที่กินเวลาส่วนใหญ่ในตอนนี้ (ดังที่ผมเชื่อ) เช่นนั้นแล้ว กิจกรรมใดๆ ที่ทำกับส่วนประกอบของงานที่เป็นเพียงการ "ถ่ายทอด" แนวคิดออกมา ย่อมไม่สามารถให้ผลตอบแทนด้านผลิตภาพที่มหาศาลได้ ดังนั้นเราจึงต้องพิจารณาแนวทางที่จัดการกับเนื้อแท้ของปัญหาซอฟต์แวร์ ซึ่งก็คือการสร้างโครงสร้างแนวคิดที่ซับซ้อนเหล่านั้น โชคดีที่บางแนวทางมีความน่าสนใจอย่างยิ่ง
ซื้อเทียบกับสร้าง (Buy versus build): ทางเลือกที่รุนแรงที่สุดสำหรับการสร้างซอฟต์แวร์คือ "ไม่ต้องสร้างมันเลย"
ทุกวันนี้ทางเลือกนี้ทำได้ง่ายขึ้นเรื่อยๆ เนื่องจากมีผู้ขายเสนอผลิตภัณฑ์ซอฟต์แวร์มากขึ้นและดีขึ้นสำหรับแอปพลิเคชันที่หลากหลายจนน่าตกใจ ในขณะที่วิศวกรซอฟต์แวร์อย่างเรามัวแต่ตรากตรำอยู่กับระเบียบวิธีในการผลิต การปฏิวัติของคอมพิวเตอร์ส่วนบุคคลก็ได้สร้างตลาดมวลชนสำหรับซอฟต์แวร์ขึ้นมา ไม่ใช่แค่ตลาดเดียว แต่เป็นตลาดจำนวนมาก แผงหนังสือทุกแห่งมีนิตยสารรายเดือนที่โฆษณาและวิจารณ์ผลิตภัณฑ์ซอฟต์แวร์นับสิบรายการในราคาตั้งแต่ไม่กี่ดอลลาร์ไปจนถึงไม่กี่ร้อยดอลลาร์ แหล่งข้อมูลที่เฉพาะทางมากขึ้นก็นำเสนอผลิตภัณฑ์ที่ทรงพลังมากสำหรับตลาดเวิร์กสเตชันและ Unix อื่นๆ แม้แต่เครื่องมือและสภาพแวดล้อมทางซอฟต์แวร์ก็สามารถหาซื้อได้สำเร็จรูป ผมเคยเสนอแนวคิดเรื่องตลาดกลางสำหรับโมดูลแยกส่วนไว้ในที่อื่น ผลิตภัณฑ์ใดๆ ดังกล่าวล้วนมีราคาถูกกว่าการสร้างขึ้นมาใหม่เองทั้งหมด แม้จะมีราคาถึง 100,000 ดอลลาร์ แต่ซอฟต์แวร์ที่ซื้อมาก็ยังมีราคาพอๆ กับต้นทุนการจ้างนักเขียนโปรแกรมเพียงหนึ่งคน-ปีเท่านั้น และที่สำคัญคือมันพร้อมส่งมอบทันที! อย่างน้อยก็ทันทีสำหรับ...
ผลิตภัณฑ์ที่มีตัวตนอยู่จริง ผลิตภัณฑ์ที่ผู้พัฒนาสามารถอ้างอิงถึงผู้ใช้งานที่มีความสุขได้ ยิ่งไปกว่านั้น ผลิตภัณฑ์ดังกล่าวมีแนวโน้มที่จะมีเอกสารประกอบที่ดีกว่ามากและได้รับการบำรุงรักษาดีกว่าซอฟต์แวร์ที่สร้างขึ้นเองในองค์กร การพัฒนาของตลาดมวลชนคือแนวโน้มระยะยาวที่ลึกซึ้งที่สุดในวิศวกรรมซอฟต์แวร์ ต้นทุนของซอฟต์แวร์คือต้นทุนการพัฒนามาโดยตลอด ไม่ใช่ต้นทุนการทำซ้ำ การแบ่งปันต้นทุนนั้นท่ามกลางผู้ใช้แม้เพียงไม่กี่รายก็ช่วยลดต้นทุนต่อผู้ใช้ลงได้อย่างมหาศาล อีกมุมมองหนึ่งคือ การใช้งานซอฟต์แวร์ชุดเดียวกัน $n$ ชุด ช่วยเพิ่มผลิตภาพของผู้พัฒนาขึ้น $n$ เท่าอย่างมีประสิทธิภาพ นั่นคือการยกระดับผลิตภาพของทั้งสายงานและของทั้งประเทศ
ประเด็นสำคัญคือความสามารถในการนำไปใช้งาน (applicability) ผมสามารถใช้แพ็กเกจสำเร็จรูปที่มีอยู่เพื่อทำงานของผมได้หรือไม่? สิ่งที่น่าประหลาดใจได้เกิดขึ้นที่นี่ ในช่วงทศวรรษ 1950 และ 1960 ผลการศึกษาแล้วการศึกษาเล่าแสดงให้เห็นว่าผู้ใช้จะไม่ใช้แพ็กเกจสำเร็จรูปสำหรับงานจ่ายเงินเดือน การควบคุมสินค้าคงคลัง บัญชีลูกหนี้ ฯลฯ เพราะข้อกำหนดนั้นเฉพาะเจาะจงเกินไป และความแตกต่างในแต่ละกรณีนั้นสูงเกินไป แต่ในช่วงทศวรรษ 1980 เราพบว่าแพ็กเกจเหล่านี้มีความต้องการสูงและมีการใช้งานอย่างแพร่หลาย
อะไรเปลี่ยนไป? ไม่ใช่ตัวแพ็กเกจหรอก พวกมันอาจจะมีความเป็นสากลและปรับแต่งได้มากกว่าเมื่อก่อนบ้างแต่ไม่มากนัก และไม่ใช่ตัวแอปพลิเคชันด้วย หากจะมีอะไรเปลี่ยนไป ความต้องการทางธุรกิจและวิทยาศาสตร์ในปัจจุบันมีความหลากหลายและซับซ้อนกว่าเมื่อ 20 ปีก่อนเสียอีก การเปลี่ยนแปลงครั้งใหญ่คือ "อัตราส่วนต้นทุนระหว่างฮาร์ดแวร์และซอฟต์แวร์" ผู้ซื้อเครื่องจักรราคา 2 ล้านดอลลาร์ในปี 1960 รู้สึกว่าเขาสามารถจ่ายเงินเพิ่มอีก 250,000 ดอลลาร์สำหรับโปรแกรมจ่ายเงินเดือนที่ปรับแต่งมาโดยเฉพาะ ซึ่งเป็นโปรแกรมที่เข้ากับสภาพแวดล้อมทางสังคมที่ไม่ค่อยเป็นมิตรกับคอมพิวเตอร์ในตอนนั้นได้อย่างราบรื่น แต่ผู้ซื้อเครื่องจักรสำนักงานราคา 50,000 ดอลลาร์ในปัจจุบันไม่สามารถจ่ายเงินซื้อโปรแกรมจ่ายเงินเดือนแบบปรับแต่งเองได้ ดังนั้นพวกเขาจึงปรับกระบวนการจ่ายเงินเดือนของตนให้เข้ากับแพ็กเกจที่มีอยู่ คอมพิวเตอร์กลายเป็นเรื่องปกติธรรมดามากเสียจนการปรับตัวเหล่านี้ได้รับการยอมรับว่าเป็นเรื่องปกติ
มีข้อยกเว้นที่ชัดเจนสำหรับข้อโต้แย้งของผมที่ว่าแพ็กเกจซอฟต์แวร์มีการเปลี่ยนแปลงน้อยมากในช่วงหลายปีที่ผ่านมา นั่นคือ "ตารางคำนวณอิเล็กทรอนิกส์" (electronic spreadsheets) และ "ระบบฐานข้อมูลอย่างง่าย" เครื่องมือที่ทรงพลังเหล่านี้ ซึ่งดูเหมือนเป็นเรื่องที่เห็นได้ชัดเมื่อมองย้อนกลับไปแต่กลับปรากฏขึ้นล่าช้ามาก สามารถนำไปใช้งานได้หลากหลายจนนับไม่ถ้วน บางงานก็แปลกแหวกแนวมาก ปัจจุบันมีบทความและแม้แต่หนังสือมากมายเกี่ยวกับวิธีรับมือกับงานที่คาดไม่ถึงด้วยตารางคำนวณ แอปพลิเคชันจำนวนมหาศาลที่แต่ก่อนต้องเขียนขึ้นเป็นโปรแกรมเฉพาะด้วยภาษา Cobol หรือ Report Program Generator ปัจจุบันถูกทำเป็นกิจวัตรด้วยเครื่องมือเหล่านี้
ผู้ใช้จำนวนมากในปัจจุบันใช้งานคอมพิวเตอร์ของตนวันแล้ววันเล่าในแอปพลิเคชันที่หลากหลายโดยไม่ต้องเขียนโปรแกรมเลย อันที่จริง ผู้ใช้เหล่านี้หลายคนไม่สามารถเขียนโปรแกรมใหม่สำหรับเครื่องของตนได้ แต่พวกเขาก็ยังชำนาญในการแก้ปัญหาใหม่ๆ ด้วยเครื่องเหล่านั้น ผมเชื่อว่ากลยุทธ์ด้านผลิตภาพซอฟต์แวร์ที่ทรงพลังที่สุดเพียงอย่างเดียวสำหรับหลายองค์กรในปัจจุบัน คือการจัดเตรียมคอมพิวเตอร์ส่วนบุคคลและโปรแกรมเขียนภาพ วาดภาพ จัดการไฟล์ และตารางคำนวณที่ดีและเป็นสากลให้กับพนักงานระดับปฏิบัติการที่ไม่มีความรู้เรื่องคอมพิวเตอร์ แล้วปล่อยให้พวกเขาใช้งานมันอย่างอิสระ กลยุทธ์เดียวกันนี้ร่วมกับแพ็กเกจทางคณิตศาสตร์และสถิติอเนกประสงค์ และความสามารถในการเขียนโปรแกรมแบบง่ายๆ บางอย่าง จะใช้ได้ผลดีกับนักวิทยาศาสตร์ในห้องปฏิบัติการนับร้อยคนด้วยเช่นกัน
การขัดเกลาข้อกำหนดและการสร้างต้นแบบที่รวดเร็ว (Requirements refinement and rapid prototyping): ส่วนที่ยากที่สุดเพียงอย่างเดียวของการสร้างระบบซอฟต์แวร์คือการตัดสินใจว่าจะสร้าง "อะไร" ให้แน่ชัด ไม่มีส่วนใดของงานเชิงแนวคิดที่จะยากเท่ากับการกำหนดข้อกำหนดทางเทคนิคที่ละเอียด รวมถึงอินเทอร์เฟซทั้งหมดที่เชื่อมต่อกับผู้คน เครื่องจักร และระบบซอฟต์แวร์อื่นๆ ไม่มีส่วนใดของงานที่หากทำผิดแล้วจะสร้างความเสียหายให้กับระบบที่ได้เท่ากับส่วนนี้ และไม่มีส่วนใดที่แก้ไขได้ยากกว่าในภายหลัง
ดังนั้น หน้าที่ที่สำคัญที่สุดที่ผู้สร้างซอฟต์แวร์ทำให้กับลูกค้าคือการดึงข้อมูลและขัดเกลาข้อกำหนดของผลิตภัณฑ์ซ้ำแล้วซ้ำเล่า เพราะความจริงก็คือ ลูกค้าเองก็ไม่รู้ว่าพวกเขาต้องการอะไร โดยปกติพวกเขาไม่รู้ว่าต้องตอบคำถามอะไรบ้าง และแทบจะไม่เคยคิดถึงปัญหาในรายละเอียดที่ต้องระบุออกมาเลย แม้แต่คำตอบง่ายๆ ที่ว่า "ทำให้ระบบซอฟต์แวร์ใหม่ทำงานเหมือนระบบประมวลผลข้อมูลแบบมือเดิมของเรา" ก็ยังเป็นคำตอบที่ง่ายเกินไป ในความเป็นจริงลูกค้าไม่เคยต้องการสิ่งนั้นเป๊ะๆ หรอก ยิ่งไปกว่านั้น ระบบซอฟต์แวร์ที่ซับซ้อนคือสิ่งที่มีพฤติกรรม มีการเคลื่อนไหว และมีการทำงาน พลศาสตร์ของการกระทำเหล่านั้นยากที่จะจินตนาการได้ ดังนั้นในการวางแผนกิจกรรมซอฟต์แวร์ใดๆ จำเป็นต้องเผื่อเวลาสำหรับการวนรอบ (iteration) อย่างเข้มข้นระหว่างลูกค้าและผู้ออกแบบเพื่อเป็นส่วนหนึ่งของการนิยามระบบ
ผมขอไปไกลกว่านั้นและยืนยันว่า มันเป็นเรื่องที่เป็นไปไม่ได้เลยที่ลูกค้า แม้แต่ผู้ที่ทำงานร่วมกับวิศวกรซอฟต์แวร์ จะสามารถระบุข้อกำหนดที่ครบถ้วน แม่นยำ และถูกต้องของผลิตภัณฑ์ซอฟต์แวร์สมัยใหม่ได้ ก่อนที่จะได้สร้างและทดลองใช้งานผลิตภัณฑ์เวอร์ชันบางส่วนที่พวกเขากำลังระบุข้อกำหนดอยู่
ดังนั้น หนึ่งในความพยายามทางเทคโนโลยีที่น่าสนใจที่สุดในปัจจุบัน และเป็นแนวทางที่จัดการกับเนื้อแท้ ไม่ใช่แค่ส่วนประกอบภายนอกของปัญหาซอฟต์แวร์ คือการพัฒนาแนวทางและเครื่องมือสำหรับการสร้างต้นแบบที่รวดเร็ว (rapid prototyping) เพื่อเป็นส่วนหนึ่งของการวนรอบการระบุข้อกำหนด ระบบซอฟต์แวร์ต้นแบบคือระบบที่จำลองอินเทอร์เฟซที่สำคัญและทำหน้าที่หลักของระบบที่ตั้งใจจะสร้าง โดยไม่จำเป็นต้องถูกผูกมัดด้วยข้อจำกัดเรื่องความเร็วของฮาร์ดแวร์ ขนาด หรือต้นทุนในระดับเดียวกัน ปกติต้นแบบจะทำงานในส่วนที่เป็นเส้นทางหลัก (mainline tasks) ของแอปพลิเคชัน แต่จะไม่มีความพยายามในการจัดการข้อยกเว้น ตอบสนองต่ออินพุตที่ไม่ถูกต้อง หรือการหยุดทำงานอย่างสะอาด ฯลฯ จุดประสงค์ของต้นแบบคือการทำให้โครงสร้างแนวคิดที่ระบุไว้นั้นกลายเป็นความจริง เพื่อให้ลูกค้าสามารถทดสอบความสม่ำเสมอและความสามารถในการใช้งานได้
กระบวนการจัดหาซอฟต์แวร์ในปัจจุบันจำนวนมากตั้งอยู่บนสมมติฐานที่ว่า เราสามารถระบุข้อกำหนดของระบบที่น่าพอใจได้ล่วงหน้า รับการประมูลราคาเพื่อสร้างมัน สร้างมันขึ้นมา และติดตั้งใช้งาน ผมคิดว่าสมมติฐานนี้ผิดพลาดอย่างรุนแรง และปัญหาในการจัดหาซอฟต์แวร์จำนวนมากก็เกิดจากความเข้าใจผิดนี้ ดังนั้นจึงไม่สามารถแก้ไขได้หากไม่มีการปรับปรุงพื้นฐานใหม่ คือการจัดเตรียมให้มีการพัฒนาและการระบุข้อกำหนดแบบวนรอบของทั้งต้นแบบและผลิตภัณฑ์จริง
การพัฒนาแบบเพิ่มส่วน—จง "ปลูก" ซอฟต์แวร์ ไม่ใช่ "สร้าง" (Incremental development—grow, not build, software): ผมยังจำความรู้สึกตกใจได้เมื่อปี 1958 เมื่อได้ยินเพื่อนคนหนึ่งพูดถึงการ "สร้าง" (building) โปรแกรม แทนที่จะเป็นการ "เขียน" (writing) โปรแกรม ในชั่วพริบตาเดียวเขาได้ขยายมุมมองทั้งหมดของผมที่มีต่อกระบวนการซอฟต์แวร์ การเปลี่ยนอุปมาอุปไมยนี้มีพลังและแม่นยำมาก ทุกวันนี้เราเข้าใจแล้วว่าการสร้างซอฟต์แวร์นั้นเหมือนกับกระบวนการก่อสร้างอื่นๆ เพียงใด และเราใช้องค์ประกอบอื่นๆ ของอุปมานี้ได้อย่างอิสระ เช่น ข้อกำหนด การประกอบชิ้นส่วน และนั่งร้าน
แต่อุปมาเรื่องการก่อสร้างได้หมดประโยชน์ของมันไปแล้ว ถึงเวลาต้องเปลี่ยนอีกครั้ง หากโครงสร้างทางแนวคิดที่เราสร้างขึ้นในปัจจุบันนั้นซับซ้อนเกินกว่าจะระบุข้อกำหนดได้อย่างแม่นยำล่วงหน้า และซับซ้อนเกินกว่าจะสร้างได้อย่างไร้ที่ติ (ดังที่ผมเชื่อ) เช่นนั้นแล้วเราต้องใช้แนวทางที่แตกต่างไปอย่างสิ้นเชิง ให้เราหันเข้าหาธรรมชาติและศึกษาความซับซ้อนในสิ่งมีชีวิต แทนที่จะดูเพียงผลงานที่ไร้ชีวิตของมนุษย์ ที่นี่เราจะพบโครงสร้างที่มีความซับซ้อนจนน่าเกรงขาม เพียงแค่สมองอย่างเดียวก็สลับซับซ้อนเกินกว่าจะทำแผนที่ ทรงพลังเกินกว่าจะเลียนแบบ เต็มไปด้วยความหลากหลาย มีการป้องกันตนเอง และฟื้นฟูตนเองได้ ความลับคือ มันถูก "ปลูก" ขึ้นมา ไม่ใช่ถูก "สร้าง"
ระบบซอฟต์แวร์ของเราก็ต้องเป็นเช่นนั้น เมื่อหลายปีก่อน Harlan Mills เสนอว่าระบบซอฟต์แวร์ใดๆ ควรถูก "ปลูก" ขึ้นมาด้วยการพัฒนาแบบเพิ่มส่วน (incremental development) นั่นคือ ขั้นแรกควรทำให้ระบบรันได้ก่อน แม้ว่ามันจะยังไม่ทำอะไรที่เป็นประโยชน์เลยนอกจากเรียกชุดของโปรแกรมย่อยจำลอง (dummy subprograms) ที่เหมาะสม จากนั้นจึงค่อยๆ เติมเนื้อหาเข้าไปทีละนิด โดยเปลี่ยนโปรแกรมย่อยเหล่านั้นให้กลายเป็นการกระทำจริง หรือเรียกไปยังส่วนที่ว่างเปล่า (empty stubs) ในระดับที่ต่ำลงไป
ผมได้เห็นผลลัพธ์ที่น่าทึ่งที่สุดนับตั้งแต่ผมเริ่มผลักดันเทคนิคนี้ให้กับผู้สร้างโครงการในชั้นเรียนวิศวกรรมซอฟต์แวร์ของผม ไม่มีอะไรในทศวรรษที่ผ่านมาที่เปลี่ยนแนวปฏิบัติของผม หรือประสิทธิผลของมันได้รุนแรงเท่านี้ แนวทางนี้จำเป็นต้องใช้การออกแบบจากบนลงล่าง เพราะมันเป็นการปลูกซอฟต์แวร์จากบนลงล่าง มันช่วยให้ถอยกลับมาแก้ไขได้ง่าย มันเอื้อต่อการสร้างต้นแบบในช่วงแรก ฟังก์ชันแต่ละอย่างที่เพิ่มเข้าไป และการเตรียมรองรับข้อมูลหรือสถานการณ์ที่ซับซ้อนขึ้น จะเติบโตขึ้นแบบออร์แกนิกจากสิ่งที่มีอยู่แล้ว
ผลกระทบต่อขวัญและกำลังใจนั้นน่าตกใจมาก ความกระตือรือร้นจะพุ่งสูงขึ้นเมื่อมีระบบที่รันได้จริงๆ แม้จะเป็นระบบที่เรียบง่ายก็ตาม ความพยายามจะเพิ่มเป็นสองเท่าเมื่อภาพแรกจากระบบซอฟต์แวร์กราฟิกใหม่ปรากฏขึ้นบนหน้าจอ แม้ว่าจะเป็นเพียงรูปสี่เหลี่ยมผืนผ้าก็ตาม เราจะมีระบบที่ "ทำงานได้" เสมอในทุกขั้นตอนของกระบวนการ ผมพบว่าทีมสามารถปลูกตัวตนที่มีความซับซ้อนขึ้นมาได้มากกว่าการสร้างมันขึ้นมา ภายในเวลาสี่เดือนเท่ากัน ผลประโยชน์เดียวกันนี้สามารถเกิดขึ้นได้ในโครงการขนาดใหญ่เช่นเดียวกับโครงการขนาดเล็กของผม
นักออกแบบที่ยิ่งใหญ่ (Great designers): คำถามที่เป็นหัวใจสำคัญว่าจะปรับปรุงศาสตร์แห่งซอฟต์แวร์ได้อย่างไร ยังคงมุ่งเป้าไปที่ "คน" เสมอมา
เราสามารถได้งานออกแบบที่ดีได้โดยการทำตามแนวปฏิบัติที่ดีแทนที่จะเป็นแนวปฏิบัติที่แย่ แนวปฏิบัติในการออกแบบที่ดีสามารถสอนกันได้ นักเขียนโปรแกรมเป็นกลุ่มคนที่มีสติปัญญาสูงที่สุดกลุ่มหนึ่งในประชากร ดังนั้นพวกเขาจึงสามารถเรียนรู้แนวปฏิบัติที่ดีได้ ดังนั้นแรงผลักดันหลักในสหรัฐอเมริกาคือการเผยแพร่แนวปฏิบัติสมัยใหม่ที่ดี หลักสูตรใหม่ วรรณกรรมใหม่ องค์กรใหม่ๆ เช่น Software Engineering Institute ล้วนเกิดขึ้นเพื่อยกระดับแนวปฏิบัติของเราจากแย่ไปสู่ดี ซึ่งเป็นสิ่งที่ถูกต้องอย่างยิ่ง
อย่างไรก็ตาม ผมไม่เชื่อว่าเราจะก้าวขึ้นสู่ระดับถัดไปได้ด้วยวิธีเดิม ในขณะที่ความแตกต่างระหว่างงานออกแบบแนวคิดที่แย่กับที่อาจจะอยู่ที่ความสมเหตุสมผลของวิธีการออกแบบ แต่ความแตกต่างระหว่างงานออกแบบที่ "ดี" กับที่ "ยอดเยี่ยม" นั้นไม่ได้อยู่ที่จุดนั้นอย่างแน่นอน งานออกแบบที่ยอดเยี่ยมมาจากนักออกแบบที่ยิ่งใหญ่ การสร้างซอฟต์แวร์เป็นกระบวนการสร้างสรรค์ ความสมเหตุสมผล...
ระเบียบวิธีสามารถมอบพลังและปลดปล่อยความคิดสร้างสรรค์ได้ แต่มันไม่สามารถจุดไฟหรือสร้างแรงบันดาลใจให้กับผู้ที่ทำงานไปวันๆ ได้ ความแตกต่างนั้นไม่ใช่เรื่องเล็กน้อย—มันเหมือนกับความแตกต่างระหว่างซาลิเอรี (Salieri) กับโมซาร์ท (Mozart)
การศึกษาครั้งแล้วครั้งเล่าแสดงให้เห็นว่านักออกแบบที่เก่งที่สุดจะสร้างโครงสร้างที่เร็วขึ้น เล็กขึ้น เรียบง่ายขึ้น สะอาดตาขึ้น และสร้างด้วยความพยายามที่น้อยกว่า ความแตกต่างระหว่างผู้ออกแบบที่ยอดเยี่ยมกับที่อยู่ในระดับเฉลี่ยนั้นเข้าใกล้สิบเท่า (order of magnitude) การมองย้อนกลับไปเพียงเล็กน้อยจะเห็นว่า แม้ระบบซอฟต์แวร์ที่ดีและมีประโยชน์หลายระบบจะถูกออกแบบโดยคณะกรรมการและสร้างโดยโครงการที่มีหลายส่วนร่วมกัน แต่ระบบซอฟต์แวร์ที่สร้างความตื่นเต้นและมีแฟนคลับที่คลั่งไคล้คือระบบที่เป็นผลผลิตจากจิตใจของผู้ออกแบบเพียงคนเดียวหรือเพียงไม่กี่คน ซึ่งก็คือเหล่านักออกแบบที่ยิ่งใหญ่นั่นเอง ลองพิจารณา Unix, APL, Pascal, Modula, อินเทอร์เฟซของ Smalltalk หรือแม้แต่ Fortran แล้วนำไปเปรียบเทียบกับ Cobol, PL/I, Algol, MVS/370 และ MS-DOS (รูปที่ 16.1)
ดังนั้น แม้ผมจะสนับสนุนความพยายามในการถ่ายทอดเทคโนโลยีและการพัฒนาหลักสูตรที่กำลังดำเนินอยู่ในขณะนี้อย่างเต็มที่ แต่ผมคิดว่าความพยายามที่สำคัญที่สุดเพียงอย่างเดียวที่เราสามารถทำได้คือ การพัฒนาวิธีการเพื่อ "ปลูก" นักออกแบบที่ยิ่งใหญ่ขึ้นมา ไม่มีองค์กรซอฟต์แวร์ใดสามารถเพิกเฉยต่อความท้าทายนี้ได้ ผู้จัดการที่ดีแม้จะหายาก แต่ก็ไม่ได้หายากไปกว่านักออกแบบที่ดีเลย นักออกแบบที่ยิ่งใหญ่และผู้จัดการที่ยิ่งใหญ่ต่างก็หาได้ยากมากทั้งคู่ องค์กรส่วนใหญ่ทุ่มเทความพยายามอย่างมากในการค้นหาและบ่มเพาะผู้ที่มีศักยภาพจะเป็นผู้จัดการ แต่ผมไม่รู้จักองค์กรใดเลยที่ทุ่มเทความพยายามเท่ากันในการค้นหาและพัฒนานักออกแบบที่ยิ่งใหญ่ ซึ่งความเป็นเลิศทางเทคนิคของผลิตภัณฑ์จะต้องพึ่งพาพวกเขาในท้ายที่สุด
| สินค้าที่น่าตื่นเต้น |
|---|
| Unix |
| APL |
| Pascal |
| Modula |
| Smalltalk |
| Fortran |
รูปที่ 16.1 ผลิตภัณฑ์ที่น่าตื่นเต้น
ข้อเสนอแรกของผมคือ แต่ละองค์กรซอฟต์แวร์จะต้องกำหนดและประกาศว่านักออกแบบที่ยิ่งใหญ่มีความสำคัญต่อความสำเร็จขององค์กรพอๆ กับผู้จัดการที่ยิ่งใหญ่ และพวกเขาควรได้รับการดูแลเอาใจใส่และ...
ได้รับผลตอบแทนในระดับเดียวกัน ไม่เพียงแต่เรื่องเงินเดือนเท่านั้น แต่รวมถึงสิทธิพิเศษของการได้รับการยอมรับ ได้แก่ ขนาดห้องทำงาน เครื่องเรือน อุปกรณ์ทางเทคนิคส่วนตัว งบประมาณการเดินทาง และทีมงานสนับสนุน จะต้องเท่าเทียมกันอย่างสมบูรณ์
จะ "ปลูก" นักออกแบบที่ยิ่งใหญ่ได้อย่างไร? แม้พื้นที่ตรงนี้จะไม่เอื้ออำนวยให้พูดคุยอย่างละเอียดได้ แต่บางขั้นตอนก็นับว่าชัดเจน:
- ระบุตัวนักออกแบบระดับแนวหน้าอย่างเป็นระบบให้เร็วที่สุดเท่าที่จะเป็นไปได้ ผู้ออกแบบที่เก่งที่สุดมักจะไม่ใช่ผู้ที่มีประสบการณ์มากที่สุดเสมอไป
-
มอบหมายที่ปรึกษาด้านอาชีพ (
career mentor) เพื่อรับผิดชอบในการพัฒนาผู้ที่มีศักยภาพ และเก็บบันทึกประวัติการทำงานอย่างละเอียด - คิดค้นและรักษาแผนการพัฒนาอาชีพสำหรับผู้ที่มีศักยภาพแต่ละคน รวมถึงการฝึกงานที่คัดสรรมาอย่างดีกับนักออกแบบระดับแนวหน้า ช่วงเวลาของการรับการศึกษาระดับสูงอย่างเป็นทางการ และหลักสูตรระยะสั้น ทั้งหมดนี้สลับไปกับการมอบหมายงานออกแบบด้วยตนเองหรืองานผู้นำทางเทคนิค
- จัดหาโอกาสให้นักออกแบบที่กำลังเติบโตได้ปฏิสัมพันธ์และกระตุ้นซึ่งกันและกัน