เขาจะนั่งอยู่ตรงนี้และพูดว่า "ทำนี่! ทำนั่น!" แต่ก็ไม่มีอะไรเกิดขึ้น
— HARRY S TRUMAN, ON PRESIDENTIAL POWER [1]
สมมติว่าเขามีทีมสถาปนิกที่มีวินัยและประสบการณ์ และมีนักพัฒนา (implementers) จำนวนมาก ผู้จัดการจะมั่นใจได้อย่างไรว่าทุกคนได้รับฟัง เข้าใจ และนำการตัดสินใจของสถาปนิกไปปฏิบัติ? กลุ่มสถาปนิก 10 คนจะรักษาความสมบูรณ์ทางแนวคิด (conceptual integrity) ของระบบที่คน 1000 คนกำลังสร้างได้อย่างไร? เทคโนโลยีทั้งชุดสำหรับการทำสิ่งนี้ได้รับการพัฒนาขึ้นในความพยายามออกแบบฮาร์ดแวร์ System/360 และมันก็ใช้ได้กับโปรเจกต์ซอฟต์แวร์เช่นเดียวกัน
Written Specifications—the Manual (ข้อกำหนดที่เป็นลายลักษณ์อักษร — คู่มือ)
คู่มือหรือข้อกำหนดที่เป็นลายลักษณ์อักษร (written specification) เป็นเครื่องมือที่จำเป็น แต่ไม่ใช่เครื่องมือที่เพียงพอ คู่มือคือข้อกำหนดภายนอก (external specification) ของผลิตภัณฑ์ มันอธิบายและกำหนดทุกรายละเอียดที่ผู้ใช้เห็น ด้วยเหตุนี้ มันจึงเป็นผลงานหลักของสถาปนิก
วงจรการจัดเตรียมดำเนินไปวนเวียน เมื่อ feedback จากผู้ใช้และนักพัฒนา (implementers) ชี้ให้เห็นว่าจุดไหนของการออกแบบที่ใช้งานหรือสร้างได้ยาก เพื่อประโยชน์ของนักพัฒนา การเปลี่ยนแปลงควรถูกแบ่งเป็นชุด (quantized) — นั่นคือควรมีเวอร์ชันที่มีวันที่ปรากฏตามตารางเวลา
คู่มือต้องไม่เพียงแค่อธิบายทุกสิ่งที่ผู้ใช้เห็น รวมถึง interfaces ทั้งหมดเท่านั้น แต่ยังต้องละเว้นจากการอธิบายสิ่งที่ผู้ใช้ไม่เห็นด้วย นั่นคือเรื่องของนักพัฒนา (implementer) และในส่วนนั้น เสรีภาพในการออกแบบของเขาจะต้องไม่มีข้อจำกัด สถาปนิกต้องพร้อมเสมอที่จะแสดง implementation หนึ่งสำหรับ feature ใดๆ ที่เขาอธิบาย แต่เขาต้องไม่พยายาม dictate การ implementation
รูปแบบต้องแม่นยำ ครบถ้วน และมีรายละเอียดที่ถูกต้อง ผู้ใช้มักจะอ้างถึงคำนิยามใดคำนิยามหนึ่ง ดังนั้นแต่ละคำนิยามต้องกล่าวถึงสาระสำคัญทั้งหมดซ้ำ และทั้งหมดต้องสอดคล้องกัน ซึ่งมักทำให้คู่มืออ่านน่าเบื่อ แต่ความแม่นยำสำคัญกว่าความมีชีวิตชีวา
ความเป็นเอกภาพของ System/360's Principles of Operation เกิดจากความจริงที่มีเพียงสองคนเท่านั้นที่เป็นคนเขียน: Gerry Blaauw และ Andris Padegs แนวคิดต่างๆ มาจากคนประมาณสิบคน แต่การหล่อหลอมการตัดสินใจเหล่านั้นให้เป็นข้อกำหนดในรูปแบบร้อยแก้วต้องทำโดยคนเพียงหนึ่งหรือสองคนเท่านั้น หากต้องการคงความสอดคล้องของเนื้อหาและผลิตภัณฑ์ไว้ เพราะการเขียนคำนิยามจะต้องมีการตัดสินใจเล็กๆ น้อยๆ (mini-decisions) มากมายที่ไม่สำคัญพอจะต้องถกเถียงกันเต็มรูปแบบ ตัวอย่างใน System/360 คือรายละเอียดว่า Condition Code ถูก set อย่างไรหลังจากแต่ละ operation อย่างไรก็ตาม สิ่งที่ไม่ใช่เรื่องเล็กคือหลักการที่ว่าการตัดสินใจเล็กๆ น้อยๆ เหล่านี้ต้องทำอย่างสอดคล้องกันตลอดทั้งระบบ
ผมคิดว่าชิ้นงานเขียนคู่มือที่ยอดเยี่ยมที่สุดเท่าที่ผมเคยเห็นคือภาคผนวกของ Blaauw ใน System/360 Principles of Operation ซึ่งอธิบายอย่างละเอียดและแม่นยำถึง ขีดจำกัด (limits) ของความเข้ากันได้ของ System/360 มันนิยามความเข้ากันได้ กำหนดสิ่งที่ต้องทำให้สำเร็จ และแจกแจงพื้นที่ของรูปลักษณ์ภายนอกที่สถาปัตยกรรมจงใจไม่กล่าวถึง (intentionally silent) และที่ผลลัพธ์จากรุ่นหนึ่งอาจแตกต่างจากอีกรุ่นหนึ่ง ที่เครื่องหนึ่งของรุ่นที่กำหนดอาจแตกต่างจากอีกเครื่องหนึ่ง หรือที่เครื่องเดียวกันอาจแตกต่างจากตัวเองหลังจากมีการเปลี่ยนแปลงทางวิศวกรรม นี่คือระดับความแม่นยำที่นักเขียนคู่มือปรารถนา และพวกเขาต้องนิยามสิ่งที่ ไม่ได้ ถูกกำหนดไว้อย่างระมัดระวังพอๆ กับสิ่งที่ถูกกำหนดไว้
Formal Definitions (นิยามในรูปแบบทางการ)
ภาษาอังกฤษ หรือภาษามนุษย์อื่นใด ไม่ใช่เครื่องมือที่มีความแม่นยำโดยธรรมชาติสำหรับนิยามดังกล่าว ดังนั้นนักเขียนคู่มือต้องบีบเค้นตัวเองและภาษาของเขาเพื่อให้ได้ความแม่นยำที่ต้องการ ทางเลือกที่น่าสนใจคือการใช้ formal notation สำหรับนิยามเหล่านี้ ท้ายที่สุดแล้ว ความแม่นยำคือสินค้าหลัก คือ raison d'être ของ formal notations
ลองมาดูข้อดีและข้อเสียของ formal definitions กัน ดังที่ได้กล่าวไว้ formal definitions มีความแม่นยำ พวกมันมักจะสมบูรณ์ จุดบกพร่อง (gaps) จะเห็นได้ชัดเจนกว่า จึงถูกเติมเต็มได้เร็วกว่า สิ่งที่พวกมันขาดคือความเข้าใจได้ (comprehensibility) ด้วยร้อยแก้วภาษาอังกฤษ เราสามารถแสดงหลักการเชิงโครงสร้าง อธิบายโครงสร้างเป็นขั้นตอนหรือระดับ และยกตัวอย่างได้ เราสามารถระบุข้อยกเว้นและเน้นความแตกต่างได้อย่างง่ายดาย ที่สำคัญที่สุด เราสามารถอธิบาย ว่าทำไม (why) formal definitions ที่นำเสนอมาจนถึงตอนนี้สร้างความประทับใจในความสง่างามและความมั่นใจในความแม่นยำ แต่มันก็ต้องการคำอธิบายในรูปแบบร้อยแก้วเพื่อทำให้เนื้อหาเรียนรู้และสอนได้ง่าย ด้วยเหตุผลเหล่านี้ ผมคิดว่าเราจะเห็นข้อกำหนดในอนาคตประกอบด้วยทั้ง formal definition และ prose definition
สุภาษิตโบราณเตือนว่า "อย่าพา chronometer สองเรือนลงทะเล ให้พาเรือนเดียวหรือสามเรือน" หลักการเดียวกันนี้ใช้ได้กับ prose และ formal definitions อย่างชัดเจน ถ้ามีทั้งสองอย่าง ต้องให้อย่างใดอย่างหนึ่งเป็นมาตรฐาน (standard) และอีกอย่างเป็นคำอธิบายที่สืบทอดมา (derivative description) โดยระบุให้ชัดเจนว่าอันไหนคืออะไร อย่างใดก็ได้ที่สามารถเป็นมาตรฐานหลัก Algol 68 ใช้ formal definition เป็นมาตรฐานและ prose definition เป็นคำอธิบาย PL/I ใช้ prose เป็นมาตรฐานและ formal description เป็น derivative System/360 ก็ใช้ prose เป็นมาตรฐานโดยมี formal description ที่สืบทอดมา
มีเครื่องมือมากมายสำหรับ formal definition Backus-Naur Form เป็นที่คุ้นเคยสำหรับการนิยามภาษา และได้รับการกล่าวถึงอย่างกว้างขวางในวรรณกรรม [2] formal description ของ PL/I ใช้แนวคิดใหม่ของ abstract syntax และได้รับการอธิบายอย่างเพียงพอ [3] APL ของ Iverson ถูกใช้เพื่ออธิบายเครื่องจักร โดยเฉพาะ IBM 7090 [4] และ System/360 [5]
Bell และ Newell ได้เสนอ notations ใหม่สำหรับการอธิบายทั้ง configurations และ machine architectures และพวกเขาได้แสดงให้เห็นด้วยเครื่องจักรหลายเครื่อง รวมถึง DEC PDP-8 [6] the 7090 [7] และ System/360 [8]
formal definitions เกือบทั้งหมดกลายเป็นว่าบรรจุหรืออธิบาย implementation ของระบบฮาร์ดแวร์หรือซอฟต์แวร์ที่กำหนดคุณสมบัติภายนอก (externals) ไว้ สามารถอธิบาย syntax ได้โดยไม่ต้องทำเช่นนี้ แต่ semantics มักจะถูกนิยามโดยการให้โปรแกรมที่ดำเนินการตามที่กำหนดไว้ ซึ่งแน่นอนว่าเป็น implementation และด้วยเหตุนี้มันจึง over-prescribe สถาปัตยกรรม ดังนั้นเราต้องระวังที่จะชี้แจงว่า formal definition ใช้กับ externals เท่านั้น และต้องบอกว่าสิ่งเหล่านั้นคืออะไร
ไม่เพียงแค่ formal definition เป็น implementation เท่านั้น แต่ implementation ยังสามารถทำหน้าที่เป็น formal definition ได้อีกด้วย เมื่อคอมพิวเตอร์ที่เข้ากันได้ (compatible) เครื่องแรกถูกสร้างขึ้น นี่คือเทคนิคที่ใช้เป๊ะๆ เครื่องใหม่ต้องทำงานตรงกับเครื่องที่มีอยู่ คู่มือคลุมเครือในบางจุด? "ถามเครื่องสิ!" โปรแกรมทดสอบจะถูกสร้างขึ้นเพื่อหาพฤติกรรม และเครื่องใหม่ก็จะถูกสร้างให้ตรงตามนั้น
simulator ที่ถูกโปรแกรมของระบบฮาร์ดแวร์หรือซอฟต์แวร์ก็สามารถทำหน้าที่ในแบบเดียวกันได้ มันคือ implementation มันรันได้ ดังนั้นทุกคำถามเกี่ยวกับนิยามสามารถแก้ไขได้โดยการทดสอบมัน
การใช้ implementation เป็น definition มีข้อดีอยู่บ้าง คำถามทั้งหมดสามารถยุติได้อย่างไม่คลุมเครือด้วยการทดลอง ไม่จำเป็นต้องมีการโต้แย้ง ดังนั้นคำตอบจึงรวดเร็ว คำตอบมีความแม่นยำเท่าที่ต้องการเสมอ และถูกต้องเสมอโดยนิยาม ข้อเสียที่เผชิญอยู่นั้นมีมากมายมหาศาล implementation อาจ over-prescribe แม้กระทั่ง externals syntax ที่ไม่ถูกต้อง (invalid syntax) ก็ให้ผลลัพธ์บางอย่างเสมอ ในระบบที่มีการตรวจสอบ (policed system) ผลลัพธ์นั้นคือการบ่งชี้ความไม่ถูกต้อง (invalidity indication) และไม่มีอะไรอื่นอีก ในระบบที่ไม่มีการตรวจสอบ (unpoliced system) อาจเกิด side effects ทุกประเภท และเหล่านี้อาจถูกใช้โดย programmers เมื่อเราพยายาม emulate IBM 1401 บน System/360 ตัวอย่างเช่น ปรากฏว่ามี "curios" ถึง 30 อย่าง—side effects ของ operations ที่ควรจะไม่ถูกต้อง—ที่ถูกใช้อย่างแพร่หลายและต้องถูกพิจารณาเป็นส่วนหนึ่งของนิยาม การใช้ implementation เป็น definition นั้น over-prescribe มันไม่เพียงบอกว่าเครื่องต้องทำอะไร แต่มันยังบอกอีกมากมายว่าต้องทำมันอย่างไร
นอกจากนี้ implementation บางครั้งก็ให้คำตอบที่ไม่คาดคิดและไม่ได้วางแผนไว้เมื่อถูกถามคำถามที่เจาะลึก และ de facto definition มักจะพบว่าขาดความสง่างาม (inelegant) ในรายละเอียดเหล่านี้เพราะมันไม่เคยได้รับการคิดไตร่ตรองมาก่อน ความไม่สง่างามนี้มักจะกลายเป็นสิ่งที่ช้าหรือมีต้นทุนสูงในการทำซ้ำใน implementation อื่น ตัวอย่างเช่น เครื่องบางเครื่องทิ้ง trash ไว้ใน multiplicand register หลังจากการคูณ ลักษณะที่แน่นอนของ trash นี้กลายเป็นส่วนหนึ่งของ de facto definition แต่การทำซ้ำมันอาจขัดขวางการใช้ algorithm การคูณที่เร็วกว่า
สุดท้าย การใช้ implementation เป็น formal definition นั้นมีโอกาสทำให้เกิดความสับสนได้เป็นพิเศษว่าข้อความอธิบายแบบร้อยแก้ว (prose description) หรือ formal description กันแน่ที่เป็นมาตรฐาน โดยเฉพาะอย่างยิ่งกับ programmed simulations นอกจากนี้ยังต้องงดการแก้ไข implementation ในขณะที่มันทำหน้าที่เป็นมาตรฐานด้วย
Direct Incorporation (การรวมโดยตรง)
มีเทคนิคที่ยอดเยี่ยมสำหรับการเผยแพร่และบังคับใช้นิยามต่างๆ ที่มีให้สำหรับสถาปนิกระบบซอฟต์แวร์ มันมีประโยชน์โดยเฉพาะสำหรับการกำหนด syntax (หากไม่ใช่ semantics) ของ interfaces ระหว่างโมดูล (intermodule interfaces) เทคนิคนี้คือการออกแบบ declaration ของพารามิเตอร์ที่ส่งผ่าน (passed parameters) หรือ shared storage และให้ implementations รวม declaration นั้นผ่านการทำงานในขั้นตอน compile-time (macro หรือ %INCLUDE ใน PL/I) ยิ่งไปกว่านั้น หากทั้ง interface ถูกอ้างอิงด้วย symbolic names เท่านั้น declaration ก็สามารถเปลี่ยนแปลงได้โดยการเพิ่มหรือแทรกตัวแปรใหม่ โดยต้องทำการ recompilation เท่านั้น ไม่ต้องแก้ไขโปรแกรมที่ใช้งาน (using program)
Conferences and Courts (การประชุมและศาล)
ไม่ต้องพูดเลยว่าการประชุมเป็นสิ่งจำเป็น การปรึกษาหารือแบบตัวต่อตัวหลายร้อยครั้งต้องเสริมด้วยการรวมกลุ่มที่ใหญ่ขึ้นและเป็นทางการมากขึ้น เราพบว่าการประชุมสองระดับนี้มีประโยชน์ ระดับแรกคือการประชุมครึ่งวันทุกสัปดาห์ของสถาปนิกทั้งหมด พร้อมด้วยตัวแทนอย่างเป็นทางการของนักพัฒนาฮาร์ดแวร์และซอฟต์แวร์ (implementers) และนักวางแผนการตลาด (market planners) โดยมีหัวหน้าสถาปนิกระบบ (chief system architect) เป็นประธาน
ใครก็ได้สามารถเสนอปัญหาหรือการเปลี่ยนแปลงได้ แต่ข้อเสนอ (proposals) มักจะถูกแจกจ่ายเป็นลายลักษณ์อักษรก่อนการประชุม ปัญหาใหม่มักถูกอภิปรายสักพัก โดยเน้นที่ความคิดสร้างสรรค์ มากกว่าการตัดสินใจเพียงอย่างเดียว กลุ่มพยายามคิดค้นหลาย solutions สำหรับปัญหา จากนั้น solutions สองสามอย่างถูกส่งต่อไปยังสถาปนิกหนึ่งคนหรือมากกว่าเพื่อลงรายละเอียดเป็นข้อเสนอการเปลี่ยนแปลงคู่มือ (manual change proposals) ที่ใช้ภาษาที่แม่นยำ
จากนั้นข้อเสนอการเปลี่ยนแปลงที่มีรายละเอียด (detailed change proposals) ก็มาถึงขั้นตอนการตัดสินใจ สิ่งเหล่านี้ถูกแจกจ่ายและพิจารณาอย่างรอบคอบโดยนักพัฒนาและผู้ใช้ และข้อดีข้อเสียถูกระบุไว้อย่างชัดเจน ถ้ามีฉันทามติเกิดขึ้น ก็ดีไป ถ้าไม่ หัวหน้าสถาปนิก (chief architect) เป็นคนตัดสินใจ มีการจดบันทึกการประชุม (minutes) และการตัดสินใจต่างๆ จะถูกเผยแพร่ในรูปแบบที่เป็นทางการ รวดเร็ว และทั่วถึง
การตัดสินใจจากการประชุมประจำสัปดาห์ให้ผลลัพธ์ที่รวดเร็วและช่วยให้งานดำเนินต่อไปได้ ถ้าใคร ไม่พอใจมากเกินไป ก็สามารถอุทธรณ์ต่อผู้จัดการโปรเจกต์ (project manager) ได้ทันที แต่สิ่งนี้เกิดขึ้นน้อยมาก
ความอุดมสมบูรณ์ของการประชุมเหล่านี้เกิดจากหลายแหล่ง:
1. กลุ่มคนกลุ่มเดียวกัน—สถาปนิก ผู้ใช้ และนักพัฒนา—ประชุมกันทุกสัปดาห์เป็นเวลาหลายเดือน ไม่ต้องใช้เวลาในการอัปเดตสถานะให้คนอื่นๆ
2. กลุ่มคนนี้ฉลาด มีไหวพริบ เชี่ยวชาญในประเด็นต่างๆ และมีส่วนร่วมอย่างลึกซึ้งในผลลัพธ์ ไม่มีใครมีบทบาท "ที่ปรึกษา (advisory)" ทุกคนได้รับอำนาจในการทำข้อผูกพันที่มีผลผูกพัน (binding commitments)
3. เมื่อมีปัญหาถูกยกขึ้นมา จะมีการหา solutions ทั้งภายในและภายนอกขอบเขตที่ชัดเจน
4. ความเป็นทางการของข้อเสนอที่เป็นลายลักษณ์อักษรช่วยโฟกัสความสนใจ บังคับให้เกิดการตัดสินใจ และหลีกเลี่ยงความไม่สอดคล้องที่เกิดจากการร่างโดยคณะกรรมการ (committee-drafted inconsistencies)
5. การมอบอำนาจการตัดสินใจ (decision-making power) ไว้ที่หัวหน้าสถาปนิกอย่างชัดเจนช่วยหลีกเลี่ยงการประนีประนอมและความล่าช้า
เมื่อเวลาผ่านไป การตัดสินใจบางอย่างก็ไม่ยั่งยืน เรื่องเล็กๆ น้อยๆ บางเรื่องก็ไม่เคยได้รับการยอมรับอย่างเต็มที่จากผู้เข้าร่วมคนใดคนหนึ่ง การตัดสินใจอื่นๆ ก่อให้เกิดปัญหาที่ไม่คาดฝัน และบางครั้งการประชุมประจำสัปดาห์ก็ไม่ตกลงที่จะพิจารณาสิ่งเหล่านั้นใหม่ ดังนั้นจึงเกิดการสะสมของคำอุทธรณ์เล็กๆ น้อยๆ (minor appeals) ประเด็นที่เปิดค้างอยู่ (open issues) หรือความไม่พอใจ (disgruntlements) เพื่อจัดการกับสิ่งเหล่านี้ เราจัดการประชุมใหญ่ประจำปีแบบศาลสูง (supreme court sessions) ซึ่งปกติใช้เวลาสองสัปดาห์ (ถ้าผมทำอีกครั้ง ผมจะจัดทุกหกเดือน)
การประชุมเหล่านี้จัดขึ้นก่อนวัน freeze ครั้งใหญ่ของคู่มือ ผู้เข้าร่วมไม่เพียงรวมถึงกลุ่มสถาปนิกและตัวแทนทางสถาปัตยกรรมของโปรแกรมเมอร์และนักพัฒนาเท่านั้น แต่ยังรวมถึงผู้จัดการฝ่ายโปรแกรมมิ่ง การตลาด และการ implementation ด้วย โดยมีผู้จัดการโปรเจกต์ System/360 เป็นประธาน วาระการประชุมมักประกอบด้วยประมาณ 200 รายการ ซึ่งส่วนใหญ่เป็นเรื่องเล็กน้อย ซึ่งถูกระบุไว้ในแผนภูมิที่ติดรอบห้อง ทุกฝ่ายได้รับฟังและมีการตัดสินใจ ด้วยปาฏิหาริย์ของการแก้ไขข้อความด้วยคอมพิวเตอร์ (และงานสนับสนุนที่ดีเยี่ยมมากมาย) ผู้เข้าร่วมแต่ละคนพบว่ามีคู่มือที่อัปเดตแล้ว ซึ่งรวมการตัดสินใจของเมื่อวานไว้ วางอยู่ที่ที่นั่งของเขาทุกเช้า
"เทศกาลฤดูใบไม้ร่วง (fall festivals)" เหล่านี้มีประโยชน์ไม่เพียงแค่สำหรับการยุติการตัดสินใจ แต่ยังสำหรับการให้การตัดสินใจเหล่านั้นได้รับการยอมรับอีกด้วย ทุกคนได้รับฟัง ทุกคนมีส่วนร่วม ทุกคนเข้าใจข้อจำกัดซับซ้อน (intricate constraints) และความสัมพันธ์ระหว่างการตัดสินใจต่างๆ ได้ดียิ่งขึ้น
Multiple Implementations (การมีหลาย Implementations)
สถาปนิก System/360 มีข้อได้เปรียบสองอย่างที่แทบไม่เคยมีมาก่อน: เวลาที่เพียงพอในการทำงานอย่างรอบคอบ และอำนาจทางการเมือง (political clout) ที่เท่าเทียมกับนักพัฒนา การมีเวลาที่เพียงพอมาจากตารางเวลาของเทคโนโลยีใหม่ ความเท่าเทียมทางการเมืองมาจากการสร้าง multiple implementations พร้อมกัน ความจำเป็นในการเข้ากันได้อย่างเคร่งครัด (strict compatibility) ระหว่าง implementations เหล่านี้ทำหน้าที่เป็นตัวบังคับใช้ข้อกำหนด (enforcing agent) ที่ดีที่สุด
ในโปรเจกต์คอมพิวเตอร์ส่วนใหญ่ จะมีวันหนึ่งที่พบว่าเครื่องจักรกับคู่มือไม่ตรงกัน เมื่อการเผชิญหน้าเกิดขึ้น คู่มือมักจะพ่ายแพ้ เพราะสามารถเปลี่ยนแปลงได้เร็วกว่าและถูกกว่าการเปลี่ยนเครื่องจักรมาก แต่ไม่ใช่เมื่อมี multiple implementations เพราะความล่าช้าและต้นทุนที่เกี่ยวข้องกับการแก้ไขเครื่องที่ผิดพลาดอาจถูกกลบด้วยความล่าช้าและต้นทุนในการแก้ไขเครื่องที่ทำตามคู่มืออย่างถูกต้อง
แนวคิดนี้สามารถนำไปใช้ได้อย่างมีประโยชน์เมื่อใดก็ตามที่มีการนิยามภาษาโปรแกรมมิ่ง เรามั่นใจได้ว่า interpreters หรือ compilers หลายตัวจะต้องถูกสร้างขึ้นไม่ช้าก็เร็วเพื่อตอบสนองวัตถุประสงค์ต่างๆ นิยามจะสะอาดขึ้น (cleaner) และวินัยจะเข้มงวดขึ้น (tighter) ถ้าอย่างน้อยสอง implementations ถูกสร้างขึ้นตั้งแต่แรก
The Telephone Log (บันทึกการโทรศัพท์)
เมื่อการ implement ดำเนินไป คำถามนับไม่ถ้วนเกี่ยวกับการตีความทางสถาปัตยกรรม (architectural interpretation) เกิดขึ้น ไม่ว่าข้อกำหนดจะแม่นยำแค่ไหนก็ตาม แน่นอนว่าคำถามเหล่านี้จำนวนมากต้องการการขยายความและคำชี้แจงในข้อความ ส่วนอื่นๆ ก็แค่สะท้อนถึงความเข้าใจผิด
อย่างไรก็ตาม มันจำเป็นอย่างยิ่งที่จะสนับสนุนให้นักพัฒนาที่สับสนโทรศัพท์หาสถาปนิกที่รับผิดชอบและถามคำถามของเขา แทนที่จะเดาและทำงานต่อไป และที่สำคัญไม่แพ้กันคือต้องตระหนักว่าคำตอบของคำถามเหล่านี้คือคำประกาศทางสถาปัตยกรรมที่มีอำนาจ ex cathedra ที่ต้องบอกให้ทุกคนทราบ
กลไกที่มีประโยชน์อย่างหนึ่งคือ telephone log ที่สถาปนิกเก็บไว้ ในนั้นเขาบันทึกทุกคำถามและทุกคำตอบ ทุกสัปดาห์ logs ของสถาปนิกหลายคนจะถูกรวบรวม ทำสำเนา และแจกจ่ายให้กับผู้ใช้และนักพัฒนา แม้ว่ากลไกนี้จะค่อนข้างไม่เป็นทางการ แต่มันก็ทั้งรวดเร็วและครอบคลุม
Product Test (การทดสอบผลิตภัณฑ์)
เพื่อนที่ดีที่สุดของผู้จัดการโปรเจกต์คือคู่ปรับประจำวันของเขา นั่นคือองค์กรทดสอบผลิตภัณฑ์อิสระ (independent product-testing organization) กลุ่มนี้ตรวจสอบเครื่องจักรและโปรแกรมเทียบกับข้อกำหนด และทำหน้าที่เป็น devil's advocate ชี้ให้เห็นทุกข้อบกพร่องและความไม่สอดคล้องที่อาจเกิดขึ้นได้ ทุกองค์กรพัฒนาจำเป็นต้องมีกลุ่มตรวจสอบทางเทคนิคอิสระ (independent technical auditing group) แบบนี้เพื่อรักษาความซื่อสัตย์
ในที่สุดแล้ว ลูกค้าคือผู้ตรวจสอบอิสระที่แท้จริง ภายใต้แสงอันโหดร้ายของการใช้งานจริง ทุกจุดบกพร่องจะปรากฏให้เห็น กลุ่มทดสอบผลิตภัณฑ์จึงเป็นตัวแทนของลูกค้า (surrogate customer) ที่เชี่ยวชาญด้านการค้นหาจุดบกพร่อง ครั้งแล้วครั้งเล่า ผู้ทดสอบผลิตภัณฑ์ที่รอบคอบจะพบสถานที่ที่คำสั่งการออกแบบ (the word) ไม่ได้ถูกส่งต่อ ที่ซึ่งการตัดสินใจในการออกแบบไม่ได้รับการเข้าใจอย่างถูกต้องหรือนำไปปฏิบัติอย่างแม่นยำ ด้วยเหตุนี้ กลุ่มทดสอบดังกล่าวจึงเป็นลิงก์ที่จำเป็นในห่วงโซ่แห่งการส่งต่อคำสั่งการออกแบบ ซึ่งเป็นลิงก์ที่ต้องทำงานตั้งแต่เนิ่นๆ และพร้อมกันกับการออกแบบ