Passing the Word
"เขาจะนั่งอยู่ตรงนี้แล้วพูดว่า 'ทำนี่สิ! ทำนั่นสิ!' แล้วก็จะไม่มีอะไรเกิดขึ้นเลย" — แฮร์รี เอส. ทรูแมน (HARRY S. TRUMAN), ว่าด้วยอำนาจของประธานาธิบดี
"แตรทั้งเจ็ด" (The Seven Trumpets) จาก The Wells Apocalypse, ศตวรรษที่ 14
สมมติว่าเขามีสถาปนิกที่มีระเบียบวินัยและมีประสบการณ์ และมีผู้ลงมือทำ (implementers) จำนวนมาก ผู้จัดการจะรับประกันได้อย่างไรว่าทุกคนจะได้ยิน เข้าใจ และนำการตัดสินใจของสถาปนิกไปปฏิบัติ? กลุ่มสถาปนิก 10 คนจะรักษาความสอดคล้องทางแนวคิด (conceptual integrity) ของระบบที่คน 1,000 คนกำลังสร้างได้อย่างไร? เทคโนโลยีทั้งหมดในการทำสิ่งนี้ได้รับการพัฒนาขึ้นสำหรับความพยายามในการออกแบบฮาร์ดแวร์ System/360 และมันก็สามารถนำมาปรับใช้กับโครงการซอฟต์แวร์ได้ดีเท่าๆ กัน
Written Specifications—the Manual
คู่มือ หรือข้อกำหนดที่เป็นลายลักษณ์อักษร เป็นเครื่องมือที่จำเป็น แม้จะยังไม่เพียงพอ คู่มือคือข้อกำหนดภายนอก (external specification) ของผลิตภัณฑ์ มันอธิบายและกำหนดทุกรายละเอียดของสิ่งที่ผู้ใช้มองเห็น ดังนั้น มันจึงเป็นผลิตภัณฑ์หลักของสถาปนิก วงจรการเตรียมคู่มือจะหมุนวนไปเรื่อยๆ ตามข้อเสนอแนะ (feedback) จากผู้ใช้และผู้ลงมือทำ ซึ่งจะแสดงให้เห็นว่าส่วนใดของงานออกแบบที่ใช้งานยากหรือสร้างยาก เพื่อเห็นแก่ผู้ลงมือทำ สิ่งสำคัญคือต้องมีการระบุการเปลี่ยนแปลงเป็นระยะๆ—คือต้องมีเวอร์ชันที่ระบุวันที่ซึ่งออกมาตามกำหนดการ คู่มือไม่เพียงแต่ต้องอธิบายทุกสิ่งที่ผู้ใช้มองเห็น รวมถึงอินเทอร์เฟซทั้งหมดเท่านั้น แต่ยังต้องละเว้นจากการอธิบายสิ่งที่ผู้ใช้มองไม่ได้เห็นด้วย นั่นเป็นเรื่องของผู้ลงมือทำ และในส่วนนั้นเสรีภาพในการออกแบบของเขาจะต้องไม่ถูกจำกัด สถาปนิกจะต้องเตรียมพร้อมเสมอที่จะแสดงการนำไปใช้งานสำหรับคุณสมบัติใดๆ ที่เขาอธิบายไว้ แต่เขาต้องไม่พยายามสั่งการการนำไปใช้งานนั้น รูปแบบการเขียนต้องมีความแม่นยำ ครบถ้วน และมีรายละเอียดที่ถูกต้อง ผู้ใช้มักจะอ้างอิงถึงคำจำกัดความเพียงอย่างเดียว ดังนั้นคำจำกัดความแต่ละอย่างจึงต้องทำซ้ำสาระสำคัญทั้งหมด และข้อมูลทั้งหมดต้องสอดคล้องกัน สิ่งนี้มักทำให้คู่มือเป็นสิ่งที่น่าเบื่อในการอ่าน แต่ความแม่นยำนั้นสำคัญกว่าความมีชีวิตชีวา
ความเป็นหนึ่งเดียวกันของ Principles of Operation ของ System/360 เกิดจากข้อเท็จจริงที่ว่ามีปากกาเพียงสองด้ามที่เขียนมัน: ของ Gerry Blaauw และ Andris Padegs ไอเดียต่างๆ มาจากคนประมาณสิบคน แต่การถ่ายทอดการตัดสินใจเหล่านั้นออกมาเป็นข้อกำหนดที่เป็นร้อยแก้วจะต้องทำโดยคนเพียงหนึ่งหรือสองคนเท่านั้น หากต้องการรักษาความสม่ำเสมอของเนื้อหาและผลิตภัณฑ์เอาไว้ เพราะการเขียนคำจำกัดความจะทำให้เกิดการตัดสินใจย่อยๆ จำนวนมาก ซึ่งไม่มีความสำคัญพอที่จะต้องนำมาถกเถียงกันอย่างเต็มรูปแบบ ตัวอย่างใน System/360 คือรายละเอียดของวิธีการตั้งรหัสสถานะ (Condition Code) หลังจากการทำงานแต่ละครั้ง อย่างไรก็ตาม สิ่งที่ไม่ใช่เรื่องเล็กน้อยคือหลักการที่ว่าการตัดสินใจย่อยๆ ดังกล่าวจะต้องทำอย่างสม่ำเสมอตลอดทั้งเล่ม
ผมคิดว่างานเขียนคู่มือที่ยอดเยี่ยมที่สุดเท่าที่ผมเคยเห็นมาคือภาคผนวกของ Blaauw ใน System/360 Principles of Operation ซึ่งอธิบายขีดจำกัดของความเข้ากันได้ (compatibility) ของ System/360 ด้วยความระมัดระวังและความแม่นยำ มันนิยาม...
ความเข้ากันได้ และกำหนดสิ่งที่ต้องทำให้สำเร็จ พร้อมทั้งระบุรายการพื้นที่ของสิ่งที่มองเห็นจากภายนอกซึ่งสถาปัตยกรรมจงใจที่จะนิ่งเฉยไว้ และผลลัพธ์จากเครื่องรุ่นหนึ่งอาจแตกต่างจากเครื่องอีกรุ่นหนึ่ง หรือเมื่อเครื่องรุ่นเดียวกันตัวหนึ่งอาจแตกต่างจากเครื่องรุ่นเดียวกันอีกตัวหนึ่ง หรือแม้แต่ความแตกต่างของเครื่องตัวเดิมหลังจากที่มีการเปลี่ยนแปลงทางวิศวกรรม นี่คือระดับของความแม่นยำที่นักเขียนคู่มือควรไปให้ถึง และพวกเขาจะต้องนิยามสิ่งที่ไม่ได้ถูกกำหนดไว้ให้ละเอียดพอๆ กับสิ่งที่ถูกกำหนดไว้
Formal Definitions
ภาษาอังกฤษ หรือภาษาของมนุษย์อื่นใด ไม่ใช่เครื่องมือที่มีความแม่นยำโดยธรรมชาติสำหรับคำจำกัดความดังกล่าว ดังนั้นนักเขียนคู่มือจึงต้องเค้นความสามารถของตนเองและภาษาของตนเพื่อให้บรรลุความแม่นยำที่จำเป็น ทางเลือกที่น่าสนใจคือการใช้สัญลักษณ์ที่เป็นทางการ (formal notation) สำหรับคำจำกัดความเหล่านั้น เพราะอย่างไรเสีย ความแม่นยำก็คือจุดขายหลักและเป็นเหตุผลหลักของการมีอยู่ของสัญลักษณ์ที่เป็นทางการ ให้เรามาพิจารณาข้อดีและข้อเสียของคำจำกัดความแบบเป็นทางการกัน
ดังที่ได้กล่าวไป คำจำกัดความแบบเป็นทางการนั้นมีความแม่นยำ และมักจะมีความครบถ้วน โดยช่องโหว่จะปรากฏให้เห็นได้ชัดเจนกว่า ดังนั้นจึงสามารถเติมเต็มได้เร็วกว่า สิ่งที่พวกมันขาดไปคือความเข้าใจง่าย เมื่อใช้ร้อยแก้วภาษาอังกฤษ เราสามารถแสดงหลักการทางโครงสร้าง อธิบายโครงสร้างเป็นขั้นตอนหรือระดับ และยกตัวอย่างประกอบได้ เราสามารถระบุข้อยกเว้นและเน้นย้ำความแตกต่างได้อย่างง่ายดาย และที่สำคัญที่สุดคือ เราสามารถอธิบายเหตุผลได้ คำจำกัดความแบบเป็นทางการที่เสนอออกมาจนถึงปัจจุบันมักสร้างความทึ่งในความสง่างามและความเชื่อมั่นในความแม่นยำ แต่พวกมันก็ต้องการคำอธิบายแบบร้อยแก้วเพื่อให้เนื้อหานั้นง่ายต่อการเรียนรู้และสอน ด้วยเหตุผลเหล่านี้ ผมคิดว่าในอนาคตเราจะเห็นข้อกำหนดที่ประกอบด้วยทั้งคำจำกัดความแบบเป็นทางการและคำจำกัดความแบบร้อยแก้ว
สุภาษิตโบราณเตือนไว้ว่า "อย่าออกทะเลโดยพกโครโนมิเตอร์ (chronometer) ไปสองเรือน ให้พกไปเรือนเดียวหรือสามเรือนเลย" สิ่งเดียวกันนี้ใช้ได้กับคำจำกัดความแบบร้อยแก้วและแบบเป็นทางการ หากมีทั้งสองอย่าง อย่างใดอย่างหนึ่งต้องเป็นมาตรฐาน และอีกอย่างหนึ่งต้องเป็นคำอธิบายที่อนุมานออกมา และต้องระบุไว้อย่างชัดเจนเช่นนั้น อย่างใดอย่างหนึ่งสามารถเป็นมาตรฐานหลักได้ ภาษา Algol 68 ใช้คำจำกัดความแบบเป็นทางการเป็นมาตรฐานและใช้แบบร้อยแก้วเป็นส่วนอธิบาย ส่วนภาษา PL/I ใช้แบบร้อยแก้วเป็นมาตรฐานและใช้แบบเป็นทางการเป็นส่วนอนุมาน System/360 ก็ใช้แบบร้อยแก้วเป็นมาตรฐานเช่นกัน โดยมีคำอธิบายแบบเป็นทางการเป็นส่วนอนุมาน
มีเครื่องมือมากมายสำหรับการทำคำจำกัดความแบบเป็นทางการ รูปแบบ Backus-Naur (Backus-Naur Form) เป็นที่คุ้นเคยสำหรับการนิยามภาษา และมีการพูดคุยกันอย่างกว้างขวางในเอกสารทางวิชาการ คำอธิบายแบบเป็นทางการของ PL/I ใช้แนวคิดใหม่ของไวยากรณ์นามธรรม (abstract syntax) และมีการอธิบายไว้อย่างเพียงพอ ส่วนภาษา APL ของ Iverson ก็ถูกนำมาใช้เพื่ออธิบายเครื่องจักร ที่โดดเด่นที่สุดคือ IBM 7090 และ System/360
Bell และ Newell ได้นำเสนอสัญลักษณ์ใหม่สำหรับอธิบายทั้งการกำหนดค่า (configurations) และสถาปัตยกรรมเครื่องจักร และพวกเขาได้สาธิตสิ่งเหล่านี้ด้วยเครื่องจักรหลายรุ่น รวมถึง DEC PDP-8, 7090 และ System/360 คำจำกัดความแบบเป็นทางการเกือบทั้งหมดกลายเป็นการรวบรวมหรืออธิบายถึงการนำไปใช้งาน (implementation) ของระบบฮาร์ดแวร์หรือซอฟต์แวร์ที่พวกมันกำลังกำหนดลักษณะภายนอกอยู่ ไวยากรณ์ (syntax) สามารถอธิบายได้โดยไม่ต้องใช้สิ่งนี้ แต่ความหมาย (semantics) มักจะถูกนิยามโดยการให้โปรแกรมที่ดำเนินการตามหน้าที่ที่กำหนดไว้ แน่นอนว่านี่คือการนำไปใช้งาน และในฐานะที่เป็นเช่นนั้น มันจึงเป็นการกำหนดสถาปัตยกรรมที่มากเกินไป (over-prescribes) ดังนันจึงต้องระมัดระวังในการระบุว่าคำจำกัดความแบบเป็นทางการนั้นใช้เฉพาะกับลักษณะภายนอกเท่านั้น และต้องระบุว่าลักษณะเหล่านั้นคืออะไร
ไม่เพียงแต่คำจำกัดความแบบเป็นทางการจะเป็นการนำไปใช้งานเท่านั้น แต่การนำไปใช้งานยังสามารถทำหน้าที่เป็นคำจำกัดความแบบเป็นทางการได้อีกด้วย เมื่อคอมพิวเตอร์ที่เข้ากันได้เครื่องแรกๆ ถูกสร้างขึ้น เทคนิคนี้คือสิ่งที่ถูกนำมาใช้ เครื่องใหม่จะต้องตรงกับเครื่องที่มีอยู่เดิม เมื่อคู่มือมีความคลุมเครือในบางจุด "ก็จงไปถามเครื่องดูสิ!" โปรแกรมทดสอบจะถูกสร้างขึ้นเพื่อกำหนดพฤติกรรม และเครื่องใหม่ก็จะถูกสร้างขึ้นเพื่อให้ตรงตามนั้น
โปรแกรมจำลอง (simulator) ของระบบฮาร์ดแวร์หรือซอฟต์แวร์สามารถทำหน้าที่ในลักษณะเดียวกันได้ทุกประการ มันคือการนำไปใช้งาน มันรันได้ ดังนั้นคำถามทั้งหมดเกี่ยวกับคำจำกัดความสามารถแก้ไขได้ด้วยการทดสอบมัน การใช้การนำไปใช้งานเป็นคำจำกัดความมีข้อดีบางประการ คือคำถามทั้งหมดสามารถตัดสินได้อย่างชัดเจนโดยการทดลอง ไม่จำเป็นต้องมีการโต้เถียง ดังนั้นจึงได้คำตอบที่รวดเร็ว คำตอบจะมีความแม่นยำเท่าที่ต้องการเสมอ และพวกมันถูกต้องเสมอโดยคำนิยาม ในทางตรงกันข้าม เราก็มีข้อเสียที่น่ากลัวหลายประการ การนำไปใช้งานอาจกำหนดรายละเอียดมากเกินไปแม้แต่ในส่วนของลักษณะภายนอก ไวยากรณ์ที่ไม่ถูกต้องมักจะให้ผลลัพธ์บางอย่างเสมอ ในระบบที่มีการควบคุม ผลลัพธ์นั้นจะเป็นการระบุถึงความไม่ถูกต้องและไม่มีอะไรเพิ่มเติม แต่ในระบบที่ไม่มีการควบคุม ผลกระทบข้างเคียง (side effects) ทุกประเภทอาจปรากฏขึ้น และสิ่งเหล่านี้อาจถูกนำไปใช้โดยเหล่านักเขียนโปรแกรม ตัวอย่างเช่น เมื่อเราดำเนินการจำลองการทำงาน (emulate) ของ IBM 1401 บน System/360 ปรากฏว่ามี "ของแปลก" (curios) ที่แตกต่างกันถึง 30 รายการ ซึ่งเป็นผลข้างเคียงของการทำงานที่คาดว่าไม่ถูกต้อง แต่ได้ถูกนำมาใช้งานอย่างแพร่หลายและต้องได้รับการพิจารณาว่าเป็นส่วนหนึ่งของคำจำกัดความ การใช้การนำไปใช้งานเป็นคำจำกัดความนั้นเป็นการกำหนดที่มากเกินไป มันไม่เพียงแต่บอกว่าเครื่องต้องทำอะไร แต่ยังบอกอีกมากว่ามันต้องทำอย่างไรด้วย ยิ่งไปกว่านั้น บางครั้งการนำไปใช้งานจะให้คำตอบที่คาดไม่ถึงและไม่ได้วางแผนไว้เมื่อมีการถามคำถามที่แหลมคม และมักจะพบว่าคำจำกัดความโดยพฤตินัยนั้นขาดความสง่างามในรายละเอียดเฉพาะเหล่านี้...
เพราะพวกมันไม่เคยได้รับการขบคิดมาก่อน ความไม่สง่างามนี้มักจะกลายเป็นเรื่องที่ทำซ้ำได้ยากหรือมีค่าใช้จ่ายสูงในการนำไปใช้งานในอีกรูปแบบหนึ่ง ตัวอย่างเช่น เครื่องจักรบางเครื่องจะทิ้งเศษขยะไว้ในรีจิสเตอร์ตัวคูณ (multiplicand register) หลังจากการคูณ ลักษณะที่แม่นยำของเศษขยะนี้กลายเป็นส่วนหนึ่งของคำจำกัดความโดยพฤตินัย ทว่าการทำซ้ำมันอาจขัดขวางการใช้อัลกอริทึมการคูณที่รวดเร็วกว่า และประการสุดท้าย การใช้การนำไปใช้งานเป็นคำจำกัดความแบบเป็นทางการนั้นมีความเสี่ยงเป็นพิเศษต่อความสับสนว่าคำอธิบายแบบร้อยแก้วหรือคำอธิบายแบบเป็นทางการกันแน่ที่เป็นมาตรฐาน ข้อนี้เป็นจริงอย่างยิ่งสำหรับโปรแกรมจำลอง และเราจะต้องงดเว้นจากการแก้ไขการนำไปใช้งานในขณะที่มันกำลังทำหน้าที่เป็นมาตรฐาน
Direct Incorporation
เทคนิคที่ยอดเยี่ยมสำหรับการเผยแพร่และบังคับใช้คำจำกัดความมีให้สำหรับสถาปนิกของระบบซอฟต์แวร์ มันมีประโยชน์อย่างยิ่งสำหรับการกำหนดไวยากรณ์ (syntax) ของอินเทอร์เฟซระหว่างโมดูล แม้ว่าอาจจะไม่รวมถึงความหมาย (semantics) ก็ตาม เทคนิคนี้คือการออกแบบการประกาศพารามิเตอร์ที่ส่งต่อหรือพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกัน และกำหนดให้การนำไปใช้งานต้องรวมการประกาศนั้นผ่านการทำงานในขณะคอมไพล์ (compile-time operation) เช่น แมโคร (macro) หรือ % INCLUDE นอกจากนี้ หากอินเทอร์เฟซทั้งหมดถูกอ้างอิงผ่านชื่อสัญลักษณ์เท่านั้น การประกาศสามารถเปลี่ยนแปลงได้โดยการเพิ่มหรือแทรกตัวแปรใหม่ผ่านการคอมไพล์ใหม่เพียงอย่างเดียว โดยไม่ต้องแก้ไขโปรแกรมที่ใช้งานอยู่
Conferences and Courts
ไม่ต้องสงสัยเลยว่าการประชุมนั้นจำเป็น การปรึกษาหารือแบบตัวต่อตัวนับร้อยครั้งจะต้องเสริมด้วยการรวมกลุ่มที่ใหญ่ขึ้นและเป็นทางการมากขึ้น เราพบว่าการประชุมสองระดับมีประโยชน์ ระดับแรกคือการประชุมครึ่งวันประจำสัปดาห์ของสถาปนิกทุกคน พร้อมด้วยตัวแทนอย่างเป็นทางการจากผู้ลงมือทำฮาร์ดแวร์และซอฟต์แวร์ และผู้วางแผนการตลาด โดยมีหัวหน้าสถาปนิกของระบบเป็นประธาน ใครก็ตามสามารถเสนอแนะปัญหาหรือการเปลี่ยนแปลงได้ แต่ข้อเสนอมักจะถูกแจกจ่ายเป็นลายลักษณ์อักษรก่อนการประชุม ปัญหาใหม่มักจะถูกอภิปรายกันสักพัก โดยเน้นที่ความคิดสร้างสรรค์มากกว่าเพียงแค่การตัดสินใจ กลุ่มจะพยายามคิดค้นวิธีแก้ปัญหามากมาย จากนั้นวิธีแก้ปัญหาบางส่วนจะถูกส่งไปยังสถาปนิกหนึ่งคนหรือมากกว่านั้นเพื่อลงรายละเอียดเป็นข้อเสนอการแก้ไขคู่มือที่ใช้ถ้อยคำที่แม่นยำ จากนั้นข้อเสนอการแก้ไขที่ละเอียดจะถูกนำมาตัดสินใจ ข้อเสนอเหล่านี้ได้ถูกหมุนเวียนและพิจารณาอย่างรอบคอบโดยผู้ลงมือทำและผู้ใช้ โดยมีการระบุข้อดีและข้อเสียไว้อย่างชัดเจน หากมีความเห็นพ้องต้องกัน (consensus) ก็ถือว่าดีมาก หากไม่ หัวหน้าสถาปนิกจะเป็นผู้ตัดสินใจ รายงานการประชุมจะถูกบันทึกไว้และการตัดสินใจจะถูกเผยแพร่อย่างเป็นทางการ รวดเร็ว และทั่วถึง
การตัดสินใจจากการประชุมประจำสัปดาห์จะให้ผลลัพธ์ที่รวดเร็วและช่วยให้งานดำเนินต่อไปได้ หากใครก็ตามไม่พอใจอย่างมาก ก็สามารถอุทธรณ์ต่อผู้จัดการโครงการได้ทันที แต่นี่เกิดขึ้นได้ยากมาก ความสำเร็จของการประชุมเหล่านี้มาจากหลายแหล่ง:
-
กลุ่มเดิม ซึ่งประกอบด้วยสถาปนิก ผู้ใช้ และผู้ลงมือทำ มาประชุมกันทุกสัปดาห์เป็นเวลาหลายเดือน ไม่จำเป็นต้องเสียเวลาในการสรุปข้อมูลให้ทันสมัยอยู่เสมอ
-
กลุ่มนี้มีความฉลาด มีไหวพริบ รอบรู้ในประเด็นต่างๆ และมีส่วนได้ส่วนเสียอย่างลึกซึ้งในผลลัพธ์ ไม่มีใครอยู่ในบทบาท "ที่ปรึกษา" ทุกคนได้รับอนุญาตให้ทำข้อตกลงที่มีผลผูกพันได้
-
เมื่อมีปัญหาถูกยกขึ้นมา วิธีแก้ปัญหาจะถูกค้นหาทั้งภายในและภายนอกขอบเขตที่เห็นได้ชัด
-
รูปแบบที่เป็นทางการของข้อเสนอที่เป็นลายลักษณ์อักษรช่วยให้ความสนใจจดจ่อ บังคับให้เกิดการตัดสินใจ และหลีกเลี่ยงความไม่สอดคล้องกันจากการร่างโดยคณะกรรมการ
-
การมอบอำนาจตัดสินใจให้แก่หัวหน้าสถาปนิกอย่างชัดเจนช่วยหลีกเลี่ยงการประนีประนอมและความล่าช้า
เมื่อเวลาผ่านไป การตัดสินใจบางอย่างก็อาจไม่ได้ผลดีเหมือนเดิม เรื่องเล็กน้อยบางเรื่องอาจไม่ได้รับการยอมรับอย่างเต็มใจจากผู้เข้าร่วมคนใดคนหนึ่ง การตัดสินใจอื่นอาจก่อให้เกิดปัญหาที่คาดไม่ถึง และบางครั้งการประชุมประจำสัปดาห์ก็ไม่เห็นชอบที่จะนำเรื่องเหล่านั้นมาพิจารณาใหม่ ดังนั้นจึงมีการสะสมของการอุทธรณ์เล็กๆ น้อยๆ ประเด็นที่ยังค้างอยู่ หรือความไม่พอใจ เพื่อจัดการกับสิ่งเหล่านี้ เราจึงจัดการประชุม "สภาสูงสุด" ประจำปี ซึ่งโดยปกติจะใช้เวลาสองสัปดาห์ (หากผมต้องทำอีกครั้ง ผมจะจัดทุกหกเดือน) เซสชันเหล่านี้จัดขึ้นก่อนกำหนดการ "แช่แข็ง" (freeze) คู่มือครั้งสำคัญ ผู้ที่เข้าร่วมไม่เพียงแต่กลุ่มสถาปัตยกรรมและตัวแทนนักเขียนโปรแกรมและสถาปัตยกรรมเท่านั้น แต่ยังรวมถึงผู้จัดการฝ่ายเขียนโปรแกรม การตลาด และผู้จัดการฝ่ายนำไปใช้งานอีกด้วย ผู้จัดการโครงการ System/360 เป็นประธาน วาระการประชุมมักประกอบด้วยรายการประมาณ 200 รายการ ซึ่งส่วนใหญ่เป็นเรื่องเล็กน้อย ซึ่งมีการจัดทำเป็นแผนภูมิแสดงไว้รอบห้อง ทุกฝ่ายจะได้รับฟังและมีการตัดสินใจเกิดขึ้น ด้วยความมหัศจรรย์ของการแก้ไขข้อความด้วยคอมพิวเตอร์ (และงานสนับสนุนที่ยอดเยี่ยม) ผู้เข้าร่วมแต่ละคนจะพบคู่มือที่อัปเดตแล้ว ซึ่งรวมถึงการตัดสินใจของเมื่อวาน วางอยู่ที่ที่นั่งของเขาทุกเช้า
"เทศกาลฤดูใบไม้ร่วง" เหล่านี้มีประโยชน์ไม่เพียงแต่ในการแก้ไขปัญหาการตัดสินใจเท่านั้น แต่ยังช่วยให้ผู้คนยอมรับการตัดสินใจเหล่านั้นด้วย ทุกคนได้รับการรับฟัง ทุกคนได้มีส่วนร่วม ทุกคนเข้าใจข้อจำกัดและความสัมพันธ์ระหว่างการตัดสินใจต่างๆ ที่ซับซ้อนได้ดียิ่งขึ้น
Multiple Implementations
สถาปนิกของ System/360 มีข้อได้เปรียบสองประการที่ไม่เคยมีมาก่อน: มีเวลาเพียงพอที่จะทำงานอย่างรอบคอบ และมีอำนาจต่อรองทางการเมืองเท่าเทียมกับผู้ลงมือทำ การมีเวลาเพียงพอมาจากกำหนดการของเทคโนโลยีใหม่ ส่วนความเท่าเทียมทางการเมืองมาจากการสร้างการนำไปใช้งานหลายรูปแบบพร้อมกัน ความจำเป็นในความเข้ากันได้ (compatibility) อย่างเคร่งครัดในหมู่เครื่องเหล่านี้ทำหน้าที่เป็นตัวบังคับใช้ข้อกำหนดที่ดีที่สุดเท่าที่จะเป็นไปได้ ในโครงการคอมพิวเตอร์ส่วนใหญ่ จะต้องมีวันที่พบว่าเครื่องจักรและคู่มือนั้นไม่ตรงกัน เมื่อเกิดการเผชิญหน้ากัน คู่มือมักจะเป็นฝ่ายแพ้ เพราะมันสามารถแก้ไขได้เร็วกว่าและถูกกว่าเครื่องจักรมาก อย่างไรก็ตาม เมื่อมีการนำไปใช้งานหลายรูปแบบ เรื่องนี้จะไม่เป็นเช่นนั้น เพราะความล่าช้าและค่าใช้จ่ายที่เกี่ยวข้องกับการแก้ไขเครื่องที่ทำงานผิดพลาดนั้นอาจสูงกว่าความล่าช้าและค่าใช้จ่ายในการแก้ไขเครื่องอื่นๆ ที่ปฏิบัติตามคู่มืออย่างซื่อสัตย์ แนวคิดนี้สามารถนำมาปรับใช้อย่างได้ผลเมื่อใดก็ตามที่มีการนิยามภาษาโปรแกรม มั่นใจได้เลยว่าไม่ช้าก็เร็วจะต้องมีการสร้างตัวแปลภาษา (interpreters) หรือตัวคอมไพล์ (compilers) หลายตัวเพื่อบรรลุวัตถุประสงค์ต่างๆ การนิยามจะมีความสะอาดและระเบียบวินัยจะเข้มงวดมากขึ้น หากมีการสร้างการนำไปใช้งานอย่างน้อยสองรูปแบบตั้งแต่เริ่มต้น
The Telephone Log
ในขณะที่การนำไปใช้งานดำเนินไป จะมีคำถามนับไม่ถ้วนเกี่ยวกับการตีความทางสถาปัตยกรรมเกิดขึ้น ไม่ว่าข้อกำหนดจะมีความแม่นยำเพียงใดก็ตาม เห็นได้ชัดว่าคำถามหลายข้อต้องการการขยายความและการทำให้ชัดเจนขึ้นในเนื้อหา ส่วนข้ออื่นๆ เพียงแค่สะท้อนถึงความเข้าใจผิด อย่างไรก็ตาม สิ่งสำคัญคือต้องส่งเสริมให้ผู้ลงมือทำที่สงสัย โทรศัพท์หาพิกัดสถาปนิกที่รับผิดชอบและถามคำถามของเขา แทนที่จะเดาเอาเองและดำเนินการต่อ และเป็นเรื่องสำคัญเท่าๆ กันที่จะต้องตระหนักว่าคำตอบของคำถามเหล่านั้นคือการประกาศทางสถาปัตยกรรมอย่างเป็นทางการ (ex cathedra) ซึ่งจะต้องแจ้งให้ทุกคนทราบ
กลไกที่มีประโยชน์ประการหนึ่งคือบันทึกการสนทนาทางโทรศัพท์ที่สถาปนิกจัดทำขึ้น ในนั้นเขาจะบันทึกทุกคำถามและทุกคำตอบ ในแต่ละสัปดาห์ บันทึกของสถาปนิกหลายๆ คนจะถูกนำมาต่อกัน ทำสำเนา และแจกจ่ายให้กับผู้ใช้และผู้ลงมือทำ แม้ว่ากลไกนี้จะไม่เป็นทางการนัก แต่มันก็ทั้งรวดเร็วและครอบคลุม
Product Test
เพื่อนที่ดีที่สุดของผู้จัดการโครงการคือคู่ปรับประจำวันของเขา ซึ่งก็คือองค์กรทดสอบผลิตภัณฑ์ที่เป็นอิสระ กลุ่มนี้จะตรวจสอบเครื่องจักรและโปรแกรมเทียบกับข้อกำหนด และทำหน้าที่เป็น "ทนายของปีศาจ" (devil's advocate) โดยชี้ให้เห็นทุกจุดบกพร่องและความคลาดเคลื่อนที่อาจเกิดขึ้นได้ ทุกองค์กรที่ทำการพัฒนาต้องการกลุ่มตรวจสอบทางเทคนิคที่เป็นอิสระเช่นนี้เพื่อให้เกิดความซื่อสัตย์ ในการวิเคราะห์ขั้นสุดท้าย ลูกค้าคือผู้ตรวจสอบที่เป็นอิสระ ในแสงสว่างที่ไร้ความปรานีของการใช้งานจริง ทุกจุดบกพร่องจะปรากฏให้เห็น ดังนั้นกลุ่มทดสอบผลิตภัณฑ์จึงเป็นตัวแทนของลูกค้า ซึ่งเชี่ยวชาญในการค้นหาข้อบกพร่อง ครั้งแล้วครั้งเล่าที่ผู้ทดสอบผลิตภัณฑ์ที่รอบคอบจะพบจุดที่ไม่มีการแจ้งข่าวสารให้ทราบ จุดที่การตัดสินใจออกแบบไม่ได้รับการเข้าใจอย่างถูกต้อง หรือการนำไปใช้งานที่ไม่แม่นยำ ด้วยเหตุผลนี้ กลุ่มทดสอบดังกล่าวจึงเป็นข้อต่อที่จำเป็นในห่วงโซ่ที่ส่งผ่านข่าวสารด้านการออกแบบ ซึ่งเป็นข้อต่อที่ต้องเริ่มทำงานตั้งแต่เนิ่นๆ และดำเนินไปพร้อมๆ กับการออกแบบ