Aristocracy, Democracy, and System Design

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

— หนังสือแนะนำอาสนวิหารแร็งส์ (REIMS CATHEDRAL GUIDEBOOK)!

ภาพถ่ายโดย Emmanuel Boudot-Lamotte

Conceptual Integrity

อาสนวิหาร (cathedrals) ส่วนใหญ่ในยุโรปแสดงให้เห็นถึงความแตกต่างในด้านผังหรือรูปแบบทางสถาปัตยกรรมระหว่างส่วนต่างๆ ที่สร้างขึ้นในต่างยุคสมัยโดยช่างก่อสร้างคนละคนกัน ช่างรุ่นหลังมักถูกเย้ายวนให้ "ปรับปรุง" งานออกแบบของช่างรุ่นก่อน เพื่อสะท้อนถึงทั้งการเปลี่ยนแปลงของยุคสมัยและความแตกต่างในรสนิยมส่วนบุคคล ดังนั้น ส่วนขวางแบบนอร์มัน (Norman transept) ที่ดูเงียบสงบจึงตั้งตระหง่านขัดแย้งกับโถงกลางแบบโกธิค (Gothic nave) ที่พุ่งทะยาน และผลลัพธ์ที่ได้ก็ประกาศถึงความภาคภูมิใจในตนเองของช่างก่อสร้างพอๆ กับพระเกียรติสิริของพระเจ้า

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

แม้ว่าส่วนใหญ่จะไม่ได้ใช้เวลาสร้างนานเป็นศตวรรษ แต่ระบบการเขียนโปรแกรมส่วนใหญ่กลับสะท้อนถึงความไม่สอดคล้องทางแนวคิด (conceptual disunity) ที่แย่ยิ่งกว่าอาสนวิหารเสียอีก โดยปกติแล้วสิ่งนี้ไม่ได้เกิดจากการสืบทอดตำแหน่งหัวหน้านักออกแบบตามลำดับเวลา แต่เกิดจากการแบ่งงานออกแบบออกเป็นหลายงานที่ทำโดยคนหลายคน ผมจะยืนยันว่า ความสอดคล้องทางแนวคิด (conceptual integrity) คือข้อพิจารณาที่สำคัญที่สุดใน system design เป็นการดีกว่าที่จะให้ระบบตัดคุณสมบัติที่แปลกแยกและการปรับปรุงบางอย่างออกไป เพื่อสะท้อนถึงแนวคิดการออกแบบเพียงชุดเดียว ดีกว่าการมีระบบที่บรรจุแนวคิดที่ดีมากมายแต่เป็นอิสระต่อกันและไม่ประสานงานกัน

ในบทนี้และอีกสองบทถัดไป เราจะสำรวจผลลัพธ์ของประเด็นนี้ที่มีต่อ system design:

• เราจะบรรลุความสอดคล้องทางแนวคิดได้อย่างไร?

• ข้อโต้แย้งนี้ไม่ได้สื่อเป็นนัยถึงกลุ่มชนชั้นนำ (elite) หรือคณาธิปไตยของสถาปนิก (aristocracy of architects) และกลุ่มสามัญชนที่เป็นผู้ลงมือทำ (horde of plebeian implementers) ที่พรสวรรค์และความคิดสร้างสรรค์ของพวกเขาถูกกดทับไว้อย่างนั้นหรือ?

• เราจะป้องกันไม่ให้เหล่าสถาปนิก (architects) เลื่อนลอยไปกับ specifications ที่ไม่สามารถนำไปใช้งานจริงได้หรือมีต้นทุนที่สูงเกินไปได้อย่างไร?

• เราจะรับประกันได้อย่างไรว่ารายละเอียดเล็กน้อยทุกประการของ architectural specification จะถูกสื่อสารไปยังผู้ลงมือทำ (implementer) โดยที่เขาเข้าใจมันอย่างถูกต้อง และนำไปใส่ไว้ในผลิตภัณฑ์ได้อย่างแม่นยำ?

Achieving Conceptual Integrity

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

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

เพราะความง่ายในการใช้งานคือจุดประสงค์ อัตราส่วนของหน้าที่การทำงานต่อความซับซ้อนเชิงแนวคิดจึงเป็นบททดสอบสูงสุดของ system design ลำพังเพียงแค่หน้าที่การทำงานหรือ simplicity (ความเรียบง่าย) อย่างใดอย่างหนึ่งไม่สามารถนิยามการออกแบบที่ดีได้ ประเด็นนี้มักถูกเข้าใจผิดกันอย่างกว้างขวาง ระบบปฏิบัติการ OS/360 ได้รับการยกย่องจากผู้สร้างว่าเป็นระบบที่ดีที่สุดเท่าที่เคยสร้างมา เพราะมันมีหน้าที่การทำงานมากที่สุดอย่างไม่อาจปฏิเสธได้ สำหรับผู้ออกแบบระบบนี้ หน้าที่การทำงานไม่ใช่ simplicity คือมาตรวัดความเป็นเลิศเสมอมา ในทางกลับกัน ระบบ Time-Sharing สำหรับเครื่อง PDP-10 ก็ได้รับการยกย่องจากผู้สร้างว่าดีที่สุด เพราะ simplicity และความประหยัดในแนวคิดของมัน อย่างไรก็ตาม ไม่ว่าจะวัดด้วยมาตรฐานใด หน้าที่การทำงานของมันก็ยังไม่อาจเทียบชั้นได้กับ OS/360 ทันทีที่ความง่ายในการใช้งานถูกยกขึ้นมาเป็นเกณฑ์ เราก็จะเห็นว่าแต่ละระบบเหล่านี้ต่างก็ขาดความสมดุล โดยบรรลุเป้าหมายที่แท้จริงเพียงครึ่งเดียวเท่านั้น

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

ความเรียบง่าย (simplicity) ที่วัดด้วยจำนวนของแนวคิดพื้นฐานที่แยกจากกัน อย่างไรก็ตาม สิ่งเหล่านี้ไม่ได้ตรงไปตรงมาเสมอไป การแสดงออกถึงสิ่งที่ต้องการทำมักต้องใช้การผสมผสานสิ่งอำนวยความสะดวกพื้นฐานที่ซับซ้อนและคาดไม่ถึง การเรียนรู้เพียงแค่องค์ประกอบและกฎเกณฑ์การผสมผสานนั้นไม่เพียงพอ แต่ต้องเรียนรู้การใช้งานตามความนิยม (idiomatic usage) ซึ่งเป็นองค์ความรู้ทั้งหมดว่าองค์ประกอบเหล่านั้นถูกนำมาผสมผสานกันอย่างไรในการปฏิบัติจริง ความเรียบง่ายและความตรงไปตรงมาเกิดขึ้นจากความสอดคล้องทางแนวคิด (conceptual integrity) ทุกส่วนต้องสะท้อนถึงปรัชญาเดียวกันและการรักษาสมดุลของสิ่งที่ต้องการ (desiderata) แบบเดียวกัน ทุกส่วนต้องใช้เทคนิคเดียวกันในด้านไวยากรณ์ (syntax) และแนวคิดที่คล้ายคลึงกันในด้านความหมาย (semantics) ดังนั้น ความง่ายในการใช้งานจึงถูกกำหนดโดยความเป็นเอกภาพของการออกแบบและความสอดคล้องทางแนวคิด

Aristocracy and Democracy

ในทางกลับกัน ความสอดคล้องทางแนวคิด (conceptual integrity) กำหนดให้งานออกแบบต้องมาจากจิตใจเพียงดวงเดียว หรือจากกลุ่มคนจำนวนน้อยที่เห็นพ้องต้องกันและมีแนวคิดที่สอดประสานกัน อย่างไรก็ตาม ความกดดันเรื่องกำหนดการ (schedule) กลับกำหนดว่าการสร้างระบบนั้นต้องการแรงกายจำนวนมาก มีเทคนิคสองประการสำหรับแก้ปัญหาที่กลืนไม่เข้าคายไม่ออกนี้ ประการแรกคือ การแบ่งงานอย่างระมัดระวังระหว่างสถาปัตยกรรม (architecture) และการนำไปใช้งาน (implementation) ประการที่สองคือ วิธีใหม่ในการจัดโครงสร้างทีมงานเขียนโปรแกรมที่ได้พูดคุยกันในบทที่แล้ว การแยกความพยายามในด้านสถาปัตยกรรมออกจากการนำไปใช้งานเป็นวิธีที่ทรงพลังมากในการบรรลุความสอดคล้องทางแนวคิดในโครงการขนาดใหญ่ ผมเองเคยเห็นความสำเร็จอย่างยิ่งใหญ่จากการใช้วิธีนี้กับคอมพิวเตอร์ IBM Stretch และกลุ่มผลิตภัณฑ์คอมพิวเตอร์ System/360 และผมก็ได้เห็นความล้มเหลวจากการที่ไม่ได้ใช้วิธีนี้ใน Operating System/360

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

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

ใน System/360 ตัวอย่างเช่น สถาปัตยกรรมคอมพิวเตอร์เพียงชุดเดียวถูกนำไปใช้งานที่แตกต่างกันอย่างมากในแต่ละรุ่นจากทั้งหมดเก้ากลุ่ม ในทางกลับกัน การนำไปใช้งานเพียงชุดเดียว เช่น รูปแบบการไหลของข้อมูล หน่วยความจำ และไมโครโค้ด (microcode) ของ Model 30 กลับทำหน้าที่เป็นสถาปัตยกรรมที่แตกต่างกันสี่แบบในเวลาที่ต่างกัน ได้แก่: คอมพิวเตอร์ System/360, ช่องสัญญาณมัลติเพล็กซ์ (multiplex channel) ที่มีช่องสัญญาณย่อยที่เป็นอิสระต่อกันทางตรรกะสูงสุด 224 ช่อง, ช่องสัญญาณเลือก (selector channel) และคอมพิวเตอร์ 1401

การแบ่งแยกแบบเดียวกันนี้สามารถนำมาใช้กับระบบการเขียนโปรแกรมได้เช่นกัน มีมาตรฐาน Fortran IV ของสหรัฐอเมริกา ซึ่งเป็นสถาปัตยกรรมสำหรับคอมไพเลอร์หลายตัว ภายใต้สถาปัตยกรรมนี้ การนำไปใช้งานหลายรูปแบบก็เป็นไปได้: เช่น text-in-core หรือ compiler-in-core, การคอมไพล์แบบเร็วหรือแบบปรับให้เหมาะสม (optimizing), แบบเน้นไวยากรณ์ (syntax-directed) หรือแบบเฉพาะกิจ (ad-hoc) ในทำนองเดียวกัน ภาษาแอสเซมบลี (assembler language) หรือภาษาควบคุมงาน (job-control language) ใดๆ ก็ยอมให้มีการนำไปใช้งานของตัวแอสเซมเบลอร์หรือตัวจัดตารางงาน (scheduler) ได้หลายรูปแบบ

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

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

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

ยอมให้มีอรรถประโยชน์ในการออกแบบ ความคิดสร้างสรรค์ ไอเดียใหม่ๆ และความชาญฉลาดทางเทคนิคได้มากเท่ากับการออกแบบข้อกำหนดภายนอก อันที่จริง อัตราส่วนราคาต่อประสิทธิภาพ (cost-performance ratio) ของผลิตภัณฑ์จะขึ้นอยู่กับผู้ลงมือทำเป็นส่วนใหญ่ เช่นเดียวกับที่ความง่ายในการใช้งานขึ้นอยู่กับสถาปิกเป็นส่วนใหญ่ มีตัวอย่างมากมายจากศิลปะและงานฝีมืออื่นๆ ที่ทำให้คนเราเชื่อว่าระเบียบวินัยนั้นดีต่อศิลปะ อันที่จริง มีคำกล่าวของศิลปินที่ยืนยันว่า "รูปแบบคือการปลดปล่อย" อาคารที่แย่ที่สุดคืออาคารที่มีงบประมาณมากเกินไปสำหรับจุดประสงค์ที่ต้องการใช้งาน ผลงานสร้างสรรค์ของ Bach ดูเหมือนจะไม่ถูกบดบังเลยจากความจำเป็นในการแต่งเพลงคานตาตา (cantata) ในรูปแบบที่จำกัดทุกสัปดาห์ ผมแน่ใจว่าคอมพิวเตอร์ Stretch จะมีสถาปัตยกรรมที่ดีกว่านี้หากมันถูกจำกัดให้รัดกุมกว่านี้ ข้อจำกัดที่เกิดจากงบประมาณของ System/360 Model 30 ในความเห็นของผม เป็นประโยชน์อย่างยิ่งต่อสถาปัตยกรรมของ Model 75

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

What Does the Implementer Do While Waiting?

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

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

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

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

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

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

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

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

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

การเขียนโปรแกรมก็มีเทคโนโลยีเช่นกัน หากเครื่องคอมพิวเตอร์เป็นเครื่องรุ่นใหม่ จะต้องมีงานมากมายที่ต้องทำเกี่ยวกับข้อกำหนดการเรียกใช้รูทีนย่อย (subroutine conventions), เทคนิคการควบคุม (supervisory techniques), อัลกอริทึมการค้นหาและการจัดเรียง

ความสอดคล้องทางแนวคิด (conceptual integrity) ต้องการให้ระบบสะท้อนถึงปรัชญาเพียงหนึ่งเดียว และข้อกำหนดที่ผู้ใช้มองเห็นนั้นต้องมาจากจิตใจเพียงไม่กี่ดวง อย่างไรก็ตาม เนื่องจากการแบ่งงานตามความเป็นจริงออกเป็นสถาปัตยกรรม การนำไปใช้งาน และการทำให้เป็นจริง สิ่งนี้จึงไม่ได้หมายความว่าระบบที่ออกแบบด้วยวิธีนี้จะใช้เวลาสร้างนานขึ้น ประสบการณ์แสดงให้เห็นในทางตรงกันข้าม ว่าระบบที่รวมเป็นหนึ่งเดียวจะประกอบเข้าด้วยกันได้เร็วกว่าและใช้เวลาในการทดสอบน้อยกว่า ในความเป็นจริง การแบ่งงานตามขวาง (horizontal division of labor) ที่แพร่หลายได้ถูกลดทอนลงอย่างมากด้วยการแบ่งงานตามแนวตั้ง (vertical division of labor) และผลที่ได้คือการสื่อสารที่เรียบง่ายขึ้นอย่างมากและความสอดคล้องทางแนวคิดที่ได้รับการปรับปรุงดีขึ้น