Plan to Throw One Away

"ในโลกนี้ไม่มีสิ่งใดคงที่ นอกจากความไม่คงที่" — สวิฟต์ (SWIFT)

"เป็นสามัญสำนึกที่จะเลือกวิธีการมาลองใช้ดู หากมันล้มเหลว ก็ยอมรับมันอย่างตรงไปตรงมาแล้วลองวิธีอื่น แต่เหนือสิ่งอื่นใด จงลองทำอะไรสักอย่าง" — แฟรงกลิน ดี. รูสเวลต์ (FRANKLIN D. ROOSEVELT)

การพังทลายของสะพาน Tacoma Narrows Bridge ที่ออกแบบผิดพลาดตามหลักพลศาสตร์ของไหล, 1940

Pilot Plants and Scaling Up

วิศวกรเคมีเรียนรู้มานานแล้วว่า กระบวนการที่ทำงานได้ในห้องแล็บไม่สามารถนำไปใช้ในโรงงานจริงได้ในขั้นตอนเดียว จำเป็นต้องมีขั้นตอนระหว่างกลางที่เรียกว่า โรงงานต้นแบบ (pilot plant) เพื่อให้ได้ประสบการณ์ในการขยายขนาดปริมาณงานและการทำงานในสภาพแวดล้อมที่ไม่มีการป้องกัน ตัวอย่างเช่น กระบวนการแยกเกลือออกจากน้ำในห้องแล็บจะถูกทดสอบในโรงงานต้นแบบที่มีความจุ 10,000 แกลลอนต่อวัน ก่อนจะถูกนำไปใช้ในระบบน้ำประปาของชุมชนขนาด 2,000,000 แกลลอนต่อวัน

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

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

ดังนั้น จงวางแผนที่จะทิ้งมันไปหนึ่งชิ้น เพราะอย่างไรเสียคุณก็ต้องทำเช่นนั้นอยู่ดี

The Only Constancy Is Change Itself

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

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

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

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

Plan the System for Change

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

สิ่งที่เห็นได้ชัดน้อยกว่าคือ เราต้องการลำดับการเรียกใช้ที่เป็นมาตรฐาน (standard calling sequences) และเทคนิคการขับเคลื่อนด้วยตาราง (table-driven techniques) ในทุกที่ที่เป็นไปได้

สิ่งที่สำคัญที่สุดคือการใช้ภาษาระดับสูงและเทคนิคการทำเอกสารประกอบในตัว (self-documenting techniques) เพื่อลดข้อผิดพลาดที่เกิดจากการเปลี่ยนแปลง การใช้การทำงานในขณะคอมไพล์ (compile-time operations) เพื่อรวมการประกาศที่เป็นมาตรฐานจะช่วยอย่างมากในการทำการเปลี่ยนแปลง

การแบ่งช่วงของการเปลี่ยนแปลง (quantization of change) เป็นเทคนิคที่จำเป็น ทุกผลิตภัณฑ์ควรมีเวอร์ชันที่ระบุหมายเลข และแต่ละเวอร์ชันต้องมีกำหนดการและวันที่ "แช่แข็ง" (freeze date) ของตัวเอง หลังจากนั้นการเปลี่ยนแปลงใดๆ จะต้องไปอยู่ในเวอร์ชันถัดไป

Plan the Organization for Change

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

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

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

โครงสร้างการบริหารจัดการก็จำเป็นต้องเปลี่ยนไปตามระบบที่เปลี่ยนไป ซึ่งหมายความว่าบอสจะต้องให้ความสำคัญอย่างมากในการทำให้ผู้จัดการและเจ้าหน้าที่ด้านเทคนิคของเขาสามารถสับเปลี่ยนหน้าที่กันได้เท่าที่พรสวรรค์จะเอื้ออำนวย อุปสรรคสำคัญคือเรื่องทางสังคมวิทยา และต้องต่อสู้กับมันด้วยความระมัดระวังอย่างต่อเนื่อง ประการแรก ตัวผู้จัดการเองมักคิดว่าพนักงานอาวุโสนั้น "มีค่าเกินไป" ที่จะนำไปใช้งานเขียนโปรแกรมจริงๆ ประการต่อมา งานด้านการบริหารจัดการมีเกียรติภูมิที่สูงกว่า เพื่อเอาชนะปัญหานี้ ห้องปฏิบัติการบางแห่ง เช่น Bell Labs จึงยกเลิกชื่อตำแหน่งงานทั้งหมด โดยพนักงานมืออาชีพแต่ละคนจะเป็น "สมาชิกของเจ้าหน้าที่ฝ่ายเทคนิค" (member of the technical staff) ส่วนที่อื่นๆ เช่น IBM มี "บันไดความก้าวหน้าคู่" (dual ladder of advancement) ดังที่แสดงในรูปที่ 11.1 ซึ่งขั้นบันไดที่ตรงกันนั้นในทางทฤษฎีถือว่าเท่าเทียมกัน

รูปที่ 11.1 บันไดความก้าวหน้าคู่ของ IBM

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

ปัญหาพื้นฐานของการบำรุงรักษาโปรแกรม (program maintenance) คือการแก้ไขจุดบกพร่องมีโอกาสสูง (20-50 เปอร์เซ็นต์) ที่จะนำจุดบกพร่องใหม่เข้ามา ดังนั้นกระบวนการทั้งหมดจึงเป็นการก้าวไปข้างหน้าสองก้าวและถอยหลังหนึ่งก้าว ทำไมจุดบกพร่องถึงไม่ได้รับการแก้ไขให้สะอาดกว่านี้? ประการแรก แม้แต่จุดบกพร่องเล็กน้อยก็แสดงตัวออกมาในรูปแบบของความล้มเหลวเฉพาะจุดบางอย่าง ทว่าในความเป็นจริงมันมักจะมีผลกระทบไปทั่วทั้งระบบ ซึ่งมักจะไม่ชัดเจน ความพยายามใดๆ ที่จะแก้ไขมันด้วยความพยายามให้น้อยที่สุดจะช่วยซ่อมแซมส่วนที่เห็นได้ชัดและอยู่เฉพาะจุด แต่หากโครงสร้างไม่บริสุทธิ์หรือเอกสารประกอบไม่ดีพอ ผลกระทบที่กว้างไกลของการซ่อมแซมนั้นก็จะถูกมองข้ามไป ประการที่สอง ผู้ซ่อมแซมมักจะไม่ใช่คนเขียนโค้ดนั้นเอง และบ่อยครั้งเขาก็เป็นนักเขียนโปรแกรมระดับจูเนียร์หรือเด็กฝึกงาน

ผลที่ตามมาของการนำบั๊กใหม่ๆ เข้ามาคือ การบำรุงรักษาโปรแกรมต้องการการทดสอบระบบต่อหนึ่งบรรทัดที่เขียนมากกว่าการเขียนโปรแกรมประเภทอื่นๆ ในทางทฤษฎี หลังจากแก้ไขแต่ละครั้ง เราต้องรันกรณีทดสอบทั้งหมดที่เคยรันกับระบบนั้น เพื่อรับประกันว่ามันจะไม่ได้รับความเสียหายในจุดที่มองไม่เห็น ในทางปฏิบัติ การทดสอบการถดถอย (regression testing) ดังกล่าวจะต้องใกล้เคียงกับอุดมคติในทางทฤษฎีนี้ และมันมีราคาแพงมาก ชัดเจนว่าวิธีการออกแบบโปรแกรมเพื่อกำจัดหรืออย่างน้อยก็ทำให้เห็นผลข้างเคียง (side effects) ได้ชัดเจนนั้น จะให้ผลตอบแทนมหาศาลในแง่ของต้นทุนการบำรุงรักษา เช่นเดียวกับวิธีการนำงานออกแบบไปสร้างจริงโดยใช้คนน้อยลง มีอินเทอร์เฟซน้อยลง และส่งผลให้มีบั๊กน้อยลงตามไปด้วย

One Step Forward and One Step Back

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

และจากการใช้แบบจำลองกลศาสตร์เชิงสถิติ Belady และ Lehman ได้ข้อสรุปทั่วไปสำหรับระบบการเขียนโปรแกรมซึ่งได้รับการสนับสนุนจากประสบการณ์ทั่วโลก "สิ่งต่างๆ มักจะอยู่ในสภาพที่ดีที่สุดในช่วงเริ่มต้น" ปาสคาล (Pascal) กล่าวไว้ ส่วน ซี. เอส. ลูอิส (C. S. Lewis) ได้กล่าวไว้ได้อย่างเฉียบคมยิ่งกว่า:

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

การสร้างโปรแกรมระบบเป็นกระบวนการที่ลดเอนโทรปี (entropy-decreasing process) ดังนั้นมันจึงมีความเสถียรเพียงชั่วคราว (metastable) โดยธรรมชาติ ส่วนการบำรุงรักษาโปรแกรมเป็นกระบวนการที่เพิ่มเอนโทรปี (entropy-increasing process) และแม้แต่การปฏิบัติที่ชำนาญที่สุดก็ทำได้เพียงประวิงเวลาการเสื่อมสลายของระบบไปสู่ความล้าสมัยที่ไม่อาจแก้ไขได้เท่านั้น