Hofstadter’s Law
มันใช้เวลานานกว่าที่คุณคิดเสมอ แม้จะเผื่อกฎนี้ไว้แล้วก็ตาม
Douglas Hofstadter เสนอกฎนี้ในหนังสือปี 1979 Gödel, Escher, Bach: An Eternal Golden Braid — หนังสือที่คว้ารางวัล Pulitzer และวนเวียนอยู่กับธีมเรื่อง recursion, self-reference และ strange loop ตลอดทั้งเล่ม กฎข้อนี้ปรากฏอยู่ในบทสนทนาสไตล์ Achilles กับ Tortoise ซึ่งเป็นรูปแบบเฉพาะตัวที่ Hofstadter ใช้อธิบายแนวคิดเชิงปรัชญาและตรรกะตลอดเล่ม
“มันใช้เวลานานกว่าที่คุณคาดเสมอ แม้ว่าคุณจะเผื่อกฎของ Hofstadter ไว้แล้วก็ตาม”
— Douglas Hofstadter
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”คำกล่าวเชิงวนซ้ำ (recursive) นี้ชี้ถึงอคติของมนุษย์ที่มัก ประเมินเวลาที่ต้องใช้กับงานซับซ้อนต่ำเกินไป โดยเฉพาะเมื่อมีความซับซ้อนและปัญหาที่คาดไม่ถึงเข้ามา ความน่าสนใจของกฎนี้อยู่ที่โครงสร้างการอ้างอิงตัวเอง (self-reference) — ต่อให้คุณรู้จักกฎนี้และพยายามเผื่อเวลาตามกฎนี้แล้ว งานก็ยังมักใช้เวลานานกว่าที่คุณคาดไว้ “หลังเผื่อแล้ว” อยู่ดี เพราะปัญหาที่แท้จริงไม่ใช่การขาดวินัยในการเผื่อเวลา แต่คือการที่มนุษย์ ไม่สามารถคาดการณ์สิ่งที่ยังไม่รู้ว่ามีอยู่ (unknown unknowns) ได้ล่วงหน้า
Hofstadter เองยกตัวอย่างจากวงการหมากรุกคอมพิวเตอร์เป็นภาพประกอบ นักวิจัยด้าน AI ในยุคนั้นทำนายซ้ำแล้วซ้ำเล่าว่า “คอมพิวเตอร์จะเอาชนะแชมป์โลกหมากรุกได้ภายในสิบปี” — และคำทำนายนี้ก็ยัง “อีกสิบปี” อยู่แบบนั้นต่อเนื่องหลายทศวรรษ (ในที่สุด Deep Blue ก็เอาชนะ Garry Kasparov ได้จริงในปี 1997 ซึ่งเป็นการยืนยันภายหลังว่าการประมาณการซ้ำ ๆ ที่ผิดพลาดตลอดหลายสิบปีนั้นเป็นของจริง ไม่ใช่เรื่องเล่น)
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”กฎของ Hofstadter เกี่ยวโยงกับแนวคิดทางจิตวิทยาที่เรียกว่า planning fallacy (Kahneman & Tversky) ซึ่งอธิบายว่ามนุษย์มักวางแผนโดยยึดสถานการณ์ที่ดีที่สุด (best-case scenario) เป็นฐาน แทนที่จะพิจารณาข้อมูลจากอดีตหรือความล่าช้าที่เคยเกิดขึ้นในโครงการคล้ายกัน ผลคือการประมาณเวลามัก “มองโลกในแง่ดีเกินจริง” อย่างเป็นระบบ ไม่ใช่แค่บางครั้งบางคราว
ในวงการซอฟต์แวร์ กฎนี้ถูกอ้างถึงคู่กับ The Mythical Man-Month ของ Fred Brooks และแนวคิด extreme programming อยู่บ่อยครั้ง เพราะทั้งสามพูดถึงปัญหาเดียวกันจากมุมต่างกัน: งานซอฟต์แวร์มีความซับซ้อนแฝง (hidden complexity) ที่มองไม่เห็นจนกว่าจะลงมือทำจริง — การรวม API ที่เอกสารไม่ตรงกับพฤติกรรมจริง, edge case ที่ requirement ไม่ได้พูดถึง, code เก่าที่ทีมลืมไปแล้วว่าซับซ้อนแค่ไหน ทั้งหมดนี้โผล่ขึ้นมาระหว่างทางเสมอ
กฎนี้ยังมีความตึงเครียดที่น่าสนใจกับ Parkinson’s Law ที่ว่า “งานจะขยายเวลาจนเต็มเวลาที่มีให้” — สองกฎนี้ดูเหมือนขัดกัน (กฎหนึ่งบอกว่างานใช้เวลานานกว่าที่คาด อีกกฎบอกว่างานจะยืดให้เต็มเวลาที่ตั้งไว้) แต่จริง ๆ แล้วเสริมกัน: การเผื่อ buffer มากเกินไปเพื่อรับมือ Hofstadter’s Law อาจทำให้ทีมหย่อนวินัยตาม Parkinson’s Law และใช้เวลาที่เผื่อไว้จนหมดโดยไม่จำเป็น จุดสมดุลจึงอยู่ที่การเผื่อเวลาอย่างมีเหตุผล ไม่ใช่เผื่อแบบไม่มีที่สิ้นสุด
แนวคิดที่เกี่ยวข้องอีกอย่างคือ cone of uncertainty ในการบริหารโครงการ — ยิ่งอยู่ในช่วงต้นของโครงการ ค่าประมาณเวลามีความไม่แน่นอนสูงมาก (อาจคลาดเคลื่อนได้หลายเท่าตัว) และค่อย ๆ แคบลงเมื่อมีข้อมูลมากขึ้นระหว่างทาง Hofstadter’s Law เป็นการยืนยันเชิงประสบการณ์ของปรากฏการณ์นี้: การประมาณช่วงต้นมักผิดไปในทิศทางเดียว คือ “สั้นเกินจริง” เสมอ ไม่ใช่สุ่มไปทั้งสองทาง
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- การพยากรณ์ AI เอาชนะหมากรุก — ตัวอย่างดั้งเดิมของ Hofstadter เอง ที่นักวิจัยทำนายซ้ำ ๆ ว่า “อีกสิบปี” อยู่นานหลายทศวรรษ ก่อนที่ Deep Blue จะเอาชนะ Kasparov ได้จริงในปี 1997
- Feature ที่ประเมินไว้หนึ่งเดือน — ทีมเผื่อ buffer เป็นหกสัปดาห์เพื่อความปลอดภัย แต่สุดท้ายโครงการลากยาวไปสามถึงหกเดือน เพราะการรวม API ที่มีปัญหา, พนักงานลาป่วยกะทันหัน, และแนวทางแรกที่ลองแล้วใช้ไม่ได้ต้องเริ่มใหม่
- Deadline ของซอฟต์แวร์ขนาดใหญ่ — โครงการซอฟต์แวร์ที่มีชื่อเสียงหลายโครงการ (ระบบปฏิบัติการ, เกม AAA, ระบบองค์กรขนาดใหญ่) มักเลื่อนกำหนดส่งซ้ำแล้วซ้ำเล่า แม้ทีมพัฒนาจะมีประสบการณ์สูงและรู้ตัวว่าเคยพลาดมาก่อน
- Sprint ที่ “เกือบเสร็จ” ทุกสัปดาห์ — ในทีม Agile ทั่วไป งานที่ถูกประเมินว่าจะเสร็จใน sprint นี้มักถูกเลื่อนไป sprint ถัดไปด้วยเหตุผลคล้ายเดิมซ้ำ ๆ (dependency ที่ไม่คาดคิด, การรีวิว code ที่พบปัญหาเชิงโครงสร้าง, requirement ที่เปลี่ยนกลางทาง)
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- อย่าวางแผนบนสมมติฐานที่ดีที่สุด ให้ใช้ข้อมูลจริงจากงานที่คล้ายกันในอดีต (historical velocity) แทนการเดาตามความรู้สึก
- แสดงค่าประมาณเป็นช่วง ไม่ใช่ตัวเลขเดี่ยว เช่น “22 ชั่วโมง ± 20%” เพื่อสื่อสารความไม่แน่นอนอย่างตรงไปตรงมา แทนที่จะให้ตัวเลขเดียวที่ดูแม่นยำเกินจริง
- แบ่งงานให้เล็กลง ค่าประมาณของงานที่ใช้เวลาหลายเดือนมักคลาดเคลื่อนมาก ในขณะที่งานที่แบ่งเป็นชิ้นเล็ก ๆ ระดับวันหรือสัปดาห์จะประมาณได้แม่นยำกว่า — หลักการง่าย ๆ คืองานสองนาทีให้ทำทันที งานไม่กี่นาทีให้เผื่อเป็นชั่วโมง งานไม่กี่ชั่วโมงให้เผื่อเป็นวัน
- ใช้เทคนิคประมาณการแบบกลุ่ม เช่น Wideband Delphi หรือ planning poker เพื่อลด bias ของคนคนเดียว และเปิดให้ทีมถกเถียงสมมติฐานที่ต่างกันก่อนสรุปตัวเลข
- เมื่อพลาดกำหนดก็ให้ อัปเดตแผน ตามจริง ไม่ใช่ดันทุรังตามแผนเดิมที่พิสูจน์แล้วว่าผิด การยอมรับความล่าช้าเร็วและปรับแผนใหม่ดีกว่าการซ่อนปัญหาไว้จนสายเกินแก้
- ใช้ Timeboxing ควบคู่กับ feedback loop สั้น ๆ เพื่อทบทวนและปรับประมาณการบ่อยครั้ง แทนที่จะวางแผนระยะยาวแบบตายตัวตั้งแต่ต้น
- ระวังไม่ให้ buffer ที่เผื่อไว้กลายเป็นข้ออ้างให้หย่อนวินัย ตาม Parkinson’s Law — เผื่อเวลาอย่างมีเหตุผลจากข้อมูล ไม่ใช่เผื่อแบบเดาสุ่มจนเสียความน่าเชื่อถือของค่าประมาณ
ที่เกี่ยวข้อง
หัวข้อที่มีชื่อว่า “ที่เกี่ยวข้อง”แหล่งอ้างอิง
หัวข้อที่มีชื่อว่า “แหล่งอ้างอิง”- ที่มา · deviq.com/laws/hofstadters-law
- Gödel, Escher, Bach: An Eternal Golden Braid — Douglas Hofstadter (1979)
- Hofstadter’s law — Wikipedia
- Hofstadter’s Law | Laws of Software Engineering
- Hofstadter’s Law — Embedded Artistry