The Second-System Effect

Adde parvum parvo magnus acervus erit. [จงเพิ่มทีละน้อยเข้ากับทีละน้อย แล้วมันจะกลายเป็นกองใหญ่] — โอวิด (OVID)

ภาพพิมพ์หินสถานีสับเปลี่ยนเส้นทางสำหรับการจราจรทางอากาศ, ปารีส, 1882 จากหนังสือ Le Vingtième Siècle โดย A. Robida

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

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

Interactive Discipline for the Architect

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

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

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

Self-Discipline—The Second-System Effect

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

แนวโน้มทั่วไปคือการออกแบบระบบที่สองให้ "มากเกินไป" (over-design) โดยนำไอเดียและสิ่งประดับประดาทั้งหมดที่เคยถูกกันออกไปอย่างระมัดระวังในระบบแรกมาใช้ ผลลัพธ์ที่ได้ก็คือ "กองขยะกองใหญ่" ดังที่โอวิดกล่าวไว้ ตัวอย่างเช่น ลองพิจารณาสถาปัตยกรรม IBM 709 ซึ่งต่อมาถูกนำมาใช้ใน 7090 นี่คือการอัปเกรด เป็นระบบที่สองสำหรับ 704 ที่ประสบความสำเร็จและสะอาดตามาก ชุดคำสั่งในการทำงานนั้นมีมากมายและฟุ่มเฟือยเสียจนมีเพียงประมาณครึ่งหนึ่งเท่านั้นที่ถูกเรียกใช้งานเป็นประจำ ลองพิจารณากรณีที่ชัดเจนกว่านั้น เช่น สถาปัตยกรรม การนำไปใช้งาน และแม้แต่การทำให้เป็นจริงของคอมพิวเตอร์ Stretch ซึ่งเป็นทางระบายความปรารถนาในการสร้างสรรค์ที่อัดอั้นมานานของคนจำนวนมาก และเป็นระบบที่สองสำหรับคนส่วนใหญ่ในนั้น ดังที่ Strachey กล่าวไว้ในบทวิจารณ์:

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

Operating System/360 เป็นระบบที่สองสำหรับผู้ออกแบบส่วนใหญ่ กลุ่มผู้ออกแบบมาจากทีมที่สร้างระบบปฏิบัติการดิสก์ 1410-7010, ระบบปฏิบัติการ Stretch, ระบบเรียลไทม์ Project Mercury และ IBSYS สำหรับ 7090 แทบไม่มีใครเลยที่มีประสบการณ์กับระบบปฏิบัติการสองระบบก่อนหน้านี้ ดังนั้น OS/360 จึงเป็นตัวอย่างที่สำคัญของผลกระทบจากระบบที่สอง เปรียบเสมือน Stretch ของงานศิลปะด้านซอฟต์แวร์ ซึ่งทั้งคำชมและคำตำหนิจากการวิจารณ์ของ Strachey สามารถนำมาใช้ได้โดยไม่มีการเปลี่ยนแปลง

ตัวอย่างเช่น OS/360 ใช้พื้นที่ 26 ไบต์ในรูทีนเปลี่ยนวันที่ซึ่งฝังตัวอยู่ถาวร (permanently resident date-turnover routine) เพื่อจัดการวันที่ 31 ธันวาคมในปีอธิกสุรทิน (ซึ่งเป็นวันที่ 366) ให้ถูกต้อง ซึ่งเรื่องนี้อาจปล่อยให้เป็นหน้าที่ของผู้ดูแลเครื่อง (operator) ก็ได้

ผลกระทบจากระบบที่สองยังมีอีกลักษณะหนึ่งที่แตกต่างจากการประดับประดาหน้าที่การทำงานเพียงอย่างเดียว นั่นคือแนวโน้มที่จะปรับปรุงเทคนิคที่การมีอยู่ของมันกลายเป็นเรื่องล้าสมัยไปแล้วเนื่องจากการเปลี่ยนแปลงในสมมติฐานพื้นฐานของระบบ OS/360 มีตัวอย่างมากมายในเรื่องนี้ ลองพิจารณาตัวแก้ไขการเชื่อมโยง (linkage editor) ที่ออกแบบมาเพื่อโหลดโปรแกรมที่คอมไพล์แยกกันและจัดการการอ้างอิงข้ามกัน นอกเหนือจากหน้าที่พื้นฐานนี้แล้ว มันยังจัดการการวางซ้อนโปรแกรม (program overlays) ได้อีกด้วย มันเป็นหนึ่งในเครื่องมือจัดการ overlay ที่ยอดเยี่ยมที่สุดเท่าที่เคยสร้างมา มันช่วยให้การจัดโครงสร้าง overlay สามารถทำได้จากภายนอกในขณะที่ทำการเชื่อมโยง โดยไม่ต้องออกแบบไว้ในซอร์สโค้ด (source code) มันช่วยให้โครงสร้าง overlay สามารถเปลี่ยนแปลงได้ในแต่ละการรันโดยไม่ต้องคอมไพล์ใหม่ มันมีตัวเลือกและสิ่งอำนวยความสะดวกที่มีประโยชน์มากมาย ในแง่หนึ่งมันคือจุดสูงสุดของการพัฒนาเทคนิค static overlay มานานหลายปี

ทว่ามันก็เป็นไดโนเสาร์ตัวสุดท้ายและงดงามที่สุด เพราะมันอยู่ในระบบที่การทำงานหลายโปรแกรมพร้อมกัน (multiprogramming) เป็นโหมดปกติ และการจัดสรรหน่วยความจำแบบไดนามิก (dynamic core allocation) เป็นสมมติฐานพื้นฐาน สิ่งนี้ขัดแย้งโดยตรงกับแนวคิดของการใช้ static overlays ระบบจะทำงานได้ดีขึ้นเพียงใดหากความพยายามที่ทุ่มเทให้กับการจัดการ overlay ถูกนำไปใช้เพื่อทำให้การจัดสรรหน่วยความจำแบบไดนามิกและการอ้างอิงข้ามแบบไดนามิกนั้นรวดเร็วขึ้นจริงๆ! ยิ่งไปกว่านั้น ตัวแก้ไขการเชื่อมโยงยังใช้พื้นที่มากและตัวมันเองก็มีการวางซ้อนกันหลายชั้น จนแม้จะใช้เพียงเพื่อการเชื่อมโยงโดยไม่มีการจัดการ overlay มันก็ยังช้ากว่าคอมไพเลอร์ส่วนใหญ่ในระบบ ความน่าเศร้าของเรื่องนี้คือจุดประสงค์ของตัวเชื่อมโยง (linker) คือเพื่อหลีกเลี่ยงการคอมไพล์ใหม่ เหมือนกับนักสเก็ตที่ท้องพุ่งไปข้างหน้าเร็วกว่าเท้า การปรับปรุงดำเนินไปจนกระทั่งมันวิ่งแซงสมมติฐานของระบบไปไกลแล้ว เครื่องมือแก้ไขข้อผิดพลาด TESTRAN เป็นอีกตัวอย่างหนึ่งของแนวโน้มนี้ มันคือจุดสูงสุดของเครื่องมือแก้ไขข้อผิดพลาดแบบแบตช์ (batch debugging) โดยให้ความสามารถในการทำ snapshot และ core dump ที่สง่างามอย่างแท้จริง มันใช้แนวคิดของส่วนควบคุม (control section) และ...

ใช้เทคนิคการสร้างที่ชาญฉลาดเพื่อให้สามารถทำ selective tracing และ snapshotting ได้โดยไม่ต้องมีภาระเพิ่มจากการแปลคำสั่ง (interpretive overhead) หรือการคอมไพล์ใหม่ แนวคิดที่ล้ำสมัยของ Share Operating System สำหรับเครื่อง 709 ได้ถูกพัฒนาจนเบ่งบานอย่างเต็มที่

ในขณะเดียวกัน แนวคิดทั้งหมดเกี่ยวกับการแก้ไขข้อผิดพลาดแบบแบตช์ (batch debugging) โดยไม่ต้องคอมไพล์ใหม่ก็เริ่มล้าสมัย ระบบคอมพิวเตอร์แบบโต้ตอบ (interactive computing systems) ที่ใช้ตัวแปลภาษา (interpreters) หรือตัวคอมไพล์แบบเพิ่มส่วน (incremental compilers) ได้กลายเป็นความท้าทายที่สำคัญที่สุด แต่แม้แต่ในระบบแบบแบตช์ การปรากฏขึ้นของคอมไพเลอร์แบบที่คอมไพล์เร็วแต่รันช้า (fast-compile/slow-execute compilers) ก็ทำให้การแก้ไขข้อผิดพลาดและการทำ snapshot ในระดับซอร์สโค้ดกลายเป็นเทคนิคที่เป็นที่นิยมมากกว่า ระบบจะดีขึ้นเพียงใดหากความพยายามใน TESTRAN ถูกนำไปใช้เพื่อสร้างเครื่องมือแบบโต้ตอบและเครื่องมือคอมไพล์เร็วให้เร็วขึ้นและดีขึ้นกว่านี้!

อีกตัวอย่างหนึ่งคือตัวจัดตารางงาน (scheduler) ซึ่งให้ความสามารถที่ยอดเยี่ยมอย่างแท้จริงในการจัดการกระแสงานแบบแบตช์คงที่ (fixed-batch job stream) ในแง่หนึ่ง ตัวจัดตารางงานนี้คือระบบที่สองที่ได้รับการปรับปรุง พัฒนา และประดับประดาต่อยอดมาจากระบบปฏิบัติการดิสก์ 1410-7010 ซึ่งเป็นระบบแบบแบตช์ที่ไม่มีการทำงานหลายโปรแกรมพร้อมกัน (unmultiprogrammed) ยกเว้นในส่วนอินพุต-เอาต์พุต และมีจุดประสงค์หลักสำหรับแอปพลิเคชันทางธุรกิจ ในฐานะที่เป็นเช่นนั้น ตัวจัดตารางงานของ OS/360 จึงถือว่าดี แต่มันกลับแทบไม่ได้รับอิทธิพลเลยจากความต้องการของ OS/360 ในเรื่องการส่งงานจากระยะไกล (remote job entry), การทำงานหลายโปรแกรมพร้อมกัน และระบบย่อยแบบโต้ตอบที่ฝังตัวอยู่ถาวร อันที่จริง การออกแบบตัวจัดตารางงานทำให้สิ่งเหล่านี้ทำได้ยาก

สถาปนิกจะหลีกเลี่ยงผลกระทบจากระบบที่สองได้อย่างไร? แน่นอนว่าเขาไม่สามารถข้ามระบบที่สองของเขาไปได้ แต่เขาสามารถตระหนักถึงอันตรายเฉพาะตัวของระบบนั้น และใช้การฝึกฝนตนเองเป็นพิเศษเพื่อหลีกเลี่ยงการประดับประดาหน้าที่การทำงาน และหลีกเลี่ยงการขยายความสามารถของฟังก์ชันที่ถูกทำให้หมดความจำเป็นไปแล้วจากการเปลี่ยนแปลงในสมมติฐานและจุดประสงค์ ระเบียบวินัยหนึ่งที่จะช่วยเปิดตาของสถาปนิกคือการกำหนดมูลค่าให้กับแต่ละฟังก์ชันเล็กๆ: เช่น ความสามารถ x มีมูลค่าไม่เกิน m ไบต์ของหน่วยความจำ และ n ไมโครวินาทีต่อการเรียกใช้งานหนึ่งครั้ง มูลค่าเหล่านี้จะช่วยนำทางการตัดสินใจในช่วงแรก และทำหน้าที่เป็นแนวทางและคำเตือนแก่ทุกคนในระหว่างการนำไปใช้งาน

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