ต่อเติมทีละเล็กละน้อย ก็จะกลายเป็นกองใหญ่ในที่สุด
[ Add little to little and there will be a big pile. ]
— OVID
ถ้าเราแยกความรับผิดชอบระหว่างการกำหนดสเปกฟังก์ชันออกจากการสร้างผลิตภัณฑ์ที่รวดเร็วและต้นทุนต่ำ แล้วอะไรล่ะที่จะคอยควบคุมความกระตือรือร้นในการสร้างสรรค์ของสถาปนิก?
คำตอบพื้นฐานคือการสื่อสารที่ละเอียดถี่ถ้วน ระมัดระวัง และเห็นอกเห็นใจกันระหว่างสถาปนิกและผู้สร้าง ถึงกระนั้นก็ยังมีคำตอบในรายละเอียดอีกมากที่ควรค่าแก่การพิจารณา
Interactive Discipline for the Architect (วินัยเชิงโต้ตอบสำหรับสถาปนิก)
สถาปนิกอาคารทำงานภายใต้งบประมาณ โดยใช้เทคนิคการประมาณราคาที่ต่อมาได้รับการยืนยันหรือแก้ไขโดยการประมูลของผู้รับเหมา บ่อยครั้งที่การประมูลทั้งหมดสูงเกินงบประมาณ สถาปนิกจึงปรับเทคนิคการประมาณราคาให้สูงขึ้นและปรับแบบให้เล็กลงเพื่อทำรอบใหม่ บางครั้งสถาปนิกอาจแนะนำวิธีให้ผู้รับเหมาสร้างแบบของเขาได้ถูกกว่าที่ผู้รับเหมาคิดไว้เอง
กระบวนการที่คล้ายคลึงกันนี้ควบคุมการทำงานของสถาปนิกระบบคอมพิวเตอร์หรือระบบซอฟต์แวร์ อย่างไรก็ตาม เขามีข้อได้เปรียบคือสามารถขอราคาประมาณจากผู้รับเหมาได้ตั้งแต่ช่วงต้นของการออกแบบ แทบจะทุกครั้งที่ต้องการ เขามักจะมีข้อเสียคือทำงานกับผู้รับเหมาเพียงรายเดียว ซึ่งสามารถปรับประมาณการขึ้นลงเพื่อสะท้อนความพอใจของตนที่มีต่อแบบได้ ในทางปฏิบัติ การสื่อสารตั้งแต่เนิ่นๆ และต่อเนื่องสามารถให้ข้อมูลต้นทุนที่ดีแก่สถาปนิก และสร้างความมั่นใจให้ผู้รับเหมาในแบบ โดยไม่ทำให้การแบ่งหน้าที่ความรับผิดชอบที่ชัดเจนพร่าเลือน
สถาปนิกมีสองทางเลือกเมื่อเจอกับประมาณการที่สูงเกินไป คือตัดทอนแบบ หรือท้าทายประมาณการด้วยการเสนอวิธีการ implement ที่ถูกกว่า อย่างหลังเป็นกิจกรรมที่ก่อให้เกิดอารมณ์ความรู้สึกอย่างหลีกเลี่ยงไม่ได้ สถาปนิกกำลังท้าทายวิธีทำงานของผู้รับเหมาในงานที่ผู้รับเหมารับผิดชอบอยู่ เพื่อให้สำเร็จ สถาปนิกต้อง
• จำไว้ว่าผู้รับเหมามีความรับผิดชอบทั้งในเชิงสร้างสรรค์และในเชิงปฏิบัติในการ implement ดังนั้นสถาปนิกควรเสนอแนะ ไม่ใช่สั่งการ
• เตรียมพร้อมที่จะเสนอ แนวทาง ในการ implement ทุกอย่างที่เขากำหนดสเปกไว้ และพร้อมที่จะยอมรับแนวทางอื่นใดที่บรรลุวัตถุประสงค์ได้เช่นกัน
• ดำเนินการเสนอแนะเหล่านี้อย่างเงียบๆ และเป็นส่วนตัว
• พร้อมที่จะสละเครดิตสำหรับการปรับปรุงที่เสนอไป
โดยปกติแล้วผู้สร้างจะโต้ตอบด้วยการเสนอแนะให้เปลี่ยนสถาปัตยกรรม บ่อยครั้งที่เขาพูดถูก—ฟีเจอร์เล็กๆ บางอย่างอาจมีต้นทุนที่สูงอย่างไม่คาดคิดเมื่อลงมือ implement จริง
Self-Discipline—The Second-System Effect (วินัยในตนเอง—Second-System Effect)
ผลงานแรกของสถาปนิกมักจะเรียบง่ายและสะอาดตา เขารู้ว่าเขาไม่รู้ว่ากำลังทำอะไรอยู่ ดังนั้นเขาจึงทำมันอย่างระมัดระวังและด้วยความยับยั้งชั่งใจอย่างมาก
ขณะที่เขาออกแบบงานแรก ลูกเล่นแล้วลูกเล่นเล่า และการปรุงแต่งแล้วปรุงแต่งเล่าก็ผุดขึ้นในความคิด สิ่งเหล่านี้ถูกเก็บไว้ใช้ "คราวหน้า" ไม่ช้าก็เร็วระบบแรกก็เสร็จ และสถาปนิกที่มีความมั่นใจและการแสดงความเชี่ยวชาญในระบบประเภทนั้น ก็พร้อมที่จะสร้างระบบที่สอง
ระบบที่สองนี้เป็นระบบที่อันตรายที่สุดที่คนเราจะออกแบบได้ เมื่อเขาทำระบบที่สามและต่อๆ ไป ประสบการณ์ก่อนหน้านี้จะยืนยันซึ่งกันและกันถึงลักษณะทั่วไปของระบบดังกล่าว และความแตกต่างจะชี้ให้เห็นว่าส่วนไหนของประสบการณ์ที่เป็นเรื่องเฉพาะและไม่สามารถนำไป generalize ได้
แนวโน้มทั่วไปคือการออกแบบระบบที่สองมากเกินไป โดยใช้ไอเดียและลูกเล่นทั้งหมดที่ถูกกันไว้อย่างระมัดระวังในระบบแรก ผลลัพธ์ดังที่ Ovid กล่าวคือ "กองใหญ่" ตัวอย่างเช่น พิจารณาสถาปัตยกรรม IBM 709 ซึ่งต่อมาถูกบรรจุใน 7090 นี่คือการอัปเกรด ซึ่งเป็นระบบที่สองของ 704 ที่ประสบความสำเร็จและสะอาดมาก ชุดคำสั่งสมบูรณ์และมากมายจนมีเพียงประมาณครึ่งเดียวเท่านั้นที่ถูกใช้งานเป็นประจำ
พิจารณากรณีที่ชัดเจนกว่าคือสถาปัตยกรรม การ implement และแม้กระทั่งการ realization ของคอมพิวเตอร์ Stretch ซึ่งเป็นทางออกของความต้องการสร้างสรรค์ที่ถูกอัดอั้นของคนจำนวนมาก และเป็นระบบที่สองสำหรับพวกเขาส่วนใหญ่ ดังที่ Strachey กล่าวในบทวิจารณ์:
ผมรู้สึกว่า Stretch นั้นเป็นจุดสิ้นสุดของสายการพัฒนาสายหนึ่งในบางแง่ เช่นเดียวกับโปรแกรมคอมพิวเตอร์ยุคแรกๆ บางตัว มันช่างชาญฉลาดเหลือเชื่อ ซับซ้อนเหลือเชื่อ และมีประสิทธิภาพอย่างยิ่ง แต่ในขณะเดียวกันก็ดูหยาบ สิ้นเปลือง และไม่สง่างาม และเรารู้สึกว่ามันน่าจะมีวิธีที่ดีกว่าในการทำสิ่งต่างๆ [1]
ระบบปฏิบัติการ OS/360 เป็นระบบที่สองของนักออกแบบส่วนใหญ่ นักออกแบบของมันมาจากการสร้างระบบปฏิบัติการดิสก์ 1410-7010, ระบบปฏิบัติการ Stretch, ระบบ real-time ของ Project Mercury, และ IBSYS สำหรับ 7090 แทบจะไม่มีใครเลยที่มีประสบการณ์กับ สอง ระบบปฏิบัติการก่อนหน้านี้ [2] ดังนั้น OS/360 จึงเป็นตัวอย่างสำคัญของ second-system effect ซึ่งเป็น Stretch แห่งวงการซอฟต์แวร์ที่ทั้งคำชมและคำตำหนิในคำวิจารณ์ของ Strachey ต่างก็ใช้ได้โดยไม่ต้องเปลี่ยนแปลง
ตัวอย่างเช่น OS/360 ใช้ 26 ไบต์ของรูทีนวันที่เปลี่ยนปี (date-turnover routine) ที่อยู่ในหน่วยความจำถาวรเพื่อจัดการกับวันที่ 31 ธันวาคมในปีอธิกสุรทินอย่างถูกต้อง (เมื่อเป็นวันที่ 366) ซึ่งน่าจะปล่อยให้เป็นหน้าที่ของผู้ปฏิบัติการก็ได้
Second-system effect มีอีกอาการหนึ่งที่แตกต่างไปจากการเพิ่มฟังก์ชันล้วนๆ นั่นคือแนวโน้มที่จะปรับแต่งเทคนิคที่การดำรงอยู่ของมันล้าสมัยไปแล้วเนื่องจากการเปลี่ยนแปลงของสมมติฐานพื้นฐานของระบบ OS/360 มีตัวอย่างมากมายของเรื่องนี้
พิจารณา linkage editor ซึ่งออกแบบมาเพื่อโหลดโปรแกรมที่ถูก compile แยกกันและแก้ไข cross-reference ของมัน นอกเหนือจากฟังก์ชันพื้นฐานนี้แล้ว มันยังจัดการ program overlay ด้วย มันเป็นหนึ่งในระบบ overlay ที่ยอดเยี่ยมที่สุดเท่าที่เคยสร้างมา มันอนุญาตให้จัดโครงสร้าง overlay ได้จากภายนอก ในขั้นตอนการ link โดยไม่ต้องออกแบบลงใน source code มันอนุญาตให้เปลี่ยนโครงสร้าง overlay ได้ในแต่ละรอบการ run โดยไม่ต้อง recompile มันมี option และสิ่งอำนวยความสะดวกที่มีประโยชน์มากมาย ในแง่หนึ่ง มันคือจุดสูงสุดของพัฒนาการหลายปีของเทคนิค static overlay
ถึงกระนั้น มันก็เป็นไดโนเสาร์ตัวสุดท้ายและดีที่สุดเช่นกัน เพราะมันเป็นส่วนหนึ่งของระบบที่การทำ multiprogramming เป็นโหมดปกติและการจัดสรรหน่วยความจำแบบ dynamic เป็นสมมติฐานพื้นฐาน ซึ่งขัดแย้งโดยตรงกับแนวคิดการใช้ static overlay ระบบจะทำงานได้ดีขึ้นสักเท่าใดหากความพยายามที่ทุ่มเทให้กับการจัดการ overlay ถูกนำไปใช้ในการทำให้การจัดสรรหน่วยความจำแบบ dynamic และสิ่งอำนวยความสะดวกในการ cross-referencing แบบ dynamic ทำงานได้รวดเร็วจริงๆ!
ยิ่งไปกว่านั้น linkage editor ต้องการพื้นที่มากและตัวมันเองก็มี overlay มากมายจนแม้เมื่อใช้แค่การ link โดยไม่มีการจัดการ overlay มันก็ยังช้ากว่า compiler ส่วนใหญ่ของระบบ ความประชดประชันของเรื่องนี้คือจุดประสงค์ของ linker คือเพื่อหลีกเลี่ยงการ recompilation เหมือนนักสเกตที่ท้องไส้เคลื่อนไปข้างหน้าจนเกินเท้า การปรับแต่งดำเนินไปจนกระทั่งสมมติฐานของระบบถูกทิ้งไว้ข้างหลังอย่างสิ้นเชิง
สิ่งอำนวยความสะดวกในการ debug อย่าง TESTRAN ก็เป็นอีกตัวอย่างหนึ่งของแนวโน้มนี้ มันเป็นจุดสูงสุดของสิ่งอำนวยความสะดวกในการ debug แบบ batch ที่มีความสามารถในการ snapshot และ core dump ที่งดงามอย่างแท้จริง มันใช้แนวคิด control section และเทคนิค generator ที่ชาญฉลาดเพื่อให้สามารถเลือก tracing และ snapshotting ได้โดยไม่มี interpreter overhead หรือต้อง recompile แนวคิดสร้างสรรค์ของ Share Operating System [3] สำหรับ 709 ได้ถูกพัฒนาให้เบ่งบานอย่างเต็มที่
ในขณะเดียวกัน แนวคิดทั้งหมดเกี่ยวกับการ debug แบบ batch โดยไม่ต้อง recompile กำลังกลายเป็นสิ่งที่ล้าสมัย ระบบ computing แบบโต้ตอบที่ใช้ language interpreter หรือ incremental compiler ได้สร้างความท้าทายพื้นฐานที่สุด แต่ถึงแม้ในระบบ batch การเกิดขึ้นของ compiler แบบ fast-compile/slow-execute ก็ทำให้การ debug และ snapshot ในระดับ source code กลายเป็นเทคนิคที่ถูกเลือกใช้มากกว่า ระบบจะดีขึ้นสักเท่าใดหากความพยายามของ TESTRAN ถูกทุ่มเทให้กับการสร้างสิ่งอำนวยความสะดวกแบบโต้ตอบและแบบ fast-compile ให้เร็วขึ้นและดีขึ้นแทน!
อีกตัวอย่างหนึ่งคือ scheduler ซึ่งมีสิ่งอำนวยความสะดวกที่ยอดเยี่ยมอย่างแท้จริงสำหรับการจัดการ batch job stream แบบตายตัว ในแง่หนึ่ง scheduler นี้คือระบบที่สองที่ได้รับการปรับปรุง ต่อยอด และตกแต่งของ 1410-7010 Disk Operating System ซึ่งเป็นระบบ batch ที่ไม่มี multiprogramming ยกเว้น input-output และมีไว้สำหรับงานธุรกิจเป็นหลัก ด้วยเหตุนี้ scheduler ของ OS/360 จึงดี แต่แทบจะไม่ได้รับอิทธิพลจากความต้องการของ OS/360 ในด้าน remote job entry, multiprogramming, และ subsystem แบบโต้ตอบที่อยู่ถาวรในหน่วยความจำเลย ที่จริงแล้วการออกแบบของ scheduler ทำให้สิ่งเหล่านี้กลายเป็นเรื่องยาก
แล้วสถาปนิกจะหลีกเลี่ยง second-system effect ได้อย่างไร? แน่นอนว่าเขาไม่สามารถข้ามระบบที่สองของเขาไปได้ แต่เขาสามารถตระหนักถึงอันตรายเฉพาะของระบบนั้น และใช้ความมีวินัยในตนเองเป็นพิเศษเพื่อหลีกเลี่ยงการตกแต่งฟังก์ชันที่ไม่จำเป็น และหลีกเลี่ยงการขยายฟังก์ชันที่กลายเป็นสิ่งไร้ประโยชน์เนื่องจากการเปลี่ยนแปลงของสมมติฐานและวัตถุประสงค์
วินัยหนึ่งที่จะเปิดตาของสถาปนิกคือการกำหนดค่าให้กับฟังก์ชันเล็กๆ แต่ละฟังก์ชัน: ความสามารถ x มีค่าไม่เกิน m ไบต์ของหน่วยความจำและ n ไมโครวินาทีต่อการเรียกใช้หนึ่งครั้ง ค่าเหล่านี้จะช่วยชี้นำการตัดสินใจในช่วงแรก และใช้เป็นแนวทางและคำเตือนแก่ทุกคนระหว่างการ implement
แล้วผู้จัดการโปรเจกต์จะหลีกเลี่ยง second-system effect ได้อย่างไร? โดยการยืนกรานให้มีสถาปนิกอาวุโสที่เคยผ่านระบบอย่างน้อยสองระบบมาก่อน รวมถึงการตระหนักถึงสิ่งล่อใจพิเศษเหล่านี้ ก็จะทำให้เขาสามารถตั้งคำถามที่ถูกต้องเพื่อให้แน่ใจว่าแนวคิดเชิงปรัชญาและวัตถุประสงค์ต่างๆ ได้สะท้อนออกมาอย่างเต็มที่ในรายละเอียดการออกแบบ