ความหมดศรัทธาต่อซอฟต์แวร์

 (tonsky.me)
5 คะแนน โดย GN⁺ 2023-10-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอฟต์แวร์สมัยใหม่แทนที่จะตอบแทนความก้าวหน้าของฮาร์ดแวร์ด้วย ประสิทธิภาพ·ความเรียบง่าย·ความสมบูรณ์ กลับทำให้ความไร้ประสิทธิภาพกลายเป็นเรื่องปกติ โดยอาศัยสมมติฐานว่า “คอมพิวเตอร์เร็วพออยู่แล้ว”
  • แม้แต่งาน พื้นฐาน อย่างการเลื่อนหน้าเว็บ, การเปิดอีเมลใน Google Inbox ที่ใช้เวลา 13 วินาที, การอัปเดต Windows 10 ที่ใช้เวลา 30 นาที, หรืออาการหน่วงตอนพิมพ์ในโปรแกรมแก้ไขข้อความ ก็ยังรู้สึกช้ากว่าที่ควรจะเป็น
  • ระบบ Android 6GB, Windows 10 4GB, Google Keyboard 150MB รวมถึงกรณีของแอป Electron และ Slack แสดงให้เห็นว่าการ พองตัว ของแอปและแพลตฟอร์มนำไปสู่ต้นทุนด้านประสิทธิภาพ ความซับซ้อน และความน่าเชื่อถือ
  • เช่นเดียวกับการอัปเดต OS·แอป·เบราว์เซอร์ และการยุติรองรับแอป 32 บิตใน iOS 11 ซอฟต์แวร์ที่เคยทำงานได้ดีในอดีตก็อาจช้าลงหรือพังไปตามกาลเวลา
  • หากต้องการสร้างซอฟต์แวร์ที่ดีกว่าเดิม วิศวกรต้องเข้าใจ ประสิทธิภาพ·โครงสร้าง·ข้อจำกัด ของระบบที่ตนสร้าง และต้องทำให้ได้ผลลัพธ์ที่เร็วและคาดการณ์ได้ด้วยทรัพยากรที่น้อยลง

ซอฟต์แวร์ที่สิ้นเปลืองประสิทธิภาพ

  • ซอฟต์แวร์สมัยใหม่มักถูกยอมรับได้ แม้จะทำงานด้วยเพียง 1% หรือ 0.01% ของประสิทธิภาพที่เป็นไปได้
  • ในขณะที่รถยนต์ อาคาร และเครื่องบินค่อย ๆ เข้าใกล้ขีดจำกัดทางกายภาพหรือรูปแบบที่เหมาะสมที่สุด ซอฟต์แวร์กลับใช้คำว่า “คอมพิวเตอร์เร็วพออยู่แล้ว” มาอ้างความชอบธรรมให้กับความไร้ประสิทธิภาพ
  • คำกล่าวที่ว่า “เวลาของโปรแกรมเมอร์แพงกว่าเวลาของคอมพิวเตอร์” อาจกลบความจริงที่ว่าเวลาของคอมพิวเตอร์กำลังถูกใช้เปลืองอย่างไม่เคยเป็นมาก่อน
  • มีการยกทวีตตัวอย่างว่า แม้จะเขียนโปรแกรม Python ที่รันทุกวันใหม่ด้วย Rust แล้วลดเวลาจาก 1.5 วินาทีเหลือ 0.06 วินาที แต่กว่าจะชดเชยเวลา 6 ชั่วโมงที่ใช้พัฒนาได้ก็ต้องรอกว่า 41 ปี ซึ่งกลายเป็นกรณีตัวแทนของการถกเรื่องประสิทธิภาพ

ประสบการณ์พื้นฐานที่ช้าจนทนไม่ได้

  • คอมพิวเตอร์พกพารุ่นใหม่มีพลังมากกว่าคอมพิวเตอร์ยุคลงจอดบนดวงจันทร์หลายพันเท่า แต่แม้แต่บน MacBook Pro รุ่นใหม่ก็ยังยากที่จะเลื่อนหน้าเว็บให้ลื่นที่ 60fps
  • Inbox ที่สร้างโดย Google ใช้เวลาถึง 13 วินาที ในการเปิดอีเมลหนึ่งฉบับบน Google Chrome
    • วิธีที่แอนิเมชันกล่องสีขาวเปล่าแทนเนื้อหาจริงนั้น ดูจะเป็นการประนีประนอมให้เข้ากับขีดจำกัดด้านประสิทธิภาพของเว็บเพจมากกว่า
    • แม้ในยุคที่จอ 120Hz กลายเป็นกระแสหลัก ก็ยังมองว่าแม้แต่การแสดงคำตอบหนึ่งรายการในคอมมูนิตี้บนเว็บก็ยังรักษา 60Hz ให้เสถียรไม่ได้
  • การอัปเดต Windows 10 ใช้เวลา 30 นาที และในเวลานั้นสามารถฟอร์แมต SSD ดาวน์โหลดบิลด์ใหม่ และติดตั้งซ้ำได้หลายรอบเสียด้วยซ้ำ
  • โปรแกรมแก้ไขข้อความสมัยใหม่มีอาการหน่วงตอนพิมพ์มากกว่า Emacs ที่มีอายุ 42 ปี
    • มีการชี้ว่าแม้แต่งานที่ต้องอัปเดตเพียงสี่เหลี่ยมเล็ก ๆ ทุกครั้งที่กดคีย์ ก็ยังทำไม่ทันภายใน 16ms
    • ขณะที่เกม 3D ต้องเรนเดอร์ทั้งหน้าจอ จัดการอินพุต คำนวณโลก และบริหารทรัพยากรทั้งหมดภายใน 16ms เดียวกัน
  • ฮาร์ดแวร์ที่เร็วขึ้นจึงไม่ได้ถูกใช้เพื่อรันซอฟต์แวร์ที่ดีขึ้น แต่กลับถูกใช้เพื่อรันซอฟต์แวร์ที่ทำสิ่งเดิมได้ช้าลง

แอปและแพลตฟอร์มที่พองตัว

  • เว็บแอปสามารถเร็วขึ้นได้ถึง 10 เท่า เพียงแค่บล็อกโฆษณา และ AMP ก็ใกล้เคียงกับการตัดส่วนที่พองเกินจำเป็นออกมากกว่าจะเป็นเทคโนโลยีใหม่จริง ๆ
  • ระบบ Android มีขนาด 6GB แม้ไม่มีแอปใด ๆ, Windows 95 มี 30MB และ Windows 10 มี 4GB
    • มองว่า Windows 10 มีขนาดใหญ่กว่า Windows 95 ถึง 133 เท่า แต่ความสามารถพื้นฐานไม่ได้ต่างกันมากนัก
    • และ Android ยังใหญ่กว่า Windows 10 อีก 1.5 เท่า
  • Google Keyboard มักใช้พื้นที่ 150MB, แอป Google ใช้ 350MB, และ Google Play Services ใช้ 300MB
    • มีการวิจารณ์ด้วยการตั้งคำถามว่า Google Keyboard ซึ่งเป็นเพียงแอปที่วาดปุ่มราวสามสิบปุ่มบนหน้าจอ ซับซ้อนกว่า Windows 95 ทั้งระบบถึง 5 เท่าจริงหรือ
    • Google Play Services ลบออกไม่ได้แม้จะไม่ได้ใช้งาน
  • สถานการณ์ที่หลังติดตั้งแอปพื้นฐานแล้วเหลือพื้นที่เก็บรูปเพียงประมาณ 1GB นั้น ตัดกับยุคที่ OS·แอป·ข้อมูลทั้งหมดต้องเก็บลงในฟลอปปีดิสก์อย่างชัดเจน
  • แอป Todo ที่สร้างบน Electron อาจบรรจุแม้กระทั่งไดรเวอร์คอนโทรลเลอร์ Xbox 360, การเรนเดอร์กราฟิก 3D, การเล่นเพลง และความสามารถในการถ่ายภาพด้วยเว็บแคม
  • Slack แม้จะเป็นแอปที่ใกล้เคียงกับแชตและโปรแกรมแก้ไขข้อความแบบง่าย ๆ แต่ก็ยังถูกจัดเป็นแอปหนักเพราะความเร็วในการโหลดและการใช้หน่วยความจำ
  • ยิ่งแอปใหญ่ขึ้น การสูญเสียการควบคุม ต้นทุนความซับซ้อน การสูญเสียประสิทธิภาพ และหนี้ด้านความน่าเชื่อถือก็ยิ่งเพิ่มขึ้น และเราไม่ควรยอมรับ แอปที่หนักเกินเหตุ ว่าเป็นเรื่องปกติ

ซอฟต์แวร์ที่เสื่อมสภาพไปตามเวลา

  • เมื่อ 3 ปีก่อน โทรศัพท์ Android 16GB ก็ยังเพียงพอ แต่พอถึงยุค Android 8.1 แอปต่าง ๆ กลับโตเป็นสองเท่าโดยไม่มีเหตุผลชัดเจน จนใช้งานได้ลำบาก
  • iPhone 4s เปิดตัวพร้อม iOS 5 แต่การรัน iOS 9 กลับเป็นภาระหนัก และก็ไม่ได้หมายความว่า iOS 9 จะยอดเยี่ยมกว่าจนเป็นคนละระดับ
  • iOS 11 ยุติการรองรับ แอป 32 บิต ทำให้แอปที่ไม่มีนักพัฒนาแล้วหรือไม่ได้อัปเดตอาจหายไปและไม่สามารถใช้งานได้อีก
  • มีการอ้างทวีตว่า โปรแกรม DOS ยังรันได้บนคอมพิวเตอร์หลายรุ่นตั้งแต่ทศวรรษ 1980 โดยไม่ต้องแก้ไข แต่แอป JavaScript อาจพังได้แม้แต่กับการอัปเดต Chrome ครั้งถัดไป
  • แม้แต่เว็บเพจที่วันนี้ยังใช้งานได้ดี ภายใน 10 ปีก็อาจไม่สามารถทำงานได้ถูกต้องบนเบราว์เซอร์ใดเลย
  • เราซื้อโทรศัพท์ใหม่และ MacBook ใหม่เพื่อทำสิ่งเดิม แต่สุดท้ายก็เพียงเพื่อรันแอปเดิมให้ช้าลงอีกครั้ง

ความคาดหวังด้านคุณภาพที่ลดต่ำลง

  • เมื่อเว็บเพจมีปัญหา มันมักไม่ได้ขอให้ตรวจหาสาเหตุ แต่บอกให้กดรีเฟรชแทน
  • เว็บแอปสามารถปล่อยข้อผิดพลาด JavaScript แบบ “สุ่ม” ออกมาได้ แม้อยู่บนเบราว์เซอร์ที่รองรับก็ตาม
  • มีการวิจารณ์ว่าการออกแบบเว็บเพจและฐานข้อมูล SQL ตั้งอยู่บนความหวังว่าข้อมูลจะไม่เปลี่ยนระหว่างที่ผู้ใช้กำลังดูหน้าเว็บที่เรนเดอร์แล้ว
  • ฟังก์ชันทำงานร่วมกันก็มักอยู่เพียงระดับ “พยายามให้ดีที่สุด” และมีสถานการณ์ปกติที่อาจทำให้ข้อมูลสูญหายได้
    • ไดอะล็อกอย่าง “จะเก็บเวอร์ชันไหนไว้?” แทบจะหมายถึงการให้เลือกว่าจะทำลายชิ้นงานไหนมากกว่า
  • Linux แม้จะมีการออกแบบที่สามารถฆ่าโปรเซสแบบตามอำเภอใจได้ ก็ยังเป็นระบบปฏิบัติการที่ได้รับความนิยมที่สุดบนเซิร์ฟเวอร์
  • กรณีของจอ Dell, AirDrop และ Bluetooth แสดงให้เห็นว่าซอฟต์แวร์ในอุปกรณ์และสเปกที่ซับซ้อนสร้างประสบการณ์ที่ต้องพึ่งการรีเซ็ตเป็นระยะหรืออาศัยดวง
  • หากต้องการส่งมอบสิ่งที่ทำงานได้อย่างเสถียร เราต้องเข้าใจสิ่งที่สร้างทั้งภายในและภายนอก แต่กับระบบที่พองตัวเกินไป เรื่องนั้นกลับทำได้ยาก

ความสับสนของเครื่องมือเขียนโปรแกรมและแนวปฏิบัติการพัฒนา

  • แม้แต่ในองค์ประกอบพื้นฐานอย่างการจัดการแพ็กเกจ ระบบบิลด์ คอมไพเลอร์ การออกแบบภาษา และ IDE ก็ยังยากจะเห็นความสมบูรณ์ที่ทั้งเร็ว มีประสิทธิภาพ และอยู่ได้นาน
  • ระบบบิลด์แม้จะมีข้อมูลการเปลี่ยนแปลงทั้งหมดอยู่แล้ว ก็ยังมักเรียกร้องให้ล้างทุกอย่างแล้วทำใหม่เป็นระยะ
    • มองว่าไม่มีเหตุผลเลยที่จะทำให้มันไม่น่าเชื่อถือ คาดการณ์ไม่ได้ และทำซ้ำไม่ได้
    • มีการบรรยายว่า NPM อยู่ในสภาพ “บางทีก็ทำงาน” มานานหลายปี
    • พร้อมอ้างทวีตว่า rm -rf node_modules ดูเหมือนจะเป็นสิ่งที่หลีกเลี่ยงไม่ได้ในงานพัฒนา Node.js/JavaScript
  • ความจริงที่ว่าคอมไพเลอร์และงานก่อน-หลังการประมวลผลใช้เวลาหลายนาทีหรือหลายชั่วโมงแต่ยังถูกยอมรับได้ ขัดกับคำพูดที่ว่า “เวลาของโปรแกรมเมอร์มีค่า”
  • กรณีที่ยังเลือกใช้ Hadoop ทั้งที่ช้ากว่าการรันบนพีซีเครื่องเดียว แสดงให้เห็นว่าโปรแกรมเมอร์ไม่ได้ตัดสินใจอย่างมีเหตุผลเสมอไป
  • มีการวิจารณ์ว่าแมชชีนเลิร์นนิงและ “ปัญญาประดิษฐ์” ได้พาซอฟต์แวร์เข้าสู่ยุคแห่งการเดาสุ่มที่ไม่น่าเชื่อถือ
    • พร้อมอ้างทวีตที่บอกว่า เมื่อเห็นคำว่า “ปัญญาประดิษฐ์” หรือ “แมชชีนเลิร์นนิง” ในแอปหรือบริการ จะตีความได้เลยว่ามันไม่น่าเชื่อถือ คาดเดาไม่ได้ และอธิบายผลลัพธ์ได้ยาก
  • วิธีการรัน VM บน Linux แล้วใส่ Docker ซ้อนใน VM ถูกมองว่าเป็นสัญญาณว่าเราไม่รู้วิธีจัดการโปรแกรม·ภาษา·สภาพแวดล้อมรันไทม์ให้เรียบร้อยจริง ๆ
    • ความจริงที่ว่า ไฟล์รันเดี่ยว ของ Go ถูกยกเป็นข้อดีหลัก สะท้อนสถานการณ์ที่แค่ไม่เละเทะก็ถือว่าประสบความสำเร็จแล้ว
  • การพึ่งพา dependency มักเข้ามาพร้อมต้นทุนการนำไปใช้และ dependency ตัวใหม่ ๆ เพราะพยายามแก้ปัญหาง่าย ๆ ด้วย “โซลูชันแพ็กเกจครบชุด”
  • มีการชี้ว่าการใช้โปรแกรมโดยไม่รีสตาร์ตติดต่อกันหลายปีนั้นยาก และบางครั้งแม้แต่ไม่กี่วันก็ยังยาก
    • การรีสตาร์ตโปรเซส, รีบูตฐานข้อมูล, watchdog ที่รีสตาร์ตแอปทุก 20 นาที, การใส่ทรัพยากรซ้ำซ้อน และการส่งข้อมูลแบบบีบอัด ล้วนเป็นวิธีข้ามปัญหาไปเร็ว ๆ แทนที่จะแก้ไขมัน
  • แนวปฏิบัติเหล่านี้ไม่ใช่วิศวกรรม แต่คือ การเขียนโปรแกรมแบบขี้เกียจ และวิศวกรรมคือการเข้าใจประสิทธิภาพ โครงสร้าง และข้อจำกัดของสิ่งที่เราสร้างอย่างลึกซึ้ง

ความซับซ้อนที่ทับถมและความไม่ใส่ใจของตลาด

  • ซอฟต์แวร์ปัจจุบันอยู่ในสภาพที่โค้ดซึ่งพอทำงานได้ถูกกองทับด้วยโค้ดที่พอทำงานได้อีกชั้น และมันก็ยังคงใหญ่ขึ้น ซับซ้อนขึ้น จนโอกาสจะเปลี่ยนแปลงยิ่งน้อยลง
  • ระบบนิเวศที่ดีควรมีช่วงที่ต้องถอยหลังเพื่อเดินหน้าต่อได้บ้าง แต่มีการชี้ว่าเราไม่เห็นเคอร์เนล OS ใหม่มา 25 ปีแล้ว และตอนนี้มันก็ซับซ้อนเกินกว่าจะเขียนใหม่ได้
  • เบราว์เซอร์เองก็เขียนเอนจินเลย์เอาต์ใหม่จากศูนย์ได้ยาก เพราะเต็มไปด้วย edge case และปัญหาทางประวัติศาสตร์
  • ความก้าวหน้าในทุกวันนี้ดูเหมือนการเติมเชื้อไฟลงกองไฟ เช่น เอา microservices มาแก้ปัญหา monolith, เอา Docker มาแก้ปัญหา microservices, แล้วเอา Kubernetes มาแก้ปัญหา Docker อีกที
  • มีการอ้างทวีตว่า เราเปลี่ยนจากการตั้งค่าแบบประกาศด้วย XML ไปเป็นการตั้งค่า microservices ด้วย YAML แต่ XML ในอดีตอย่างน้อยก็ยังมี schema
  • ผู้ใช้แทบไม่มีทางเลือกนอกจากยอมรับสิ่งที่วิศวกรส่งมาให้ ไม่ว่าจะเป็นแอป Android ขนาด 350MB, การเลื่อนหน้าจอที่กระตุก, หรือคำแนะนำว่า “ถ้าไม่ทำงานก็รีบูต”
  • หากผลิตภัณฑ์คู่แข่งทั้งหมดก็ช้า ใหญ่ และคุณภาพต่ำเหมือนกัน ก็ยากที่จะเกิดแรงกดดันจากการแข่งขัน
    • แม้บางครั้งจะมีผลิตภัณฑ์ที่สร้างแรงกดดันได้ เช่น iPhone/iOS เทียบกับสมาร์ตโฟนอื่น หรือ Chrome เทียบกับเบราว์เซอร์อื่น แต่ก็มักอยู่ได้ไม่นาน
  • ภารกิจของวิศวกรควรเป็นการแสดงให้เห็นว่า ด้วยคอมพิวเตอร์ยุคใหม่แล้ว อะไรบ้างที่เป็นไปได้ในด้านประสิทธิภาพ ความน่าเชื่อถือ คุณภาพ และความพร้อมใช้งาน

แต่ก็ยังมีทางเลือกให้เห็น

  • LMAX Disruptor, SBE, Aeron ของ Martin Thompson ถูกยกเป็นตัวอย่างที่น่าประทับใจ เรียบง่าย และมีประสิทธิภาพ
  • Xi editor ของ Raph Levien ถูกประเมินว่าเป็นงานที่สร้างขึ้นโดยยึดหลักการที่ถูกต้อง
  • Jonathan Blow สร้างภาษาขึ้นมาใช้กับเกมของตัวเอง และบนโน้ตบุ๊กของเขาสามารถคอมไพล์ใหม่ทั้งหมดของโค้ด 500,000 บรรทัด ได้ในเวลา 1 วินาที
    • นี่คือผลลัพธ์ของการคอมไพล์ใหม่ทั้งหมด ไม่ใช่ incremental build และไม่ใช่แคชระหว่างทาง
  • มองว่าการเขียนโปรแกรมให้เร็วไม่ได้ต้องใช้ความเป็นอัจฉริยะหรือเวทมนตร์อะไร เพียงแค่ไม่สร้างมันบนกองขยะขนาดมหึมาของ toolchain ที่กำลังเป็นกระแส

ข้อเรียกร้องเพื่อซอฟต์แวร์ที่ดีกว่า

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

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
xguru 2023-10-24

บทความนี้มีฉบับแปลภาษาเกาหลีออกมาก่อนแล้ว ดังนั้นไปอ่านฉบับนั้นได้เลย.

https://tonsky.me/blog/disenchantment/ko/

ผมได้เปลี่ยนเป็นลิงก์ฉบับแปลไว้แล้ว.
 
GN⁺ 2023-10-24
ความคิดเห็นจาก Hacker News

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

    • Kagi ไม่ได้รับเงินลงทุนจาก VC แต่ถึงอย่างนั้นก็ยังมีโค้ดที่ไม่เหมาะที่สุด บั๊กจำนวนมาก และปัญหาประสิทธิภาพแปลก ๆ อยู่หลายจุด จากมุมของคนที่รู้เรื่องการพัฒนาซอฟต์แวร์ มองว่านี่เป็นเรื่องที่หลีกเลี่ยงได้ยาก ไม่ว่าจะมาจากแหล่งเงินแบบไหนหรือบริษัทใหญ่แค่ไหน และเป็นฟังก์ชันของความซับซ้อนของซอฟต์แวร์ ทรัพยากรที่มี และแรงจูงใจ
      อย่างไรก็ตาม สิ่งที่ทำได้ง่ายกว่าบริษัทที่รับเงิน VC คือการจัดสรรเวลาให้กับ การรีแฟกเตอร์และการจัดการหนี้ทางเทคนิค จริง ๆ แล้วตอนนี้กำลังเหยียบเบรกการพัฒนาฟีเจอร์ใหม่เป็นเวลา 45 วัน เพื่อจัดการปัญหาทางเทคนิคหลัก ๆ อยู่ ถ้าคาดว่าจะถูกซื้อกิจการในปีหน้า ก็คงลงทุนแบบนี้ได้ยาก และหนี้ทางเทคนิคก็จะกลายเป็นปัญหาของคนอื่น
      ตราบใดที่ผลิตภัณฑ์ยังถูกพัฒนาต่อไป บั๊กและปัญหาใหม่ ๆ ก็จะเกิดขึ้นเรื่อย ๆ “โค้ดที่สมบูรณ์แบบ” เป็นไปได้เฉพาะในบริบทปิดที่ไม่มีการเพิ่มฟีเจอร์ใหม่อีกแล้วเท่านั้น
    • ประโยคที่ว่า “มันไม่มีเงินอยู่ตรงนั้น จริง ๆ แล้วตรงกันข้าม” สมควรถูกพูดซ้ำ นี่คือโรคที่กลืนกินซอฟต์แวร์ และกำลังทำให้ซอฟต์แวร์ยุคใหม่กลายเป็นเวอร์ชันที่แย่ที่สุดเท่าที่เป็นไปได้
      ผมมองว่า โมเดลการลงทุนแบบ VC คือสิ่งที่ผลักอุตสาหกรรมมาถึงจุดนี้ สตาร์ทอัพรับเงินหลายล้านดอลลาร์ แล้วต้องทำเงินให้เร็วพอที่จะคืนให้ผู้ลงทุน ดังนั้นจึงต้องรีดเงินจากแอปให้เร็วที่สุดเท่าที่ทำได้ งานที่ไม่มีตัวชี้วัด ROI ติดอยู่จะไม่ได้รับความสนใจจากใครเลย
    • ผมไม่คิดว่าซอฟต์แวร์สมัยก่อนปลอดภัยกว่า เพียงแต่ผู้ใช้คอมพิวเตอร์ไร้เดียงสาและเชื่อใจมากกว่าเท่านั้น เมื่อมีเครื่องจำนวนมากขึ้นเชื่อมต่อเข้ากับเครือข่าย เราก็ได้เรียนรู้อะไรมากมาย
      โดยพื้นฐานแล้วมันเคยมีการเปิดให้เข้าถึงได้โดยตรง ไม่มีรหัสผ่านหรือใช้รหัสผ่านสั้น ๆ การจัดเก็บรหัสผ่านที่ไม่ปลอดภัย ทุกอย่างเป็นข้อความล้วน การไม่สนใจการทำความสะอาดอินพุต และสิ่งอย่าง telnet
      อีกเหตุผลหนึ่งที่ซอฟต์แวร์บวมขึ้นก็อยู่ตรงนี้ เราเริ่มมองเห็นปฏิสัมพันธ์และความเสี่ยง และเมื่อเห็นแล้วก็ทำเป็นไม่เห็นไม่ได้ เงื่อนไขขอบเขต ที่ต้องจัดการไม่ได้ลดลง แต่เพิ่มขึ้น และฮาร์ดแวร์ที่ต้องรองรับก็มีมากขึ้นด้วย
      กระบวนการเขียนโค้ดที่มีประสิทธิภาพดีสามารถปรับปรุงได้ แต่ในขณะเดียวกัน baseline ก็กำลังสูงขึ้นเร็วกว่าความเร็วที่เราไปถึงเสียอีก สิ่งที่น่าสนใจก็คือตอนนี้เรากำลังค่อย ๆ กลับไปในทิศทางที่ไม่ต้องใช้รหัสผ่านอีกครั้ง
    • เห็นด้วยว่าแรงจูงใจไม่สอดคล้องกัน มีอุตสาหกรรมบางแขนงที่ประสิทธิภาพและความถูกต้องมีมูลค่าจริง ถ้าให้ความสำคัญกับ งานฝีมือด้านซอฟต์แวร์ เหมือนผู้เขียน การย้ายไปทำในสาขาเหล่านั้นคือวิธีที่ดีที่สุดในการสนุกกับงาน
    • พูดง่าย ๆ คือเราไม่ได้ปล่อยโค้ดออกไป แต่ปล่อย ฟีเจอร์ ออกไป ไม่ได้ปล่อย automatic dependency injection, abstraction ที่สง่างาม หรือทริกคอมไพเลอร์เจ๋ง ๆ แต่ปล่อยฟีเจอร์ใหม่ที่ลูกค้ายอมจ่ายเงิน
      test coverage ระดับ unit test ที่สูงจนทำให้การรีแฟกเตอร์เจ็บปวด มักขัดขวางการปล่อยฟีเจอร์ และผมคิดว่ามันเกิดขึ้นบ่อยกว่าที่พวกคลั่งไคล้ test-driven development อยากยอมรับมาก “แนวปฏิบัติที่ดีที่สุด” จำนวนมากในวงการนั้นใกล้เคียงกับหลักคำสอนที่ไม่สมจริง ซึ่งสร้างโดยคนที่อยู่ในบริษัทที่หา product-market fit เจอแล้วและเงินไหลเข้ามาเอง

  • ยังมี HP MS200 all-in-one ที่พอใช้งานได้แบบเฉียดฉิวอยู่เครื่องหนึ่ง ซื้อถูก ๆ จาก garage sale เมื่อปี 2017 และถ้าลง Linux หลังจาก Chrome โหลดเสร็จแล้ว ก็ยังสามารถวิดีโอคอล Skype เวอร์ชันเว็บแบบเต็มหน้าจอ หรือดู YouTube เต็มหน้าจอได้
    ล่าสุดได้เครื่องนี้กลับมาและก่อนจะทำเป็นคอมพิวเตอร์ให้เด็ก ๆ ใช้ ก็ลองติดตั้ง FC38 กับ Chrome รุ่นล่าสุด ปรากฏว่าวิดีโอ YouTube กลายเป็นสไลด์โชว์ ปรับตั้งค่าเท่าไรก็ไม่ได้ผล จึงเพิ่ม RAM จาก 2GB เป็น 3GB แล้วมันก็กลับมาเล่น 720p เต็มหน้าจอได้ระดับเดียวกับเมื่อ 6 ปีก่อน
    แปลว่าการทำสิ่งเดิมต้องใช้หน่วยความจำเพิ่มขึ้น 1.5 เท่า หรือเพิ่มอีก 1GB ผมก็เข้าใจคำพูดที่ว่า 16GB คือขั้นต่ำ แต่แม้บนเครื่องห่วย ๆ เครื่องนี้ Chrome ซึ่งแทบจะเป็นเว็บเบราว์เซอร์ที่อยู่เฉย ๆ ยังแสดง memory footprint ประมาณ 30GB ส่วนใหญ่น่าจะเป็นไฟล์ที่ mmap ไว้ แต่ถึงอย่างไรก็คือ 30GB

    • YouTube เป็นตัวอย่างที่ดีในการแสดงความแตกต่างด้านประสิทธิภาพ คุณภาพวิดีโอดีขึ้นเพราะ codec รุ่นใหม่ แต่เครื่องเก่าหรือเครื่องราคาถูกไม่มี GPU รุ่นใหม่ จึงต้อง decode ด้วยซอฟต์แวร์ และบางครั้งก็ประมวลผลด้วย JavaScript ซึ่งสิ้นเปลืองมาก แต่ทำงานได้บนทุกเครื่อง
      ในทางกลับกัน สำหรับอุปกรณ์ส่วนใหญ่ อายุแบตเตอรี่ที่เพิ่มขึ้น อุณหภูมิที่ต่ำลง และความต้องการ RAM/ดิสก์ที่น้อยลง ถือเป็นการปรับปรุงที่ชัดเจน YouTube อาจเก็บไฟล์ encoding แบบเก่าไว้ซ้ำบนเซิร์ฟเวอร์ก็ได้ แต่ในสถานการณ์ที่ผู้ใช้ส่วนใหญ่เข้าจากอุปกรณ์รุ่นใหม่ นั่นก็กลายเป็นการเปลืองพื้นที่
      การใช้ RAM ที่เพิ่มขึ้นส่วนใหญ่ของ Chrome มาจากพัฒนาการของ สถาปัตยกรรม sandbox หน่วยความจำที่ใช้ร่วมกันและพื้นที่โปรเซสอาจถูกใช้ในการโจมตีเพื่อหลุดจาก sandbox ได้ จึงมีการเพิ่มการแยกกั้นมากขึ้น และการที่ Chrome เปิดโปรเซสอิสระใหม่สำหรับแต่ละแท็บและ extension ก็เป็นสาเหตุใหญ่เช่นกัน
      ทุกวันนี้ ad blocker ก็มีผลมากเช่นกัน เมื่อเว็บแย่ลง ad blocker ที่มีประสิทธิภาพก็สร้างได้ยากขึ้นและต้องใช้ทรัพยากรมากขึ้น ซอฟต์แวร์ที่ช้าไม่ได้ช้าลงเพียงเพื่อกวนใจคน แต่บ่อยครั้งเป็นผลจากการเปลี่ยนแฮ็กที่อันตรายให้กลายเป็น implementation ที่ดี และจาก requirement ที่เปลี่ยนไป FLV ไม่เพียงพออีกต่อไป และ h264 เองก็ดูไม่น่าจะยืนระยะได้นานในอีก 5 ปีข้างหน้าเมื่อ h265 และ AV1 แพร่หลายขึ้น
    • เว็บเบราว์เซอร์กลายเป็นระบบปฏิบัติการของตัวเองไปแล้วโดยพฤตินัย “เว็บสมัยใหม่” มีฟีเจอร์มากเกินไป และบ่อยครั้งฟีเจอร์เดียวกันก็ถูก implement ด้วยวิธีแข่งขันกันห้าหกแบบ แม้บนฮาร์ดแวร์สมัยใหม่ แค่ การเรนเดอร์ข้อความ ก็อาจเป็นภาระหนักได้
      toolchain สมัยใหม่มุ่งเน้นที่ “อย่าสร้างล้อขึ้นมาใหม่” แต่ถ้า dependency แต่ละตัวเลือกล้อคนละเวอร์ชันกัน แค่ดึง dependency มาไม่กี่ตัว ก็อาจมี implementation ของฟังก์ชันระดับต่ำเดียวกันเข้ามาทีละ 6 แบบ
    • ทุกครั้งที่ติดตั้ง Linux ใหม่ ผมจะลองให้โอกาส UI เริ่มต้น แต่สุดท้ายก็มักกลับไปใช้ MATE อย่างไรก็ตาม บนเครื่องเก่าเครื่องนี้ Gnome Shell ตอบสนองได้ค่อนข้างชัดเจน มี app store และมี Chrome ด้วย
      แต่สิ่งที่ติดตั้งเป็น Flatpak และรู้สึกได้ถึงความบวม โชคดีที่ Chrome ยังติดตั้งแบบ native โดยตรงเป็น RPM ได้ และใช้ shared library ของ OS จริง ๆ
    • จำได้ว่าสมัยหนึ่งการรันเว็บเบราว์เซอร์แบบกราฟิกบน Linux/X11 ต้องใช้ 8MB น่าจะเป็น Netscape Navigator และ 8MB ก็เพียงพอแล้ว ส่วน 16MB จะสบายขึ้นอีกหน่อย

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

    • ด้านหนึ่งก็แทบไม่น่าเชื่อว่าสิ่งที่มีอยู่ตอนนี้ทำงานได้ดีขนาดนี้ ทุกชั้นดูเหมือนถูกยึดไว้ด้วยเทปกาวกับหมากฝรั่ง แต่ก็ใช้งานได้จริง สิ่งที่มนุษยชาติทำสำเร็จทำให้ทึ่งได้ทุกวัน
      อีกด้านหนึ่ง ก็ยังเห็นอยู่เรื่อย ๆ ว่าทุกอย่างเต็มไปด้วยบั๊กแค่ไหน และไม่รู้ว่าจริง ๆ แล้วมันมีบั๊กมากขึ้น หรือเป็นเพราะพออายุมากขึ้นและรู้เรื่องเบื้องหลังมากขึ้น ความอดทนต่อการพัฒนาซอฟต์แวร์แบบบริษัทใหญ่ก็ลดลงกันแน่ หงุดหงิดกับ product manager ในจินตนาการที่สั่งว่า “ปล่อยฟีเจอร์ X เดี๋ยวนี้” ทั้งที่บั๊ก UX ชัด ๆ จับได้ง่ายมาก
    • หลังจากดูการบรรยาย “จุดจบของโลก” ของ Jonathan Blow แล้วลองใส่ใจดู ก็พบว่ามี ประสบการณ์ซอฟต์แวร์ห่วย ๆ ที่เรายอมรับและอยู่กับมันทุกวันมากจนน่าตกใจ
      ผมเข้าใจและเห็นด้วยบางส่วนกับข้อโต้แย้งอย่างต้นทุน ค่าเสียโอกาส และ pragmatism แต่บางครั้งก็สลัดความรู้สึกไม่ได้ว่าเราแค่ยอมรับการใช้ชีวิตอยู่ในโลกที่สร้างเสร็จแค่ครึ่งเดียว
    • ตอนเป็นวัยรุ่นเมื่อ MacBook Air รุ่นแรกออกมา เพื่อนผมพบว่าแค่เปิดแอปใน Dock บนเครื่องเดโมในร้านอย่างรวดเร็วต่อเนื่อง ก็ทำให้เครื่องแครชได้อย่างสม่ำเสมอ คลิกอยู่ไม่กี่วินาทีเครื่องก็แครชแล้วรีบูต
      ตอนนี้ก็ไม่รู้สึกว่าดีขึ้น เด็กเล็ก ๆ พอได้จับโทรศัพท์หรือแล็ปท็อป แค่กดปุ่มเร็วเกินไปหรือกดในลำดับที่ไม่คาดคิด ก็ทำให้อุปกรณ์สมัยใหม่ค้าง หน่วง และแครชได้ค่อนข้างสม่ำเสมอ ทั้งที่ไม่ได้ทำให้พังทางกายภาพเลย แต่นี่คือสภาพของเทคโนโลยีสมัยใหม่
      ผมเข้าใจว่าทำไมถึงยังไม่ถูกแก้ ผู้คนเริ่มคาดหวังไปแล้วว่าบางครั้งต้องรีสตาร์ต และกรณีแบบนี้ก็โยนความผิดให้เด็กได้ง่าย แถมรีสตาร์ตแล้วก็หาย แต่ถึงอย่างนั้น ในวงจรชีวิตของระบบปฏิบัติการ ผมก็หวังว่าตอนนี้มันควรจะดีขึ้นได้แล้ว
    • https://danluu.com/everything-is-broken/
    • ผมไม่ได้คิดว่าซอฟต์แวร์ทุกวันนี้มีบั๊กมากกว่าเมื่อก่อนมากขนาดนั้น คนที่เคยทำ ซัพพอร์ตเครื่อง Windows ช่วงปลายยุค 90 และต้นยุค 2000 จะรู้ดี

  • ในบทความที่เขียนเกี่ยวกับ C ผมไม่ได้พูดถึงเรื่องนี้ แต่หนึ่งในเหตุผลสำคัญที่ผมใช้ C คือมันทำให้สร้างซอฟต์แวร์ที่บวมเทอะทะได้ยาก จะเพิ่มฟีเจอร์ก็ได้ แต่การที่ฟีเจอร์เดียวจะทำให้ไฟล์ executable เพิ่มขึ้น 100KB ก็ยังไม่ง่าย
    ตอนนี้ไม่ได้มีงานประจำ แต่ใช้เครื่องแรงสำหรับ “งาน” อยู่ ถึงอย่างนั้นก็ใช้ Neovim กับ tmux แทน IDE ใช้ Gentoo ที่ปรับแต่งหนัก ๆ แทน Linux distro ทั่วไป และใช้ OpenRC แทน systemd รวมถึงใช้ tiling window manager ชื่อ Qtile แทนเดสก์ท็อปเต็มรูปแบบ
    ผมรักษาเครื่องให้ไม่บวมเทอะทะ จนตอนบูตและเพิ่งล็อกอินมีแค่ 40 โปรเซส ตอนนี้ผมกำลังทำวิศวกรรมซอฟต์แวร์จริง ๆ อยู่ พยายามลดปัญหาของ C อย่างได้ผล พร้อมกับรักษาซอฟต์แวร์ให้เล็กและเร็ว และหวังว่าสักวันจะสร้างธุรกิจบนสิ่งนั้นได้
    คงได้เห็นกันว่ายังมีตลาดสำหรับซอฟต์แวร์ที่ไม่บวมและคล่องตัวอยู่หรือไม่
    https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
    https://gavinhoward.com/2020/12/my-development-environment-a...
    https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
    https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

    • เป็นมุมมองที่น่าสนใจ ผมแก่พอที่จะจำยุคที่ ภาษา C ถูกมองว่าบวมเทอะทะเมื่อเทียบกับการเขียน assembly โดยตรงได้
      โปรแกรมอย่าง WordPerfect, Lotus 123, MS-DOS 1.0 และ SubLogic Flight Simulator ก่อนที่ Microsoft จะเข้าซื้อ ในยุค 1980 ล้วนเขียนด้วย assembly ตอนนั้นผู้สังเกตการณ์ในอุตสาหกรรมมองว่า เพราะ MS Word และ MS Excel เขียนด้วย C ที่ “บวม” Microsoft จึงทำซ้ำฟีเจอร์ใหม่ ๆ ได้เร็วกว่า WordPerfect กับ Lotus 123 และพอร์ตไปยังสถาปัตยกรรมอื่นได้เร็วกว่า เพราะคู่แข่งยังอยู่กับ assembly นานเกินไป
      ในซอฟต์แวร์ส่วนตัวก็เห็น trade-off แบบเดียวกัน ถ้าใช้ C#/Python ที่ระดับสูงกว่าและ “บวม” กว่า แทน C/C++ ที่เพรียวกว่า ก็ทำงานบางอย่างเสร็จได้เร็วขึ้นมาก ผมถนัด C++ มากกว่าและชอบไฟล์ executable ขนาดเล็ก แต่ถ้า C# ทำงานที่ต้องการให้เสร็จได้เร็วกว่า ข้อดีนั้นก็หมดความหมาย ผมเองก็เป็นส่วนหนึ่งของปัญหาซอฟต์แวร์บวมเหมือนกัน
    • ผมมองว่า “วิศวกรรมจริง ๆ” คือการวางการตัดสินใจเหล่านี้ไว้บน สเปกตรัมของการประนีประนอม แล้วจัดวางโปรเจกต์ให้เหมาะกับข้อจำกัดของทั้งผู้สร้างและผู้ใช้ ผลลัพธ์อาจไปอยู่สุดขั้วด้านหนึ่งได้ แต่ไม่ได้หมายความว่าคนที่อยู่ตำแหน่งอื่นเพราะข้อจำกัดอื่น ๆ ไม่ได้ทำ “วิศวกรรมจริง ๆ”
      “จะสร้างสะพานที่แข็งแรงที่สุดและเบาที่สุดในโลก” เป็นเรื่องน่าทึ่ง ส่วน “จะสร้างสะพานที่เบาพอและแข็งแรงพอ ในราคาที่ลูกค้าจ่ายไหว” นั่นคือวิศวกรรม
    • บอกว่าฟีเจอร์เดียวเพิ่มไฟล์ executable ถึง 100KB ยังยาก แต่ถ้าลองทำ รองรับ Unicode แล้วจะเห็นต่างออกไป
    • อยากให้ช่วยอธิบายเพิ่มเติมตรงที่ว่า “ลดปัญหาของ C อย่างได้ผล” หมายถึงพยายามแก้ปัญหาของตัวภาษาเอง ใช้ dialect ใหม่ของ C ปัญหาใน ecosystem อย่างความยากของ static linking กับ glibc หรือเป็นเรื่องอื่นไปเลยกันแน่
    • เห็นด้วยกับประโยคที่ว่า “เคยปฏิเสธข้อเสนองาน C++”

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

    • จากมุมมองผู้ใช้ ซอฟต์แวร์ควรต้องเร็ว นั้นเป็นเรื่องจริง ลองคิดดูว่าคอมเมนต์นี้เขียนบน iPhone 4 หรือ 14 หรือเวิร์กสเตชันเป็น Pentium แรม 4GB หรือเปล่า
      เครือข่ายก็น่าจะไม่ใช่ 2G ระดับไม่กี่ kbps แต่เป็น 5G หลายร้อย Mbps หรือสายไฟเบอร์เสียมากกว่า สุดท้ายการกระทำดังยิ่งกว่าคำพูด และถ้าสังคมโดยรวมยึดสัจพจน์ว่า “ซอฟต์แวร์ที่เร็วขึ้น” ก็ยอมรับว่าเป็นความจริงได้
      โดยเฉพาะเมื่อมันเป็นสัจพจน์ที่มาจากที่เดียวกับข้ออ้างว่า “เวลาของนักพัฒนามีค่ากว่า” ความต่างมีแค่ว่ากำลังประหยัดเวลาของใคร
    • ถ้าโค้ดใช้เวลาหลายวินาทีบน M1 Mac ราคาแพง ผู้ใช้ที่เป็นไปได้สัดส่วนค่อนข้างมากอาจต้องรอเป็นหลายนาที ผู้ใช้ที่ไม่ใช่สายเทคนิคมักยอมรับความไร้เหตุผลแบบนี้ไปเฉย ๆ เพราะไม่รู้ว่าประสิทธิภาพสามารถดีขึ้นได้มากโดยไม่ต้องซื้อฮาร์ดแวร์ใหม่
      ถ้านักพัฒนาไม่ทดสอบบน อุปกรณ์สเปกต่ำ ด้วย ก็จะไม่รู้ถึงปัญหานี้เลย ปัญหาจริง ๆ ไม่ได้อยู่ที่ด้านเทคนิคเท่ากับท่าทีของนักพัฒนาบางคนที่ตั้งรับและเริ่มเถียงทันทีเมื่อเจอความจริงที่ไม่สบายใจว่าโค้ดช้าเกินไป ควรไปนั่งกับผู้จัดการผลิตภัณฑ์ จัดเวลาสำหรับ profiling และ optimization แล้วดูว่าจะบรรเทาปัญหาประสิทธิภาพอย่างไรโดยไม่ต้องสร้างใหม่ตั้งแต่ต้น
    • ชอบความโกรธเชิงอารมณ์นะ บางครั้งข้อมูลก็แค่ทำให้ความจริงที่เรารู้อยู่แล้วพร่ามัว ไม่จำเป็นต้องมีข้อมูลมาบอกว่าเราควรพยายามอย่างเต็มที่เพื่อสร้างซอฟต์แวร์ที่ดีที่สุด และบทความนี้ก็ช่วยเตือนเรื่องนั้น
    • ในประโยคว่า “ซอฟต์แวร์สมัยใหม่ทำให้ผู้คนสร้างอะไรบางอย่างที่แย่ได้” ไม่เข้าใจว่าซอฟต์แวร์สมัยใหม่มีอะไรพิเศษกันแน่ และก็ไม่ชัดเจนว่าใช้อะไรเป็นเกณฑ์ตัดสินว่าสมัยใหม่
      BASIC กับ SQL ก็มีเจตนามานานแล้วที่จะทำให้ผู้คนสร้างอะไร “แย่ ๆ” ได้ และ Fortran รวมถึงภาษาและเทคโนโลยีจำนวนมากที่หายไปแล้วก็เช่นกัน
      Python หรือ Java ถ้าพูดแบบใจดีก็ถือว่าอนุรักษนิยม และถ้าคิดถึงความก้าวหน้าของภาษาโปรแกรมมิงในยุค 70 จริง ๆ ก็ควรเรียกว่าล้าสมัยด้วยซ้ำ J หรือ Prolog ล้ำหน้ากว่า Rust หรือ Go มากในเชิงแนวคิด แต่ถูกสร้างมาก่อน C ที่สะสมมาจาก C89 ถึง C23 เป็นภาษาสมัยใหม่หรือไม่ หรือมีแค่ C23 ที่สมัยใหม่ และระหว่าง C89 กับ C23 มีความต่างใหญ่จริง ๆ หรือไม่ ก็ยังคลุมเครือ
      ถ้าไม่ใช่เวลาที่ถูกสร้างขึ้นหรือผังวิวัฒนาการในจินตนาการ ก็สงสัยว่ามีวิธีอื่นในการนิยาม ความสมัยใหม่ หรือเปล่า
    • ผมคิดว่าผู้เขียนตอบคำถามของตัวเองแล้วในย่อหน้าต้น ๆ ที่ว่า “เฉพาะในซอฟต์แวร์เท่านั้นที่โปรแกรมรันได้แค่ 1% หรือ 0.01% ของประสิทธิภาพที่เป็นไปได้ก็ยังโอเค ดูเหมือนทุกคนจะโอเคกันหมด” ถ้าทุกคนโอเค ก็ปล่อยผ่านไปเถอะ

  • เป็นคำบ่นเก่า ๆ ความสะดวกสบายหลายอย่างที่เรามองว่าเป็นเรื่องปกติมีต้นทุน และต้นทุนนั้นสะสมจนใหญ่โต หน้าจอ 4K มีพิกเซลมากกว่า 800x600 ถึง 17 เท่า และใช้สี 32 บิต ดังนั้นขนาดดิบของกราฟิกสำหรับจอแสดงผลสมัยใหม่จึงใหญ่ขึ้นราว 68 เท่า
    เมื่อก่อนภาพนิ่งก็เพียงพอแล้ว แต่ตอนนี้แอนิเมชันคุณภาพสูงเฟรมเรตสูงกลายเป็นมาตรฐาน Arial Unicode เป็นฟอนต์ขนาด 15MB และคงไม่สามารถใส่ในหน่วยความจำของคอมพิวเตอร์ส่วนใหญ่ที่รัน Windows 95 ได้ด้วยซ้ำ
    การตรวจสะกดทุกที่กลายเป็นเรื่องปกติไปแล้ว และสิ่งเหล่านี้ก็สะสมกัน ถึงอย่างนั้นมันก็ทำให้คอมพิวเตอร์น่าใช้ขึ้นมาก ผมไม่คิดถึงโหมดวิดีโอ 16 สี หรือยุคที่ไม่สามารถใช้ภาษาที่ไม่ใช่ภาษาอังกฤษสองภาษาพร้อมกันได้โดยไม่ต้องใช้ทางอ้อมที่น่าหงุดหงิดมาก ๆ

    • แม้อยู่ภายใต้ข้อจำกัด 4K และ Unicode เดียวกัน ก็ยังมีแอปที่มีประสิทธิภาพมากกว่าหลายลำดับขั้น ดังนั้นเรื่องนี้อย่างเดียวอธิบายไม่ได้
    • จริงที่มันมีต้นทุน แต่ต้นทุนนั้นไม่ได้คุ้มค่าเสมอไป ฉันต้องการหน้าจอ 4K และยินดีจ่ายค่าพิกเซลเหล่านั้น
      แต่ไม่ต้องการแอนิเมชันที่มีเหตุผลเพียงเพื่อทำให้เวลารอดูน่าเบื่อน้อยลง Unicode ก็เป็นสิ่งที่คุ้มจ่าย
      ถึงอย่างนั้น ก็ควรวาด glyph ลงบนหน้าจอได้ภายในเวลาไม่กี่มิลลิวินาทีเหมือนในปี 1981 พิกเซลและ glyph มีมากขึ้นก็จริง แต่ทำได้ เพียงแค่มันไม่ใช่ลำดับความสำคัญเท่านั้น
    • เข้าใจว่าผลลัพธ์ทุกอย่างกินทรัพยากรมากขึ้นมาก แต่ต้องมีคำอธิบายว่าเหตุใดซอฟต์แวร์ยังคงช้าจนน่าปวดใจ ทั้งที่ใช้ ทรัพยากรการประมวลผลมากขึ้น 100 เท่า
      คล้ายกับจ่าย 100,000 ดอลลาร์ซื้อ BMW สมรรถนะสูง แล้ววิศวกรบอกว่าเร่ง 0-60mph ใช้เวลา 30 วินาที และผู้ใช้ไม่ใช่ผู้เชี่ยวชาญด้านสมรรถนะก็เลยต้องยอมรับไปตามนั้น

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

    • ก็รอดูผลกระทบอันเลวร้ายที่ LLM จะมีต่อคุณภาพโค้ดและประสิทธิภาพในอีกไม่กี่ปีข้างหน้าได้เลย คลื่นโปรแกรมเมอร์หน้าใหม่คือ “คนกระซิบ GPT” ที่ใช้เวลาส่วนใหญ่เกาะติดแชตบอตแม้แต่ใน IDE และให้แชตบอตเขียนโปรแกรมแทน
      แน่นอนว่านี่คือเรื่องก่อนที่ AI จะไปถึงจุดที่แก้ได้ทั้งหมด ไม่ว่าจะเป็นสิ่งที่เราเขียนผิด สิ่งที่ AI เขียนผิด และแม้แต่ตัว AI เองที่ไร้ประสิทธิภาพอย่างมากตามที่บทความต้นทางคาดการณ์ไว้
    • ไม่ใช่แค่เรื่องการวัดผลได้ แต่เป็นปัญหาของ ความสามารถทำกำไร ด้วย ทุนนิยมไม่ได้สร้างผลิตภัณฑ์ที่มีประสิทธิภาพ แต่สร้างการผลิตที่มีประสิทธิภาพ เพราะมันสนใจแค่การสกัดกำไรออกจากระบบการผลิต
      รถยนต์ถูกปรับให้เหมาะสมก็ต่อเมื่อเกิดช็อกจากน้ำมันภายนอก และถึงอย่างนั้นก็ยังไม่สม่ำเสมออย่างมาก ในความเป็นจริง ผลิตภัณฑ์ที่ไม่มีประสิทธิภาพมักทำกำไรได้มากกว่า เพราะลูกค้าต้องเปลี่ยนบ่อยกว่า สาย iPhone ห่วย ๆ ที่แตกหลังผ่านไปหนึ่งปีทำให้ Apple เรียกเก็บเงินค่าเปลี่ยนได้ซ้ำแล้วซ้ำเล่า เครื่องใช้ไฟฟ้าสีขาวเสียบ่อยขึ้น แต่ผลิตได้ถูกลง ทำให้กำไรต่อหน่วยสูงขึ้น สิ่งสำคัญไม่ใช่ประสิทธิภาพการใช้งานหลังการขาย แต่คือประสิทธิภาพการผลิต
      ในซอฟต์แวร์ ทุนนิยมทำงานด้วยการเทระบบอัตโนมัติใหม่ ๆ ออกมาให้เร็วที่สุด และปล่อยให้ผู้บริโภครับภาระการสูญเสียพลังงานและเวลา ห่วงโซ่การผลิตถูกทำให้เป็นมาตรฐานและปรับแต่งให้เหมาะสมมากขึ้นเรื่อย ๆ จนสามารถสับเปลี่ยนนักพัฒนา React หรือผู้ดูแล Kubernetes ได้เหมือนคนงานคลังสินค้า และเกิดแรงกดดันต่อค่าจ้างตามมา ระบบอัตโนมัติบางส่วนแทบจะเป็นการสร้างเหตุผลให้ตัวเองดำรงอยู่ เช่นทำให้ศัพท์บัญชียากเกินเข้าใจเพื่อให้มีงานรองรับ ส่วนที่เหลือเป็นเรื่องของกำไร

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

    • เวลาในการบูตยังคงแย่มาก โดยเฉพาะใน ระบบ AM5/DDR5 รุ่นใหม่ ๆ
      BIOS ของผมใช้เวลา POST ประมาณ 20 วินาที และเขาว่านี่เป็นเรื่องปกติ หลังจากนั้น OS บูตประมาณ 10 วินาที
    • ไม่แน่ใจว่าลูกค้าเคยมีทางเลือกที่มีความหมายหรือช่องทางแสดงความต้องการตั้งแต่เมื่อไร นานมาแล้วมันเป็นตลาดที่ขับเคลื่อนโดยฝั่งอุปทาน ผู้ผลิตทำสิ่งที่อยากทำ แล้วลูกค้าก็ซื้อสิ่งที่มีอยู่ในตลาด
    • บนพีซีที่โรงเรียน WordPerfect ใช้เวลาบูตเป็นนาที ๆ แบบตามตัวอักษร
    • คำพูดที่ว่า “วิศวกรได้รับค่าจ้างให้สร้างผลิตภัณฑ์สำหรับลูกค้า” ถูกต้องในระดับหนึ่ง แต่ซอฟต์แวร์กลายเป็นองค์ประกอบสำคัญของชีวิตมนุษย์ในหลายแง่มุม เหมือนไฟฟ้าหรือบริการทางการแพทย์
      อาจพูดได้ว่าแพทย์หรือวิศวกรก็ได้รับค่าจ้างให้พัฒนายาใหม่หรือแหล่งพลังงานใหม่ แต่สาขาเหล่านี้อ่อนไหวและสำคัญ จึงมีการควบคุมจากรัฐหลายชั้น ซอฟต์แวร์ยังไม่มีการควบคุมในระดับนั้น
    • ถูกบางส่วน แต่เวลาบริษัทขนาด Google หรือ Apple เป็นผู้กำหนดกระแส ก็ไม่ควรแสร้งทำเหมือนกำลังทำตามเจตจำนงของลูกค้าแบบบริษัทเล็กหรือบริษัทขนาดกลาง
      พวกเขามีพลังในการหล่อหลอมสภาพแวดล้อมเอง จึงสามารถเปลี่ยนทิศทางผลลัพธ์ของ “ความต้องการของลูกค้า” ได้อย่างมาก

  • บทความนี้เขียนในปี 2018 และเคยมีการถกเถียงก่อนหน้านี้อยู่หลายครั้ง
    https://news.ycombinator.com/item?id=18012334 (Sep 2018)
    https://news.ycombinator.com/item?id=21929709 (Jan 2020)
    https://news.ycombinator.com/item?id=31798580 (Jun 2022)

  • เห็นด้วยอย่างลึกซึ้ง สิ่งสำคัญคือในฐานะนักพัฒนา เราต้องจำไว้ว่าเรามีทางเลือก เราเลือกทุกอย่างไม่ได้ แต่เลือกทางเลือกที่แย่น้อยกว่าได้
    ไม่จำเป็นต้องใช้ Node เสมอไป ใน ecosystem ของ .NET หรือ JVM ก็สามารถเขียนซอฟต์แวร์ที่ดีและรองรับย้อนหลังได้ และคาดหวังได้ว่ามันจะยังรันได้โดยไม่ต้องแก้ไขในอีก 10 ปีข้างหน้า
    ไม่จำเป็นต้องสร้างเว็บเพจแบบ single-page เสมอไป HTML แบบเก่าที่โหลดทั้งหน้าใหม่ทุกครั้งที่คลิกก็ทำงานได้ดี และ ณ จุดนี้อาจมี latency ต่ำกว่าด้วยซ้ำ
    ไม่จำเป็นต้องสร้างแอปเดสก์ท็อปด้วย Chromium เสมอไป การเริ่มใช้ UI framework อาจต้องลงแรงเพิ่มอีกเล็กน้อย แต่คุณภาพก็คุ้มค่า เราไม่ได้มีอำนาจตัดสินใจเสมอไป แต่เมื่อมี ก็ควรถอยออกจากตัวเลือกที่แย่

    • ทุกวันนี้แนวคิดที่ว่า “ทุกอย่างต้องเป็น SPA” เป็นเรื่องน่าเศร้า เข้าใจได้ว่าแอปซับซ้อนอย่าง GMail ได้ประโยชน์จาก SPA แต่มีสถานที่มากเกินไปที่ยังยืนกรานเพิ่มความซับซ้อนฝั่ง frontend ทั้งที่สามารถสร้างฟังก์ชันเดียวกันได้ด้วย CSS/HTML พื้นฐานและ jQuery เล็กน้อย โดยใช้เวลาน้อยกว่ามากและมีบั๊กน้อยกว่ามาก
    • พอได้ยินว่าซอฟต์แวร์ที่รองรับย้อนหลังใน ecosystem ของ .NET ใช้งานได้ดี ก็อดกระแอมไม่ได้ โครงการ .NET Core ทำให้โค้ดจำนวนมากพังจริง ๆ และ Microsoft ก็เลิกใช้ไลบรารีจำนวนมาก แน่นอนว่าบางส่วนมีเหตุผลที่สมเหตุสมผลมาก และไลบรารี .NET แบบ legacy จำนวนมากก็มีตัวเลือกด้านการออกแบบที่ค่อนข้างแย่