มหาวิหารอันยิ่งใหญ่นี้คือผลงานศิลปะที่หาที่เปรียบมิได้ ไม่มีความแห้งแล้งหรือความสับสนในหลักคำสอนที่มันวางไว้ . . .
มันคือจุดสูงสุดของรูปแบบสถาปัตยกรรม เป็นผลงานของศิลปินที่เข้าใจและซึมซับความสำเร็จของบรรพชนทั้งหมด มีความเชี่ยวชาญในเทคนิคแห่งยุคสมัยอย่างสมบูรณ์ แต่ใช้มันโดยไม่โอ้อวดหรืออวดฝีมืออย่างไร้เหตุผล
ฌอง ดอร์เบ คือผู้ที่วางแผนโดยรวมของอาสนวิหารแห่งนี้อย่างไม่ต้องสงสัย แผนดังกล่าวได้รับการเคารพ อย่างน้อยก็ในองค์ประกอบสำคัญ โดยผู้สืบทอดของเขา นี่คือหนึ่งในเหตุผลที่ทำให้สิ่งก่อสร้างนี้มีความสอดคล้องและเป็นหนึ่งเดียวกันอย่างยิ่ง
— REIMS CATHEDRAL GUIDEBOOK [1]
Conceptual Integrity (ความสมบูรณ์ทางแนวคิด)
อาสนวิหารส่วนใหญ่ในยุโรปมีความแตกต่างในแผนผังหรือรูปแบบสถาปัตยกรรมระหว่างส่วนที่สร้างขึ้นในยุคสมัยต่างๆ โดยผู้สร้างที่ต่างกัน ผู้สร้างรุ่นหลังมักถูกล่อลวงให้ "ปรับปรุง" แบบแปลนของรุ่นก่อน เพื่อสะท้อนทั้งการเปลี่ยนแปลงของแฟชั่นและความแตกต่างในรสนิยมส่วนบุคคล ดังนั้นปีกนอนแบบนอร์มันที่สงบสุขจึงเข้ามาปะทะและขัดแย้งกับโถงกลางแบบโกธิกที่ทะยานสูง และผลลัพธ์ที่ได้ก็ประกาศถึงความเย่อหยิ่งของผู้สร้างไม่น้อยไปกว่าการสรรเสริญพระเกียรติของพระเจ้า
เมื่อเทียบกับสิ่งเหล่านี้ ความเป็นหนึ่งเดียวทางสถาปัตยกรรมของอาสนวิหารแร็งส์ก็โดดเด่นอย่างงดงาม ความปีติที่ปลุกเร้าผู้ชมนั้นมาจากความสมบูรณ์ของการออกแบบไม่น้อยไปกว่าความยอดเยี่ยมเฉพาะส่วนใดส่วนหนึ่ง ดังที่คู่มือกล่าวไว้ ความเป็นหนึ่งเดียวกันนี้เกิดขึ้นได้จากการสละอัตตาของผู้สร้างถึงแปดรุ่น แต่ละรุ่นยอม sacrifice แนวคิดบางอย่างของตน เพื่อให้ส่วนรวมคงไว้ซึ่งความบริสุทธิ์ของการออกแบบ ผลลัพธ์ที่ได้ไม่เพียงประกาศถึงพระเกียรติของพระเจ้าเท่านั้น แต่ยังประกาศถึงอำนาจของพระองค์ในการกอบกู้มนุษย์ที่ตกต่ำจากความเย่อหยิ่งของพวกเขา
แม้ว่าจะไม่ได้ใช้เวลานานนับศตวรรษในการสร้าง แต่ระบบซอฟต์แวร์ส่วนใหญ่กลับมีความไม่เป็นหนึ่งเดียวทางแนวคิดที่เลวร้ายยิ่งกว่าอาสนวิหารเสียอีก โดยปกติแล้วสิ่งนี้ไม่ได้เกิดจากการสืบทอดกันของนักออกแบบหลัก แต่เกิดจากการแบ่งงานออกเป็นหลายส่วนโดยคนจำนวนมาก
ผมจะยืนยันว่าความสมบูรณ์ทางแนวคิดคือ สิ่งสำคัญที่สุด ในการออกแบบระบบ การมีระบบที่ละเว้นคุณสมบัติและการปรับปรุงที่แปลกประหลาดบางอย่าง แต่สะท้อนแนวคิดการออกแบบชุดเดียวนั้น ดีกว่าการมีระบบที่ประกอบด้วยแนวคิดดีๆ มากมายแต่เป็นอิสระและไม่ประสานงานกัน ในบทนี้และสองบทถัดไป เราจะพิจารณาผลกระทบของแนวคิดนี้ต่อการออกแบบระบบซอฟต์แวร์:
• ความสมบูรณ์ทางแนวคิดจะบรรลุได้อย่างไร?
• ข้อโต้แย้งนี้ไม่ได้หมายถึงการมีชนชั้นนำ หรือกลุ่มสถาปนิกชั้นสูง และกลุ่มผู้พัฒนาสามัญชนจำนวนมากที่พรสวรรค์และความคิดสร้างสรรค์ถูกกดขี่ใช่หรือไม่?
• จะป้องกันไม่ให้สถาปนิกหลงทางไปกับสเปกที่ไม่สามารถนำไปปฏิบัติได้หรือมีต้นทุนสูงได้อย่างไร?
• จะมั่นใจได้อย่างไรว่าทุกรายละเอียดเล็กๆ น้อยๆ ของสเปกสถาปัตยกรรมจะถูกสื่อสารไปยังผู้พัฒนา เข้าใจอย่างถูกต้อง และนำไปใช้ในผลิตภัณฑ์อย่างแม่นยำ?
Achieving Conceptual Integrity (การบรรลุความสมบูรณ์ทางแนวคิด)
จุดประสงค์ของระบบซอฟต์แวร์คือทำให้คอมพิวเตอร์ใช้งานง่าย เพื่อให้บรรลุสิ่งนี้ ระบบจึงจัดเตรียมภาษาและสิ่งอำนวยความสะดวกต่างๆ ที่จริงแล้วคือโปรแกรมที่ถูกเรียกใช้และควบคุมผ่านคุณสมบัติทางภาษา แต่สิ่งอำนวยความสะดวกเหล่านี้ต้องแลกมาด้วยราคา: คำอธิบายภายนอกของระบบซอฟต์แวร์มีขนาดใหญ่กว่าคำอธิบายภายนอกของระบบคอมพิวเตอร์ถึงสิบถึงยี่สิบเท่า ผู้ใช้พบว่าการระบุฟังก์ชันเฉพาะใดๆ นั้นง่ายกว่ามาก แต่ก็มีฟังก์ชันให้เลือกมากมายกว่า และมี option และรูปแบบให้จดจำมากขึ้น
ความง่ายในการใช้งานจะเพิ่มขึ้นก็ต่อเมื่อเวลาที่ประหยัดได้จากการระบุฟังก์ชันมากกว่าเวลาที่เสียไปในการเรียนรู้ จดจำ และค้นหาคู่มือเท่านั้น ด้วยระบบซอฟต์แวร์สมัยใหม่ ส่วนได้นี้มีมากกว่าต้นทุนจริง แต่ในช่วงไม่กี่ปีที่ผ่านมา อัตราส่วนของส่วนได้ต่อต้นทุนดูเหมือนจะลดลงเมื่อมีการเพิ่มฟังก์ชันที่ซับซ้อนมากขึ้นเรื่อยๆ ผมยังคงหลอนกับความทรงจำเกี่ยวกับความง่ายในการใช้งานของ IBM 650 แม้จะไม่มี assembler หรือซอฟต์แวร์อื่นใดเลยก็ตาม
เนื่องจากความง่ายในการใช้งานคือจุดประสงค์ อัตราส่วนระหว่างฟังก์ชันต่อความซับซ้อนทางแนวคิดนี้จึงเป็นมาตรวัดสูงสุดของการออกแบบระบบ ฟังก์ชันเพียงอย่างเดียวหรือความเรียบง่ายเพียงอย่างเดียวไม่ได้กำหนดการออกแบบที่ดี
ประเด็นนี้ถูกเข้าใจผิดอย่างกว้างขวาง Operating System/360 ได้รับการยกย่องจากผู้สร้างว่าดีที่สุดเท่าที่เคยสร้างมา เพราะมันมีฟังก์ชันมากที่สุดอย่างปฏิเสธไม่ได้ ฟังก์ชัน ไม่ใช่ความเรียบง่าย คือมาตรวัดความเป็นเลิศสำหรับนักออกแบบของมันเสมอมา ในทางกลับกัน Time-Sharing System สำหรับ PDP-10 ได้รับการยกย่องจากผู้สร้างว่าดียอดเยี่ยม เพราะความเรียบง่ายและความกระชับของแนวคิด แต่ไม่ว่าจะวัดด้วยมาตรฐานใด ฟังก์ชันของมันก็ไม่ได้อยู่ในระดับเดียวกับ OS/360 ด้วยซ้ำ ทันทีที่ความง่ายในการใช้งานถูกยกขึ้นเป็นเกณฑ์ ระบบแต่ละระบบก็จะถูกมองว่าไม่สมดุล โดยมุ่งไปเพียงครึ่งเดียวของเป้าหมายที่แท้จริง
สำหรับฟังก์ชันในระดับที่กำหนด อย่างไรก็ตาม ระบบที่ดีที่สุดคือระบบที่สามารถระบุสิ่งต่างๆ ได้ด้วยความเรียบง่ายและตรงไปตรงมาที่สุด ความเรียบง่าย อย่างเดียวนั้นไม่พอ ภาษา TRAC ของ Mooers และ Algol 68 บรรลุความเรียบง่ายเมื่อวัดจากจำนวนแนวคิดพื้นฐานที่แตกต่างกัน แต่อย่างไรก็ตาม พวกมันไม่ ตรงไปตรงมา การแสดงออกถึงสิ่งที่ต้องการทำมักต้องใช้การผสมผสานสิ่งอำนวยความสะดวกพื้นฐานที่ซับซ้อนและไม่คาดคิด การเรียนรู้แค่องค์ประกอบและกฎการรวมกันนั้นไม่พอ เรายังต้องเรียนรู้การใช้งานแบบสำนวน ซึ่งเป็นองค์ความรู้ทั้งหมดเกี่ยวกับวิธีการรวมองค์ประกอบต่างๆ ในทางปฏิบัติ ความเรียบง่ายและความตรงไปตรงมามาจากความสมบูรณ์ทางแนวคิด ทุกส่วนต้องสะท้อนปรัชญาเดียวกันและความสมดุลของสิ่งที่พึงประสงค์เดียวกัน ทุกส่วนต้องใช้เทคนิคเดียวกันใน syntax และแนวคิดที่คล้ายคลึงกันใน semantics ความง่ายในการใช้งานจึงกำหนดความเป็นหนึ่งเดียวกันของการออกแบบ นั่นคือความสมบูรณ์ทางแนวคิด
Aristocracy and Democracy (ชนชั้นนำและประชาธิปไตย)
ความสมบูรณ์ทางแนวคิดในทางกลับกันกำหนดว่าการออกแบบต้องมาจากจิตใจเดียว หรือจากกลุ่มคนจำนวนน้อยมากที่เห็นพ้องต้องกัน
อย่างไรก็ตาม แรงกดดันด้านตารางเวลากำหนดว่าการสร้างระบบต้องใช้คนจำนวนมาก มีสองเทคนิคที่ใช้แก้ปัญหาที่กลืนไม่เข้าคายไม่ออกนี้ได้ เทคนิคแรกคือการแบ่งงานอย่างระมัดระวังระหว่างสถาปัตยกรรมและการนำไปปฏิบัติ เทคนิคที่สองคือวิธีการใหม่ในการจัดโครงสร้างทีมพัฒนาซอฟต์แวร์ที่ได้กล่าวถึงในบทที่แล้ว
การแยกความพยายามทางสถาปัตยกรรมออกจากการนำไปปฏิบัติเป็นวิธีที่มีประสิทธิภาพมากในการบรรลุความสมบูรณ์ทางแนวคิดในโปรเจกต์ขนาดใหญ่ ผมเองเคยเห็นมันถูกใช้อย่างประสบความสำเร็จอย่างมากในคอมพิวเตอร์ Stretch ของ IBM และในกลุ่มผลิตภัณฑ์คอมพิวเตอร์ System/360 และผมเคยเห็นมันล้มเหลวจากการขาดการนำไปใช้ใน Operating System/360
โดย สถาปัตยกรรม ของระบบ ผมหมายถึงสเปกที่สมบูรณ์และละเอียดของส่วนติดต่อกับผู้ใช้ สำหรับคอมพิวเตอร์ นั่นคือคู่มือการเขียนโปรแกรม สำหรับ compiler นั่นคือคู่มือภาษา สำหรับโปรแกรมควบคุม นั่นคือคู่มือสำหรับภาษาที่ใช้เรียกใช้ฟังก์ชันต่างๆ ของมัน สำหรับทั้งระบบ นั่นคือการรวมกันของคู่มือทั้งหมดที่ผู้ใช้ต้องปรึกษาเพื่อทำงานทั้งหมดของเขา
สถาปนิกของระบบ เช่นเดียวกับสถาปนิกของอาคาร คือตัวแทนของผู้ใช้ หน้าที่ของเขาคือนำความรู้ทางวิชาชีพและเทคนิคมาใช้เพื่อผลประโยชน์สูงสุดของผู้ใช้ ตรงกันข้ามกับผลประโยชน์ของพนักงานขาย ผู้ผลิต ฯลฯ [2]
สถาปัตยกรรมต้องถูกแยกแยะอย่างระมัดระวังจากการนำไปปฏิบัติ ดังที่ Blaauw ได้กล่าวไว้ว่า "ในขณะที่สถาปัตยกรรมบอก ว่าอะไร เกิดขึ้น การนำไปปฏิบัติบอก ว่ามันเกิดขึ้นได้อย่างไร " [3] เขายกตัวอย่างง่ายๆ คือนาฬิกา ซึ่งสถาปัตยกรรมประกอบด้วยหน้าปัด เข็ม และปุ่มขึ้นลาน เมื่อเด็กเรียนรู้สถาปัตยกรรมนี้แล้ว เขาสามารถบอกเวลาได้ง่ายไม่ว่าจะเป็นนาฬิกาข้อมือหรือนาฬิกาหอคอยของโบสถ์ อย่างไรก็ตาม การนำไปปฏิบัติและวิธีการทำให้เป็นจริง บรรยายถึงสิ่งที่เกิดขึ้นภายในเรือน—การขับเคลื่อนด้วยกลไกต่างๆ มากมาย และการควบคุมความแม่นยำด้วยหลายวิธี
ใน System/360 เป็นต้น สถาปัตยกรรมคอมพิวเตอร์แบบเดียวกันถูกนำไปใช้ด้วยวิธีที่แตกต่างกันอย่างมากในแต่ละรุ่นจากทั้งหมดเก้ารุ่น ในทางกลับกัน การนำไปปฏิบัติแบบเดียวกัน นั่นคือ data flow, หน่วยความจำ, และ microcode ของ Model 30 ถูกใช้ในเวลาที่ต่างกันสำหรับสถาปัตยกรรมที่แตกต่างกันสี่แบบ: คอมพิวเตอร์ System/360, multiplex channel ที่มี subchannel ที่เป็นอิสระทางตรรกะมากถึง 224 ช่อง, selector channel, และคอมพิวเตอร์ 1401 [4]
ความแตกต่างเดียวกันนี้ใช้ได้กับระบบซอฟต์แวร์อย่างเท่าเทียมกัน มีมาตรฐาน Fortran IV ของสหรัฐอเมริกา นี่คือสถาปัตยกรรมสำหรับ compiler หลายตัว ภายใต้สถาปัตยกรรมนี้ การนำไปปฏิบัติหลายแบบเป็นไปได้: text-in-core หรือ compiler-in-core, fast-compile หรือ optimizing, syntax-directed หรือ ad-hoc ในทำนองเดียวกัน ภาษา assembler หรือ job-control ภาษาใดๆ ก็ย่อมมีการนำไปปฏิบัติของ assembler หรือ scheduler มากมาย
ตอนนี้เราสามารถจัดการกับคำถามที่สะเทือนอารมณ์อย่างลึกซึ้งเกี่ยวกับชนชั้นนำกับประชาธิปไตย สถาปนิกไม่ใช่ชนชั้นนำใหม่ เป็นกลุ่มผู้มีปัญญาชน ที่ถูกตั้งขึ้นมาบอกผู้พัฒนาที่ยากจนและโง่เขลาว่าต้องทำอะไรหรือ? งานสร้างสรรค์ทั้งหมดไม่ได้ถูกสงวนไว้สำหรับชนชั้นนำนี้ โดยทำให้ผู้พัฒนาเป็นแค่ฟันเฟืองในเครื่องจักรหรือ? เราจะไม่ได้ผลิตภัณฑ์ที่ดีกว่าด้วยการรับฟังความคิดดีๆ จากทั้งทีม ตามปรัชญาประชาธิปไตย แทนที่จะจำกัดการพัฒนาสเปกไว้เพียงไม่กี่คนหรือ?
สำหรับคำถามสุดท้าย มันง่ายที่สุด ผมจะไม่ยืนยันว่ามีเพียงสถาปนิกเท่านั้นที่จะมีแนวคิดทางสถาปัตยกรรมที่ดี บ่อยครั้งที่แนวคิดใหม่ๆ มาจากผู้พัฒนาหรือผู้ใช้ อย่างไรก็ตาม ประสบการณ์ทั้งหมดของผมทำให้เชื่อ และผมพยายามจะแสดงให้เห็นว่า ความสมบูรณ์ทางแนวคิดของระบบเป็นตัวกำหนดความง่ายในการใช้งาน ฟีเจอร์และแนวคิดดีๆ ที่ไม่สอดคล้องกับแนวคิดพื้นฐานของระบบ ควรถูกตัดทิ้งไปเสียดีกว่า หากมีแนวคิดสำคัญแต่เข้ากันไม่ได้มากมายเช่นนี้ ก็ให้ทิ้งระบบทั้งระบบและเริ่มต้นใหม่บนระบบที่มีแนวคิดพื้นฐานต่างออกไป
สำหรับข้อกล่าวหาเรื่องชนชั้นนำ คำตอบคือทั้งใช่และไม่ใช่ ใช่ ในแง่ที่ว่าต้องมีสถาปนิกจำนวนน้อย ผลงานของพวกเขาต้องคงอยู่ยาวนานกว่าของผู้พัฒนา และสถาปนิกนั่งอยู่ที่จุดศูนย์กลางของแรงต่างๆ ที่เขาต้องแก้ไขในท้ายที่สุดเพื่อประโยชน์ของผู้ใช้ หากระบบจะมีความสมบูรณ์ทางแนวคิด ใครสักคนต้องควบคุมแนวคิดเหล่านั้น นั่นคือชนชั้นนำที่ไม่จำเป็นต้องขออภัย
ไม่ใช่ เพราะการกำหนดสเปกภายนอกไม่ใช่งานที่สร้างสรรค์มากกว่าการออกแบบการนำไปปฏิบัติ มันเป็นเพียงงานสร้างสรรค์คนละประเภทกัน การออกแบบการนำไปปฏิบัติ ภายใต้สถาปัตยกรรมที่กำหนด ต้องการและเปิดโอกาสให้มีความคิดสร้างสรรค์ในการออกแบบ มีแนวคิดใหม่ๆ และมีความสามารถทางเทคนิคมากพอๆ กับการออกแบบสเปกภายนอก อันที่จริง อัตราส่วนต้นทุนต่อประสิทธิภาพของผลิตภัณฑ์จะขึ้นอยู่กับผู้พัฒนามากที่สุด เช่นเดียวกับที่ความง่ายในการใช้งานขึ้นอยู่กับสถาปนิกมากที่สุด
มีตัวอย่างมากมายจากศิลปะและงานฝีมืออื่นๆ ที่ทำให้เราเชื่อว่าวินัยเป็นสิ่งดีสำหรับศิลปะ อันที่จริง มีคำกล่าวของศิลปินว่า "รูปแบบคือการปลดปล่อย" อาคารที่แย่ที่สุดคืออาคารที่มีงบประมาณมากเกินไปสำหรับวัตถุประสงค์ที่จะใช้ ผลงานสร้างสรรค์ของ Bach แทบจะไม่ถูกขัดขวางโดยความจำเป็นในการผลิต cantata รูปแบบจำกัดทุกสัปดาห์ ผมมั่นใจว่าคอมพิวเตอร์ Stretch จะมีสถาปัตยกรรมที่ดีกว่านี้หากมันถูกจำกัดมากขึ้น ข้อจำกัดที่เกิดจากงบประมาณของ System/360 Model 30 ในความเห็นของผมนั้นเป็นประโยชน์อย่างสิ้นเชิงสำหรับสถาปัตยกรรมของ Model 75
ในทำนองเดียวกัน ผมสังเกตว่าการกำหนดสถาปัตยกรรมจากภายนอกช่วยเสริม ไม่ใช่ขัดขวาง รูปแบบสร้างสรรค์ของทีมพัฒนา พวกเขามุ่งความสนใจไปที่ส่วนของปัญหาที่ไม่มีใครเคยจัดการทันที และสิ่งประดิษฐ์ต่างๆ ก็เริ่มหลั่งไหล ในทีมพัฒนาที่ไม่มีข้อจำกัด ความคิดและการถกเถียงส่วนใหญ่จะไปอยู่ที่การตัดสินใจทางสถาปัตยกรรม และการนำไปปฏิบัติที่แท้จริงจะถูกละเลย [5]
ผลกระทบนี้ ซึ่งผมเห็นมาหลายครั้ง ได้รับการยืนยันโดย R. W. Conway ซึ่งกลุ่มของเขาที่ Cornell สร้าง compiler PL/C สำหรับภาษา PL/I เขากล่าวว่า "ในที่สุดเราก็ตัดสินใจที่จะนำภาษาไปใช้ตามเดิมโดยไม่เปลี่ยนแปลงหรือปรับปรุง เพราะการถกเถียงเกี่ยวกับภาษาจะใช้ความพยายามทั้งหมดของเรา" [6]
What Does the Implementer Do While Waiting? (ผู้พัฒนาทำอะไรระหว่างรอ?)
มันเป็นประสบการณ์ที่ถ่อมตนมากที่ได้ทำผิดพลาดมูลค่าหลายล้านดอลลาร์ แต่มันก็น่าจดจำมากเช่นกัน ผมจำคืนที่เราตัดสินใจว่าจะจัดระเบียบการเขียนสเปกภายนอกสำหรับ OS/360 อย่างไรได้อย่างชัดเจน ผู้จัดการฝ่ายสถาปัตยกรรม ผู้จัดการฝ่ายพัฒนาโปรแกรมควบคุม และผม กำลังขบคิดแผน ตารางเวลา และการแบ่งหน้าที่รับผิดชอบ
ผู้จัดการฝ่ายสถาปัตยกรรมมีคนเก่ง 10 คน เขายืนยันว่าพวกเขาสามารถเขียนสเปกและทำให้ถูกต้องได้ มันจะใช้เวลาสิบเดือน ซึ่งมากกว่าตารางเวลาที่กำหนดไว้สามเดือน
ผู้จัดการโปรแกรมควบคุมมีคน 150 คน เขายืนยันว่าพวกเขาสามารถเตรียมสเปกได้ โดยมีทีมสถาปัตยกรรมคอยประสานงาน มันจะออกมาดีและใช้งานได้จริง และเขาทำได้ตามตารางเวลา ยิ่งกว่านั้น ถ้าทีมสถาปัตยกรรมทำมัน คน 150 คนของเขาจะนั่งเล่นอยู่นิ่งๆ เป็นเวลาสิบเดือน
ผู้จัดการฝ่ายสถาปัตยกรรมตอบว่าถ้าผมให้ความรับผิดชอบกับทีมโปรแกรมควบคุม ผลลัพธ์จะ ไม่ ตรงตามกำหนดเวลา แต่จะช้ากว่าสามเดือนเช่นกัน และมีคุณภาพต่ำกว่ามาก ผมทำตามนั้น และมันก็เป็นอย่างนั้น เขาพูดถูกทั้งสองข้อ ยิ่งกว่านั้น การขาดความสมบูรณ์ทางแนวคิดทำให้ระบบมีต้นทุนสูงขึ้นมากในการสร้างและปรับเปลี่ยน และผมประมาณว่ามันเพิ่มเวลาในการ debug ขึ้นอีกหนึ่งปี
แน่นอนว่ามีหลายปัจจัยที่นำไปสู่การตัดสินใจที่ผิดพลาดนั้น แต่ปัจจัยที่压倒性的คือตารางเวลาและการดึงดูดใจในการนำคน 150 คนนั้นมาทำงาน มันคือเสียงไซเรนที่ผมอยากจะทำให้เห็นถึงอันตรายร้ายแรงของมันในตอนนี้
เมื่อมีการเสนอว่าทีมสถาปัตยกรรมขนาดเล็กควรเขียนสเปกภายนอกทั้งหมดสำหรับคอมพิวเตอร์หรือระบบซอฟต์แวร์ ผู้พัฒนาจะยกข้อโต้แย้งสามประการ:
• สเปกจะอุดมไปด้วยฟังก์ชันมากเกินไปและไม่สะท้อนข้อพิจารณาด้านต้นทุนในทางปฏิบัติ
• สถาปนิกจะได้รับความสนุกในการสร้างสรรค์ทั้งหมดและกีดกันความคิดสร้างสรรค์ของผู้พัฒนา
• ผู้พัฒนาจำนวนมากจะต้องนั่งว่างงานในขณะที่สเปกถูกส่งผ่าน funnel แคบๆ ที่เป็นทีมสถาปัตยกรรม
ข้อแรกเป็นอันตรายจริง และจะถูกกล่าวถึงในบทถัดไป อีกสองข้อเป็นภาพล้วนๆ ดังที่เราได้เห็นข้างต้น การนำไปปฏิบัติก็เป็นกิจกรรมสร้างสรรค์ระดับสูงเช่นกัน โอกาสในการสร้างสรรค์และประดิษฐ์คิดค้นในการนำไปปฏิบัตินั้นไม่ได้ลดลงอย่างมีนัยสำคัญจากการทำงานภายใต้สเปกภายนอกที่กำหนด และลำดับของความคิดสร้างสรรค์อาจเพิ่มขึ้นด้วยซ้ำจากวินัยนั้น ผลิตภัณฑ์โดยรวมจะต้องดีขึ้นแน่นอน
ข้อโต้แย้งสุดท้ายเป็นเรื่องของจังหวะเวลาและการจัดระยะ คำตอบสั้นๆ คืองดจ้างผู้พัฒนาจนกว่าสเปกจะเสร็จสมบูรณ์ นี่คือสิ่งที่ทำเมื่อมีการก่อสร้างอาคาร
อย่างไรก็ตาม ในธุรกิจระบบคอมพิวเตอร์ จังหวะนั้นเร็วกว่า และเราต้องการบีบอัดตารางเวลาให้มากที่สุดเท่าที่จะทำได้ สเปกและการสร้างสามารถทับซ้อนกันได้มากแค่ไหน?
ดังที่ Blaauw ชี้ให้เห็น ความพยายามสร้างสรรค์ทั้งหมดเกี่ยวข้องกับสามขั้นตอนที่แตกต่างกัน: สถาปัตยกรรม การนำไปปฏิบัติ และการทำให้เป็นจริง ปรากฏว่าสิ่งเหล่านี้สามารถเริ่มต้นแบบขนานและดำเนินการไปพร้อมกันได้
ในการออกแบบคอมพิวเตอร์ เป็นต้น ผู้พัฒนาสามารถเริ่มได้ทันทีที่เขามีสมมติฐานที่ค่อนข้างคลุมเครือเกี่ยวกับคู่มือ มีความคิดที่ชัดเจนขึ้นเล็กน้อยเกี่ยวกับเทคโนโลยี และมีวัตถุประสงค์ด้านต้นทุนและประสิทธิภาพที่ชัดเจน เขาสามารถเริ่มออกแบบ data flow, ลำดับการควบคุม, แนวคิดการบรรจุภัณฑ์โดยรวม และอื่นๆ เขาสร้างหรือปรับใช้เครื่องมือที่เขาจะต้องใช้ โดยเฉพาะระบบการเก็บบันทึก รวมถึงระบบ design automation
ในขณะเดียวกัน ในระดับการทำให้เป็นจริง วงจร การ์ด สายเคเบิล โครง แหล่งจ่ายไฟ และหน่วยความจำ ต่างต้องได้รับการออกแบบ ปรับแต่ง และจัดทำเอกสาร งานนี้ดำเนินการควบคู่ไปกับสถาปัตยกรรมและการนำไปปฏิบัติ
สิ่งเดียวกันนี้เป็นจริงในการออกแบบระบบซอฟต์แวร์ ก่อนที่สเปกภายนอกจะเสร็จสมบูรณ์เสียอีก ผู้พัฒนาก็มีอะไรให้ทำมากมายแล้ว เมื่อมีความประมาณการคร่าวๆ เกี่ยวกับฟังก์ชันของระบบที่จะถูกรวบรวมไว้ในสเปกภายนอกในที่สุด เขาก็สามารถดำเนินการได้ เขาต้องมีวัตถุประสงค์ด้านพื้นที่และเวลาที่ชัดเจน เขาต้องรู้การกำหนดค่าระบบที่ผลิตภัณฑ์ของเขาจะต้องทำงานบนนั้น จากนั้นเขาก็สามารถเริ่มออกแบบขอบเขตของ module, โครงสร้างของ table, การแบ่ง pass หรือ phase, algorithm, และเครื่องมือทุกประเภท นอกจากนี้ ยังต้องใช้เวลาในการสื่อสารกับสถาปนิกด้วย
ในขณะเดียวกัน ในระดับการทำให้เป็นจริงก็มีอะไรให้ทำมากมายเช่นกัน การเขียนโปรแกรมก็มีเทคโนโลยีของมันเช่นกัน หากเครื่องเป็นเครื่องใหม่ จะต้องทำงานมากมายเกี่ยวกับ subroutine convention, เทคนิคการควบคุม, algorithm การค้นหาและการเรียงลำดับ [7]
ความสมบูรณ์ทางแนวคิดต้องการให้ระบบสะท้อนปรัชญาเดียว และให้สเปกที่ผู้ใช้เห็นนั้นมาจากความคิดจำนวนน้อย อย่างไรก็ตาม เนื่องจากการแบ่งงานจริงออกเป็นสถาปัตยกรรม การนำไปปฏิบัติ และการทำให้เป็นจริง นี่จึงไม่ได้หมายความว่าระบบที่ออกแบบเช่นนี้จะใช้เวลาสร้างนานกว่า ประสบการณ์แสดงให้เห็นตรงกันข้าม กล่าวคือระบบที่มีความสมบูรณ์นั้นประกอบกันได้เร็วกว่าและใช้เวลาทดสอบน้อยกว่า โดยสรุปแล้ว การแบ่งงานในแนวนอนที่แพร่หลายได้ถูกลดทอนลงอย่างมากด้วยการแบ่งงานในแนวตั้ง และผลลัพธ์ที่ได้คือการสื่อสารที่เรียบง่ายขึ้นอย่างสิ้นเชิงและความสมบูรณ์ทางแนวคิดที่ดีขึ้น