ไม่มีอะไรในโลกนี้ที่คงที่ นอกจากความไม่คงที่
— SWIFT
เป็นสามัญสำนึกที่จะเลือกวิธีการแล้วลองทำ ถ้ามันล้มเหลว ก็ยอมรับอย่างตรงไปตรงมาแล้วลองวิธีอื่น แต่เหนือสิ่งอื่นใด จงลองทำอะไรสักอย่าง
— FRANKLIN D. ROOSEVELT [1]
Pilot Plants and Scaling Up (โรงงานนำร่องและการขยายขนาด)
วิศวกรเคมีเรียนรู้มานานแล้วว่ากระบวนการที่ทำงานได้ในห้องปฏิบัติการไม่สามารถนำไปใช้งานในโรงงานได้ในขั้นตอนเดียว จำเป็นต้องมีขั้นตอนกลางที่เรียกว่า pilot plant เพื่อให้มีประสบการณ์ในการขยายปริมาณและการทำงานในสภาพแวดล้อมที่ไม่ได้ถูกควบคุม ตัวอย่างเช่น กระบวนการแยกเกลือออกจากน้ำในห้องปฏิบัติการจะถูกทดสอบใน pilot plant ที่มีความจุ 10,000 แกลลอน/วัน ก่อนที่จะนำไปใช้กับระบบน้ำชุมชนขนาด 2,000,000 แกลลอน/วัน
ผู้สร้างระบบซอฟต์แวร์ก็เคยได้ยินบทเรียนนี้เช่นกัน แต่ดูเหมือนว่ายังไม่ได้เรียนรู้มันอย่างแท้จริง โปรเจกต์แล้วโปรเจกต์เล่าออกแบบชุดอัลกอริทึมแล้วก็พุ่งตรงเข้าสู่การสร้างซอฟต์แวร์ที่ส่งมอบให้ลูกค้าได้ตามตารางเวลาที่เรียกร้องให้ส่งมอบสิ่งแรกที่สร้างเสร็จ
ในโปรเจกต์ส่วนใหญ่ ระบบแรกที่สร้างขึ้นมาแทบจะใช้งานไม่ได้เลย มันอาจจะช้าเกินไป ใหญ่เกินไป ใช้งานยาก หรือทั้งสามอย่างรวมกัน ไม่มีทางเลือกอื่นนอกจากต้องเริ่มใหม่ เจ็บปวดแต่ฉลาดขึ้น และสร้างเวอร์ชันที่ออกแบบใหม่เพื่อแก้ปัญหาเหล่านี้ การทิ้งแล้วออกแบบใหม่อาจทำในครั้งเดียว หรือทำทีละส่วนก็ได้ แต่ประสบการณ์จากระบบขนาดใหญ่ทั้งหมดแสดงให้เห็นว่ามันจะเกิดขึ้นแน่นอน [2] เมื่อใดก็ตามที่มีการใช้แนวคิดระบบใหม่หรือเทคโนโลยีใหม่ เราจำเป็นต้องสร้างระบบเพื่อทิ้ง เพราะแม้การวางแผนที่ดีที่สุดก็ไม่สามารถรอบรู้พอที่จะทำให้ถูกต้องได้ในครั้งแรก
ดังนั้นคำถามสำหรับฝ่ายบริหารจึงไม่ใช่ ว่าจะ สร้าง pilot system แล้วทิ้งหรือไม่ เพราะคุณ จะ ทำอย่างนั้นอยู่ดี คำถามเดียวคือจะวางแผนล่วงหน้าให้สร้างของที่ต้องทิ้ง หรือจะสัญญากับลูกค้าว่าจะส่งมอบของที่ต้องทิ้งนั้นให้พวกเขา เมื่อมองแบบนี้ คำตอบก็ชัดเจนขึ้นมาก การส่งมอบของที่ต้องทิ้งให้ลูกค้าช่วยถ่วงเวลา แต่มันก็แลกมาด้วยความทรมานของผู้ใช้ ความว้าวุ่นใจของทีมพัฒนาที่ต้องออกแบบใหม่ และชื่อเสียงที่แย่ของผลิตภัณฑ์ ซึ่งแม้การออกแบบใหม่ที่ดีที่สุดก็ยากจะลบล้าง
เพราะฉะนั้น จงวางแผนที่จะทิ้งซักครั้ง เพราะยังไงคุณก็ต้องทำอยู่ดี .
The Only Constancy Is Change Itself (สิ่งเดียวที่คงที่คือการเปลี่ยนแปลง)
เมื่อเรายอมรับแล้วว่าระบบนำร่องต้องถูกสร้างและทิ้ง และการออกแบบใหม่ด้วยแนวคิดที่เปลี่ยนไปนั้นหนีไม่พ้น มันก็เป็นประโยชน์ที่จะเผชิญหน้ากับปรากฏการณ์ของการเปลี่ยนแปลงทั้งมวล ขั้นแรกคือการยอมรับความจริงที่ว่าการเปลี่ยนแปลงคือวิถีชีวิต ไม่ใช่ข้อยกเว้นที่น่ารำคาญ Cosgrove ชี้ให้เห็นอย่างเฉียบคมว่าโปรแกรมเมอร์ส่งมอบความพึงพอใจในความต้องการของผู้ใช้ ไม่ใช่ผลิตภัณฑ์ที่จับต้องได้ และทั้งความต้องการที่แท้จริงและการรับรู้ของผู้ใช้ต่อความต้องการนั้นจะเปลี่ยนแปลงไปเมื่อโปรแกรมถูกสร้าง ทดสอบ และใช้งาน [3]
แน่นอนว่าสิ่งนี้ก็เป็นจริงสำหรับความต้องการที่ถูกตอบสนองโดยผลิตภัณฑ์ฮาร์ดแวร์ ไม่ว่าจะเป็นรถยนต์รุ่นใหม่หรือคอมพิวเตอร์เครื่องใหม่ แต่การมีอยู่ของวัตถุที่จับต้องได้นั้นช่วยจำกัดและทำให้ความต้องการเปลี่ยนแปลงของผู้ใช้ลดลง การที่ซอฟต์แวร์เป็นสิ่งที่ปรับเปลี่ยนได้และมองไม่เห็น ทำให้ผู้สร้างต้องเผชิญกับการเปลี่ยนแปลงความต้องการที่ไม่สิ้นสุด
ผมไม่ได้หมายความว่าการเปลี่ยนแปลงทั้งหมดในเป้าหมายและข้อกำหนดของลูกค้าจะต้อง สามารถ หรือควรถูกนำเข้าไปในการออกแบบ แน่นอนว่าต้องมีการกำหนดเกณฑ์ขั้นต่ำ และเกณฑ์นี้ต้องสูงขึ้นเรื่อยๆ เมื่อการพัฒนาดำเนินไป มิเช่นนั้นจะไม่มีผลิตภัณฑ์ใดเกิดขึ้นมาเลย
อย่างไรก็ตาม การเปลี่ยนแปลงในเป้าหมายบางอย่างเป็นสิ่งที่หลีกเลี่ยงไม่ได้ และการเตรียมพร้อมรับมือก็ดีกว่าการสมมติว่ามันจะไม่เกิดขึ้น ไม่เพียงแต่การเปลี่ยนแปลงในเป้าหมายเท่านั้นที่เลี่ยงไม่ได้ การเปลี่ยนแปลงในกลยุทธ์และเทคนิคการพัฒนาก็เลี่ยงไม่ได้เช่นกัน แนวคิดการทิ้งซักครั้งนั้นก็เป็นเพียงการยอมรับความจริงที่ว่าเมื่อเราเรียนรู้ เราก็เปลี่ยนแปลงการออกแบบ [4]
Plan the System for Change (วางแผนระบบให้พร้อมรับการเปลี่ยนแปลง)
วิธีการออกแบบระบบให้รองรับการเปลี่ยนแปลงนั้นเป็นที่รู้จักกันดีและถูกพูดถึงอย่างกว้างขวางในวงการ—บางทีอาจถูกพูดถึงมากกว่าที่นำไปปฏิบัติเสียอีก วิธีการเหล่านี้รวมถึงการทำ modularization อย่างระมัดระวัง การสร้าง subroutine อย่างครอบคลุม การกำหนด interface ระหว่าง module ให้แม่นยำและสมบูรณ์ และการจัดทำ documentation ที่ครบถ้วน สิ่งที่เห็นได้ไม่ชัดเท่าก็คือการใช้ standard calling sequences และเทคนิคแบบ table-driven ทุกครั้งที่ทำได้
ที่สำคัญที่สุดคือการใช้ high-level language และเทคนิค self-documenting เพื่อลดข้อผิดพลาดที่เกิดจากการเปลี่ยนแปลง การใช้ compile-time operations เพื่อรวม standard declarations เข้ามาช่วยได้อย่างมีประสิทธิภาพในการจัดการกับการเปลี่ยนแปลง
การแบ่งการเปลี่ยนแปลงเป็นส่วนๆ (quantization of change) เป็นเทคนิคที่จำเป็น ทุกผลิตภัณฑ์ควรมีหมายเลขเวอร์ชัน และแต่ละเวอร์ชันต้องมีตารางเวลาและวันที่ freeze ของตัวเอง หลังจากนั้นการเปลี่ยนแปลงทั้งหมดจะไปอยู่ในเวอร์ชันถัดไป
Plan the Organization for Change (วางแผนองค์กรให้พร้อมรับการเปลี่ยนแปลง)
Cosgrove เสนอให้มองแผนทั้งหมด milestones และตารางเวลาเป็นเพียงสิ่งชั่วคราว เพื่อให้การเปลี่ยนแปลงทำได้ง่ายขึ้น แต่แนวคิดนี้ไปไกลเกินไป—จุดอ่อนทั่วไปของทีมพัฒนาโปรแกรมในปัจจุบันคือการควบคุมโดยฝ่ายบริหารน้อยเกินไป ไม่ใช่มากเกินไป
อย่างไรก็ตาม เขาให้ข้อคิดที่ยอดเยี่ยมไว้ เขาสังเกตว่าความไม่เต็มใจที่จะทำเอกสารการออกแบบนั้นไม่ได้เกิดจากความขี้เกียจหรือแรงกดดันด้านเวลาเพียงอย่างเดียว แต่เกิดจากความไม่เต็มใจของนักออกแบบที่จะผูกมัดตัวเองให้ต้องปกป้องการตัดสินใจที่เขารู้ว่ายังเป็นเพียงชั่วคราว "การทำเอกสารการออกแบบทำให้นักออกแบบเปิดเผยตัวเองต่อคำวิจารณ์ของทุกคน และเขาจะต้องสามารถปกป้องทุกสิ่งที่เขาเขียน ถ้าโครงสร้างองค์กรมีความเป็นภัยในทางใดทางหนึ่ง จะไม่มีอะไรถูกบันทึกเป็นเอกสารจนกว่ามันจะป้องกันได้อย่างสมบูรณ์"
การจัดโครงสร้างองค์กรให้พร้อมรับการเปลี่ยนแปลงนั้นยากกว่าการออกแบบระบบให้พร้อมรับการเปลี่ยนแปลงมาก แต่ละคนต้องได้รับมอบหมายงานที่ช่วยขยายขอบเขตความสามารถของเขา เพื่อให้ทีมงานทั้งหมดมีความยืดหยุ่นทางเทคนิค ในโปรเจกต์ขนาดใหญ่ ผู้จัดการจำเป็นต้องมีโปรแกรมเมอร์ระดับท็อปสองสามคนเป็นกองกำลังสำรองทางเทคนิคที่พร้อมจะเข้าไปช่วยได้ทุกเมื่อในจุดที่การศึกหนักที่สุด
โครงสร้างการบริหารก็ต้องเปลี่ยนแปลงไปเมื่อระบบเปลี่ยนแปลง นั่นหมายความว่าหัวหน้าต้องให้ความสนใจอย่างมากในการทำให้ผู้จัดการและคนทางเทคนิคของเขาสามารถสับเปลี่ยนกันได้เท่าที่ความสามารถของพวกเขาจะเอื้ออำนวย
อุปสรรคเหล่านี้เป็นเรื่องทางสังคมวิทยา และต้องต่อสู้ด้วยความตื่นตัวอยู่เสมอ ประการแรก ผู้จัดการมักคิดว่าคนที่มีประสบการณ์สูง "มีค่ามากเกินไป" ที่จะใช้ทำงานเขียนโปรแกรมจริงๆ ประการที่สอง ตำแหน่งงานด้านบริหารมีเกียรติภูมิสูงกว่า เพื่อแก้ปัญหานี้ ห้องปฏิบัติการบางแห่ง เช่น Bell Labs ยกเลิกตำแหน่งงานทั้งหมด พนักงานวิชาชีพทุกคนเป็น "member of the technical staff" บางแห่งเช่น IBM ใช้ระบบบันไดความก้าวหน้าแบบคู่ (dual ladder of advancement) ดังที่ Fig. 11.1 แสดงไว้ ขั้นบันไดที่เทียบระดับกันนั้นตามทฤษฎีแล้วเท่าเทียมกัน
Figure 11.1. IBM dual ladder of advancement (บันไดความก้าวหน้าแบบคู่ของ IBM)
การกำหนดระดับเงินเดือนให้สอดคล้องกันนั้นทำได้ง่าย แต่การให้เกียรติภูมิที่เท่าเทียมกันนั้นทำได้ยากกว่ามาก ห้องทำงานต้องมีขนาดและสิ่งอำนวยความสะดวกเท่ากัน บริการเลขานุการและการสนับสนุนอื่นๆ ต้องสอดคล้องกัน การย้ายจากสายเทคนิคไปยังระดับที่เทียบเท่ากันในสายบริหารไม่ควรมาพร้อมกับการขึ้นเงินเดือน และควรประกาศว่าเป็นการ "reassignment" เท่านั้น ไม่ใช่ "promotion" การย้ายกลับในทิศทางตรงกันข้ามควรมาพร้อมกับการขึ้นเงินเดือนเสมอ การชดเชยที่เกินพอสำหรับแรงผลักทางวัฒนธรรมเป็นสิ่งจำเป็น
ผู้จัดการควรถูกส่งไปเรียนหลักสูตรทบทวนความรู้ทางเทคนิค และคนทางเทคนิคระดับอาวุโสควรถูกส่งไปอบรมด้านการบริหาร เป้าหมายของโปรเจกต์ ความคืบหน้า และปัญหาด้านการจัดการต้องถูกแบ่งปันกับทีมอาวุโสทั้งหมด
เมื่อใดก็ตามที่ความสามารถเอื้ออำนวย คนอาวุโสต้องถูกทำให้พร้อมทั้งทางเทคนิคและทางอารมณ์ที่จะบริหารทีมหรือมีความสุขกับการสร้างโปรแกรมด้วยมือของตัวเอง การทำเช่นนี้เป็นงานที่หนักแน่นอน แต่มันก็คุ้มค่าอย่างแน่นอน!
แนวคิดทั้งหมดของการจัดทีมพัฒนาแบบ surgical team เป็นการโจมตีปัญหานี้อย่างถึงรากถึงโคน มันทำให้คนอาวุโสรู้สึกว่าเขาไม่ได้ลดศักดิ์ศรีเมื่อลงมือเขียนโปรแกรม และมันพยายามขจัดอุปสรรคทางสังคมที่กีดกันเขาจากความสุขในการสร้างสรรค์นั้น
ยิ่งไปกว่านั้น โครงสร้างดังกล่าวถูกออกแบบมาเพื่อลดจำนวน interface ให้เหลือน้อยที่สุด ซึ่งทำให้ระบบเปลี่ยนแปลงได้ง่ายที่สุด และทำให้การย้ายทีม surgical team ทั้งทีมไปยังงานเขียนโปรแกรมอื่นทำได้ค่อนข้างง่ายเมื่อจำเป็นต้องมีการเปลี่ยนแปลงองค์กร นี่คือคำตอบระยะยาวสำหรับปัญหาขององค์กรที่ยืดหยุ่นอย่างแท้จริง
Two Steps Forward and One Step Back (ก้าวไปสองก้าว ถอยกลับหนึ่งก้าว)
โปรแกรมไม่ได้หยุดเปลี่ยนแปลงเมื่อถูกส่งมอบให้ลูกค้าใช้งาน การเปลี่ยนแปลงหลังส่งมอบเรียกว่า program maintenance แต่กระบวนการนี้แตกต่างอย่างสิ้นเชิงจากการ maintenance ฮาร์ดแวร์
การ maintenance ฮาร์ดแวร์สำหรับระบบคอมพิวเตอร์เกี่ยวข้องกับกิจกรรมสามอย่าง—การเปลี่ยนชิ้นส่วนที่เสื่อมสภาพ การทำความสะอาดและหล่อลื่น และการใส่วิศวกรรมเปลี่ยนแปลงที่แก้ไขข้อบกพร่องในการออกแบบ (การเปลี่ยนแปลงทางวิศวกรรมส่วนใหญ่—แต่ไม่ทั้งหมด—แก้ไขข้อบกพร่องในขั้นตอนการทำให้เกิดขึ้นจริงหรือการ implement มากกว่าสถาปัตยกรรม ดังนั้นจึงมองไม่เห็นโดยผู้ใช้)
การ maintenance โปรแกรมไม่เกี่ยวข้องกับการทำความสะอาด การหล่อลื่น หรือการซ่อมแซมความเสื่อมสภาพ มันประกอบด้วยการเปลี่ยนแปลงที่แก้ไขข้อบกพร่องในการออกแบบเป็นหลัก และบ่อยกว่าฮาร์ดแวร์มากที่การเปลี่ยนแปลงเหล่านี้รวมถึงการเพิ่มฟังก์ชันใหม่ โดยปกติแล้วผู้ใช้จะมองเห็นการเปลี่ยนแปลงเหล่านี้
ค่าใช้จ่ายทั้งหมดในการ maintenance โปรแกรมที่ถูกใช้อย่างแพร่หลายโดยทั่วไปแล้วอยู่ที่ 40 เปอร์เซ็นต์หรือมากกว่าของค่าใช้จ่ายในการพัฒนามัน ที่น่าแปลกคือค่าใช้จ่ายนี้ได้รับผลกระทบอย่างมากจากจำนวนผู้ใช้ ยิ่งมีผู้ใช้มากก็ยิ่งพบ bugs มากขึ้น
Betty Campbell จาก MIT's Laboratory for Nuclear Science ชี้ให้เห็นวัฏจักรที่น่าสนใจในอายุของ release หนึ่งของโปรแกรม ดังที่แสดงใน Fig. 11.2 ในตอนแรก bugs เก่าที่พบและแก้ไขใน releases ก่อนหน้ามักจะกลับมาปรากฏอีกครั้งใน release ใหม่ ฟังก์ชันใหม่ของ release ใหม่ก็มักจะมีข้อบกพร่อง สิ่งเหล่านี้ถูกขจัดออกไป และทุกอย่างก็ดำเนินไปได้ด้วยดีเป็นเวลาหลายเดือน จากนั้นอัตราการเกิด bugs ก็เริ่มสูงขึ้นอีกครั้ง Miss Campbell เชื่อว่านี่เป็นเพราะผู้ใช้มาถึงระดับความชำนาญใหม่ที่พวกเขาเริ่มใช้ความสามารถใหม่ของ release อย่างเต็มที่ การใช้งานอย่างหนักนี้จะดึง bugs ที่ซ่อนเร้นมากขึ้นในฟีเจอร์ใหม่ออกมา [5]
Figure 11.2. Bug occurrence as a function of release age (การเกิด bug ตามอายุของ release)
ปัญหาพื้นฐานของการ maintenance โปรแกรมคือการแก้ไขข้อบกพร่องหนึ่งมีโอกาสสูง (20–50 เปอร์เซ็นต์) ที่จะนำข้อบกพร่องอื่นเข้ามา ดังนั้นกระบวนการทั้งหมดจึงเป็นแบบก้าวไปสองก้าว ถอยกลับหนึ่งก้าว
ทำไมข้อบกพร่องถึงไม่ถูกแก้ไขอย่างสะอาด? ประการแรก แม้แต่ข้อบกพร่องที่ซ่อนเร้นก็แสดงตัวเป็นความล้มเหลวเฉพาะจุดบางอย่าง ในความเป็นจริงมันมักจะมีผลกระทบในวงกว้างต่อระบบ ซึ่งมักไม่ชัดเจน ความพยายามแก้ไขด้วยความพยายามน้อยที่สุดจะซ่อมเฉพาะจุดที่เห็นได้ชัด แต่ถ้าโครงสร้างไม่บริสุทธิ์เพียงพอหรือ documentation ไม่ละเอียดพอ ผลกระทบในวงกว้างของการซ่อมแซมนั้นจะถูกมองข้ามไป ประการที่สอง คนที่ซ่อมแซมมักไม่ใช่คนที่เขียนโค้ด และบ่อยครั้งเขาเป็นโปรแกรมเมอร์รุ่นน้องหรือเด็กฝึกงาน
ผลที่ตามมาจากการนำ bugs ใหม่เข้ามาคือการ maintenance โปรแกรมต้องใช้การทดสอบระบบต่อบรรทัดโค้ดที่เขียนมากกว่างานเขียนโปรแกรมอื่นๆ มาก ในทางทฤษฎี หลังการแก้ไขแต่ละครั้งเราต้องรัน test cases ทั้งหมดที่เคยรันกับระบบมาก่อน เพื่อให้แน่ใจว่าระบบไม่ได้รับความเสียหายในทางที่ซ่อนเร้น ในทางปฏิบัติ regression testing แบบนี้ต้องใกล้เคียงกับอุดมคติทางทฤษฎี และมันมีค่าใช้จ่ายสูงมาก
แน่นอนว่าวิธีการออกแบบโปรแกรมเพื่อกำจัดหรืออย่างน้อยก็ทำให้เห็นผลข้างเคียงได้ชัดเจน สามารถให้ผลตอบแทนมหาศาลในด้านค่าใช้จ่ายในการ maintenance เช่นเดียวกับวิธีการ implement ด้วยคนน้อยลง มี interface น้อยลง และส่งผลให้มี bugs น้อยลง
One Step Forward and One Step Back (ก้าวไปหนึ่งก้าว ถอยกลับหนึ่งก้าว)
Lehman และ Belady ได้ศึกษาประวัติศาสตร์ของ releases ต่อเนื่องในระบบปฏิบัติการขนาดใหญ่ [6] พวกเขาพบว่าจำนวน modules ทั้งหมดเพิ่มขึ้นเป็นเส้นตรงตามหมายเลข release แต่จำนวน modules ที่ได้รับผลกระทบเพิ่มขึ้นแบบทวีคูณตามหมายเลข release การซ่อมแซมทั้งหมดมีแนวโน้มที่จะทำลายโครงสร้าง เพิ่ม entropy และความไม่เป็นระเบียบของระบบ ความพยายามที่ใช้ในการแก้ไขข้อบกพร่องในการออกแบบดั้งเดิมลดลงเรื่อยๆ ในขณะที่ความพยายามในการแก้ไขข้อบกพร่องที่เกิดจากการแก้ไขครั้งก่อนเพิ่มขึ้นเรื่อยๆ เมื่อเวลาผ่านไป ระบบก็มีความเป็นระเบียบน้อยลงเรื่อยๆ ไม่ช้าก็เร็วการแก้ไขก็ไม่มีความคืบหน้าอีกต่อไป แต่ละก้าวไปข้างหน้าจะถูกหักล้างด้วยก้าวถอยหลังหนึ่งก้าว แม้ว่าในหลักการจะใช้งานได้ตลอดไป แต่ระบบก็หมดสภาพในการเป็นฐานสำหรับการพัฒนาต่อ ยิ่งไปกว่านั้น เครื่องจักรก็เปลี่ยน การกำหนดค่าก็เปลี่ยน และความต้องการของผู้ใช้ก็เปลี่ยน ดังนั้นระบบจึงไม่ได้ใช้งานได้ตลอดไปจริงๆ การออกแบบใหม่ทั้งหมดตั้งแต่ต้นเป็นสิ่งจำเป็น
และจากแบบจำลองทางสถิติเชิงกลศาสตร์ Belady และ Lehman ก็มาถึงข้อสรุปที่ทั่วไปมากขึ้นสำหรับระบบซอฟต์แวร์ ซึ่งได้รับการสนับสนุนจากประสบการณ์ของทุกคนทั่วโลก "สิ่งต่าง ๆ มักจะดีที่สุดในตอนเริ่มต้น" ปาสกาลกล่าว C. S. Lewis กล่าวได้เฉียบคมยิ่งกว่า:
นั่นคือกุญแจสำคัญของประวัติศาสตร์ พลังงานมหาศาลถูกใช้ไป—อารยธรรมถูกสร้างขึ้น—สถาบันที่ยอดเยี่ยมถูกคิดค้นขึ้น แต่ทุกครั้งก็มีบางอย่างผิดพลาด ข้อบกพร่องร้ายแรงบางอย่างมักจะนำพาคนเห็นแก่ตัวและโหดร้ายขึ้นมาอยู่บนจุดสูงสุด แล้วทุกอย่างก็ถอยกลับไปสู่ความทุกข์และความพินาศ อันที่จริง เครื่องจักรก็พัง มันดูเหมือนจะสตาร์ทได้ดีและวิ่งไปได้สองสามหลา แล้วมันก็เสีย [7]
การสร้างระบบซอฟต์แวร์เป็นกระบวนการที่ลด entropy ดังนั้นโดยธรรมชาติแล้วมันจึง metastable (เสถียรแบบชั่วคราว) การ maintenance โปรแกรมเป็นกระบวนการที่เพิ่ม entropy และแม้แต่การดำเนินการที่ชำนาญที่สุดก็เพียงแค่ชะลอการทรุดตัวของระบบไปสู่ความล้าสมัยที่ไม่อาจแก้ไขได้