Wirth's Law
ซอฟต์แวร์ช้าลงเร็วกว่าที่ฮาร์ดแวร์เร็วขึ้น
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”Wirth’s Law ตั้งชื่อตาม Niklaus Wirth นักวิทยาการคอมพิวเตอร์ชาวสวิสผู้ออกแบบภาษา Pascal, Modula-2 และระบบปฏิบัติการ Oberon เขาเขียนถึงข้อสังเกตนี้ไว้ในบทความชื่อ “A Plea for Lean Software” ตีพิมพ์ในวารสาร Computer ของ IEEE เมื่อเดือนกุมภาพันธ์ ค.ศ. 1995 โดยกล่าวว่า “software is getting slower more rapidly than hardware becomes faster” — ซอฟต์แวร์ช้าลงเร็วกว่าที่ฮาร์ดแวร์เร็วขึ้น
ที่น่าสนใจคือ Wirth เองไม่ได้อ้างว่าตัวเองเป็นผู้คิดคำนี้ขึ้นมาก่อน เขาให้เครดิตกับ Martin Reiser ผู้เขียนคำนำของหนังสือเกี่ยวกับระบบ Oberon ที่เคยเขียนไว้ว่า “software manages to outgrow hardware in size and sluggishness” (ซอฟต์แวร์มีขนาดใหญ่ขึ้นและอืดขึ้นเร็วกว่าฮาร์ดแวร์ที่มันวิ่งอยู่) ตัวปรากฏการณ์นี้ถูกสังเกตเห็นตั้งแต่ราวปี 1987 แล้ว ก่อนที่ Wirth จะนำมาเขียนขยายความให้เป็นที่รู้จักในวงกว้าง
หลักการนี้จับคู่กับ Moore’s Law ในลักษณะตรงข้ามกันพอดี — Moore’s Law บอกว่าพลังประมวลผลต่อต้นทุนเพิ่มขึ้นเป็นเท่าตัวทุก ๆ ราว 18-24 เดือน ส่วน Wirth’s Law บอกว่าไม่ว่าฮาร์ดแวร์จะเร็วขึ้นแค่ไหน ซอฟต์แวร์ก็มักจะ “กิน” ความเร็วที่เพิ่มมานั้นจนหมด และมักจะกินมากกว่าด้วยซ้ำ ทำให้ผู้ใช้ปลายทางแทบไม่รู้สึกว่าเครื่องเร็วขึ้นเลยในการใช้งานจริง ปรากฏการณ์นี้มีชื่อเรียกทั่วไปว่า software bloat (ซอฟต์แวร์อืดฉุย)
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”Wirth ชี้ว่าปัจจัยสำคัญสองอย่างที่ทำให้เกิด software bloat คือ
- ฮาร์ดแวร์ที่ดีขึ้นเรื่อย ๆ เปิดทางให้ทำแบบนั้นได้ — เมื่อ RAM, CPU และ storage ราคาถูกลงและแรงขึ้น นักพัฒนาก็ไม่มีแรงกดดันให้ต้องเขียน code ให้ประหยัดทรัพยากรเหมือนยุค 1970 ที่หน่วยความจำมีจำกัดจนต้องคิดทุก byte
- ผู้ใช้แยกแยะไม่ออกว่าอะไรจำเป็นกับอะไรแค่ “น่ามี” — Wirth เขียนไว้ตรง ๆ ว่าคนมักเข้าใจผิดว่าความซับซ้อนคือความซับซ้อนที่ซับซ้อน (“customers have trouble distinguishing between essential features and those that are just nice to have”) ทำให้ feature ที่ไม่จำเป็นถูกเพิ่มเข้ามาเรื่อย ๆ โดยไม่มีใครอยากตัดออก
ผลลัพธ์คือ layer ของ abstraction ซ้อนทับกันหลายชั้น — framework บน framework, VM บน VM, ชั้น interop เพื่อรองรับหลาย platform/หลายรูปแบบ file — แต่ละชั้นดูสมเหตุสมผลในตัวมันเอง แต่เมื่อรวมกันแล้วกลับกินทรัพยากรมากกว่าที่ควร Wirth เองพิสูจน์ว่ามันไม่จำเป็นต้องเป็นแบบนี้ ด้วยการนำทีมพัฒนาระบบปฏิบัติการ Oberon (1986-1989) ที่ทั้งระบบ compiler และ OS มีขนาดเล็กกว่าซอฟต์แวร์ร่วมสมัยมาก แต่ยังทำงานได้ครบถ้วน
สิ่งที่ควรเข้าใจให้ชัดคือ Wirth’s Law ไม่ใช่กฎฟิสิกส์หรือทฤษฎีที่พิสูจน์ได้ทางคณิตศาสตร์ (ต่างจาก Moore’s Law ที่อย่างน้อยยังอิงกับข้อมูลการผลิต semiconductor) มันเป็น adage หรือข้อสังเกตเชิงประสบการณ์ (empirical observation) ที่สะท้อนแรงจูงใจขององค์กรและพฤติกรรมของทีมพัฒนามากกว่าจะเป็นกฎเกณฑ์ตายตัว — แต่ก็เป็นข้อสังเกตที่ถูกยืนยันซ้ำแล้วซ้ำเล่าในรอบสามสิบปีที่ผ่านมา จนมีคนตั้งชื่อแปรผันของมันหลายแบบ เช่น Gates’s Law (“the speed of software halves every 18 months” — ความเร็วของซอฟต์แวร์เชิงพาณิชย์ลดลงครึ่งหนึ่งทุก 18 เดือน อ้างถึง Bill Gates แม้ไม่มีหลักฐานว่าเขาพูดจริง), May’s Law (ตั้งชื่อตาม David May ว่าประสิทธิภาพซอฟต์แวร์ลดลงครึ่งหนึ่งทุก 18 เดือนเช่นกัน เป็นการหักล้าง Moore’s Law พอดิบพอดี), Page’s Law (Larry Page แห่ง Google พูดถึงแนวคิดเดียวกันซ้ำในปี 2009), และวลีติดตลกที่ว่า “What Andy giveth, Bill taketh away” ซึ่งพาดพิงถึง Andy Grove แห่ง Intel ผู้ทำให้ชิปเร็วขึ้น กับ Bill Gates แห่ง Microsoft ผู้ที่ระบบปฏิบัติการรุ่นใหม่ ๆ มักต้องการทรัพยากรมากขึ้นตามไปด้วย
graph LR
A[Hardware เร็วขึ้นตาม Moore Law] --> B[ทีมมีทรัพยากรเหลือเฟือ]
B --> C[เพิ่ม feature และ abstraction layers]
C --> D[Software ใช้ทรัพยากรมากขึ้น]
D --> E[ผู้ใช้รู้สึกว่าเครื่องไม่ได้เร็วขึ้นเลย]
E --> A
วงจรนี้อธิบายว่าทำไมคอมพิวเตอร์และมือถือยุคปัจจุบันแรงกว่ายุค 1990 นับพันเท่า แต่การเปิดโปรแกรมพื้นฐานอย่าง text editor หรือ chat app ก็ยังใช้เวลาหลายวินาที — ส่วนต่างของความเร็วถูก “กิน” ไปโดย layer ที่เพิ่มขึ้นตลอดทาง
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- วิวัฒนาการของ Windows — ความต้องการฮาร์ดแวร์ขั้นต่ำของ Windows เพิ่มขึ้นแบบก้าวกระโดดทุกเจเนอเรชัน จาก Windows 95 ที่ต้องการเพียง CPU 25 MHz และ RAM 4 MB ไปจนถึง Windows 11 ที่ต้องการ CPU 1 GHz แบบ 64-bit dual-core และ RAM อย่างน้อย 4 GB — ทั้งที่งานพื้นฐานที่ผู้ใช้ทำ (พิมพ์เอกสาร, เปิดเว็บ, ฟังเพลง) ไม่ได้ซับซ้อนขึ้นในสัดส่วนเดียวกันเลย
- iTunes — เริ่มต้นเป็นแค่โปรแกรมเล่นเพลง แต่ค่อย ๆ ถูกเสริมด้วยระบบร้านค้า, sync อุปกรณ์, podcast, และ feature โฆษณา จนกลายเป็น platform e-commerce ขนาดใหญ่ที่กินทรัพยากรมากกว่าหน้าที่หลักของมันหลายเท่า
- WeChat — จาก app แชทขนาดเพียง 2 MB ในยุคแรก ขยายกลายเป็น “super-app” ขนาดกว่า 750 MB ที่รวมทั้งระบบชำระเงิน เกม มินิโปรแกรม และบริการอื่น ๆ นับร้อย
- เบราว์เซอร์สมัยใหม่ — หน้าต่างเบราว์เซอร์เดียวในปัจจุบันอาจใช้ RAM หลักร้อย MB ต่อแท็บ ซึ่งใกล้เคียงหรือมากกว่าพื้นที่หน่วยความจำทั้งระบบของ Oberon System (1987) ที่ทำงานได้ครบเป็น OS สมบูรณ์แบบทั้งเครื่อง
- Facebook Messenger ในปี 2016 ยอมรับตรง ๆ ว่า app บวมเกินไปหลังจากเพิ่มเกม บอต และ feature แบบ Snapchat เข้ามาเรื่อย ๆ จนต้องประกาศแผน “ลดน้ำหนัก” app ในเวลาต่อมา
ตัวอย่างเหล่านี้ล้วนสะท้อนรูปแบบเดียวกัน คือ hardware headroom ที่ควรทำให้ผู้ใช้ได้ประสบการณ์ที่เร็วขึ้น กลับถูกใช้ไปกับ feature ที่สะสมพอกพูนขึ้นทีละน้อยจนแทบไม่เหลือส่วนต่างให้ผู้ใช้สัมผัสได้
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- อย่าสร้างสิ่งที่ยังไม่ต้องการ — ยึดหลัก YAGNI อย่างจริงจัง ทุก feature ที่เพิ่มเข้าไปคือ surface area ที่ต้องดูแล ทดสอบ และมันมักจะแบก dependency, abstraction layer และ configuration ตามมาด้วยเสมอ แม้จะยังไม่มีใครใช้งานจริง
- เรียบง่ายไว้ก่อนเสมอ — Keep It Simple ไม่ใช่แค่คำขวัญสวยหรู แต่เป็นวินัยที่ต้องเลือกใช้อย่างตั้งใจ เพราะความซับซ้อนสะสมทีละนิดโดยไม่มีใครตัดสินใจ “เพิ่มความซับซ้อน” อย่างชัดเจนสักครั้งเดียว — มันคืบคลานเข้ามาทีละ commit
- ระวัง feature creep — feature ที่ขอเพิ่มทีละอย่างดูเหมือนไม่มีอะไรมาก แต่สะสมไปเรื่อย ๆ จนกลายเป็นภาระ ทีมควรมีกระบวนการทบทวนและ “ตัดทิ้ง” feature ที่ไม่คุ้มค่าเป็นระยะ ไม่ใช่แค่เพิ่มอย่างเดียว
- วัดประสิทธิภาพจริง อย่าพึ่งแต่ฮาร์ดแวร์ที่แรงขึ้น — อย่าปล่อยให้ hardware upgrade กลบปัญหาด้าน performance ของ code ไว้ ทีมที่ดีควรตั้ง budget ด้าน memory/CPU/startup time ให้ระบบ และเฝ้าระวังไม่ให้มันไหลลื่นขึ้นเรื่อย ๆ โดยไม่มีใครสังเกต
- ทีมใหญ่ไม่ได้แปลว่าดีกว่า — ปรากฏการณ์เดียวกับ software bloat เกิดกับองค์กรได้เหมือนกัน ทีมวิศวกรที่ขยายใหญ่โตเกินจำเป็นมักเคลื่อนตัวช้าลงและสร้างความซับซ้อนเชิงกระบวนการโดยไม่จำเป็น เหมือนที่ Wirth เคยเตือนว่าระบบซับซ้อนไม่จำเป็นต้องอาศัยกองทัพนักออกแบบและโปรแกรมเมอร์เสมอไป
- ทบทวนเป็นระยะว่าอะไรคือ “จำเป็น” จริง ๆ — เมื่อทีมเติบโต feature ก็มักสะสมโดยไม่มีใครกล้าตัด การจัดสรรเวลาให้ทีม refactor และตัดสิ่งที่ไม่จำเป็นออกเป็นระยะ คือวิธีต้านทาน Wirth’s Law ในระยะยาว