- หากให้การปรับแต่งซอฟต์แวร์เป็นลำดับความสำคัญจริง ๆ ระบบจำนวนมากกว่าที่คาดอาจทำงานได้แม้บน ฮาร์ดแวร์รุ่นเก่า
- เมื่อ สัญญาณราคาตลาด ทำงานกับทรัพยากรประมวลผลที่มีจำกัด แรงกดดันในการสร้างซอฟต์แวร์ที่มีประสิทธิภาพมากขึ้นก็จะเพิ่มขึ้น
- ตัวอย่างหนึ่งคือการสร้างผลิตภัณฑ์ที่ใช้ภาษาแบบ interpreted และสถาปัตยกรรม microservices ขึ้นใหม่เป็น codebase แบบ native ที่เป็น monolith
- แต่หากไม่มีการประมวลผลที่ราคาถูกมากและขยายขนาดได้สูง การทดลองและเปิดตัว ผลิตภัณฑ์ใหม่เชิงนวัตกรรม อาจเกิดขึ้นได้น้อยลงมาก
- การปรับแต่งประสิทธิภาพเพียงอย่างเดียวยังไม่เพียงพอ และการประมวลผลที่ราคาถูกและขยายขนาดได้คือปัจจัยที่กำหนดความถี่ของการทดลองและการเปิดตัวผลิตภัณฑ์
การทดลองทางความคิดที่ให้ความสำคัญกับการปรับแต่งเป็นอันดับแรก
- หากการปรับแต่งซอฟต์แวร์เป็นลำดับความสำคัญจริง ๆ ระบบจำนวนมากกว่าที่คาดอาจทำงานได้บน ฮาร์ดแวร์รุ่นเก่า
- หากสัญญาณราคาทำงานอย่างเข้มข้นกับทรัพยากรประมวลผลที่มีจำกัด ตลาดจะต้องการซอฟต์แวร์ที่มีประสิทธิภาพมากขึ้น
แนวทางการทำให้เป็นจริงที่เป็นไปได้และข้อจำกัด
- ตัวอย่างหนึ่งคือการสร้างผลิตภัณฑ์ที่ใช้ภาษาแบบ interpreted และ microservices ขึ้นใหม่เป็น codebase แบบ native ที่เป็น monolith
- อย่างไรก็ตาม หากไม่มีการประมวลผลที่ราคาถูกมากและขยายขนาดได้สูง ผลิตภัณฑ์ใหม่เชิงนวัตกรรม อาจเกิดขึ้นได้น้อยลงมาก
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อาจให้เหตุผลได้ว่า ตลาดยังซื้อ ซอฟต์แวร์ที่มีบั๊กเยอะและไร้ประสิทธิภาพ ได้ดีพอ ๆ กับซอฟต์แวร์ที่ทำมาอย่างสมบูรณ์ และหนึ่งในสองแบบนี้คือซอฟต์แวร์ที่ถูกที่สุดเท่าที่จะสร้างได้
เรื่องนี้คล้ายกับแนวคิด “ตลาดมะนาว” ตลาดขายสินค้าทุกอย่างราวกับมีคุณภาพสูง แต่แอบลดคุณภาพลงเพื่อลดต้นทุนส่วนเพิ่ม ผู้ซื้อแยกสินค้าคุณภาพสูงกับคุณภาพต่ำก่อนซื้อไม่ได้ ทำให้อุปสงค์ใกล้เคียงกันแบบผิดธรรมชาติ และสาเหตุคือความไม่สมมาตรของข้อมูล
ใน AI เรื่องนี้เกิดขึ้นแล้ว และต่อไปจะหนักขึ้นอีก ผู้ใช้แยกไม่ออกระหว่างแอปแมชชีนเลิร์นนิงที่ซับซ้อนกับการเรียกรอบปั่นหมาดของเครื่องซักผ้าว่าเป็น AI ตัว ป้ายกำกับ AI เองสร้างราคาพรีเมียมขึ้นมา และผู้ใช้ก็จ่ายเกินจริงให้กับเครื่องซักผ้าอย่างมาก
การจ่ายเกินจริงเพราะเชื่อว่าซอฟต์แวร์ห่วย ๆ ถูกออกแบบและเขียนโดยนักเทคโนโลยีกับผู้เชี่ยวชาญก็เป็นเรื่องเดียวกันโดยพื้นฐาน ซอฟต์แวร์ 99% เขียนโดย IC1~3 และในบริษัทเทคโนโลยีส่วนใหญ่ QA หนึ่งคนคือกลไกเดียวที่ยกระดับคุณภาพให้เกินกว่า “ตรงตามเกณฑ์การรับมอบ” บางครั้งก็มีกลุ่มอินเทิร์นท่องคาถา “LGTM” แต่ถึงอย่างนั้นก็ยังพบได้ไม่บ่อย
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
เคยมั่นใจว่าถ้าผลิตภัณฑ์ดีกว่า ก็จะโน้มน้าวผู้คนและเติบโตแบบไวรัลได้ แต่ไม่เป็นอย่างนั้น มันก็เติบโตอยู่ แต่ช้าเกินไปจนเงินหมดภายในไม่กี่ปีก่อนจะถึงจุดคุ้มทุน
สิ่งที่ได้ตระหนักคือ ในตลาดแข่งขัน ต้นทุนต่ำ และดังนั้นคุณภาพต่ำ จึงเป็นข้อได้เปรียบในการแข่งขัน ยิ่งผลิตภัณฑ์มีขนาดใหญ่ขึ้น แรงกดดันให้ลดต้นทุนก็ยิ่งเพิ่มขึ้น และผู้คนต้องการของถูก ดังนั้นจะมีใครสักคนลด “ต้นทุน” หรือก็คือลดคุณภาพลงเพื่อทำให้ถูกกว่า บริษัทจ่ายเท่าที่จำเป็นขั้นต่ำเพื่ออยู่รอดและทำกำไร
บริษัทอายุน้อยอาจพยายามสร้างของคุณภาพสูง หรือเพิ่มค่าใช้จ่ายชั่วคราว แต่สุดท้ายจะเกิดกระแสที่ไหลลงไปสู่ ความธรรมดาที่มั่นคง เรื่องนี้ต่างจากตลาดมะนาวเล็กน้อย และดูเหมือนจะลงเอยด้วยความธรรมดาทั่วทุกหนแห่งมากกว่าการล่มสลายของตลาด
แต่ถ้าให้คนทั่วไปเลือกระหว่าง Slack กับ Weechat ซึ่งเป็นไคลเอนต์ IRC ที่เร็วกว่า ก็มีแนวโน้มจะมองฝั่งที่เป็น UI แบบเทอร์มินัล ไม่มีวิดีโอคอล ไม่มีการเชื่อมต่อ webhook ไม่มีอวาตาร์หรืออีโมจิปรับแต่งเอง ว่าเป็นคุณภาพต่ำ
ประสิทธิภาพก็เป็นฟีเจอร์ อย่างหนึ่งเช่นกัน เหตุผลใหญ่ที่ Internet Explorer แพ้ Chrome ก็เพราะ Chrome เร็วกว่ามากตอนเปิดตัว และเหตุผลที่นักพัฒนา Python ย้ายไปใช้ uv/ruff อย่างรวดเร็วก็คือประสิทธิภาพที่ดีขึ้น เพียงแต่ถ้า Slack ใช้เวลาเปิด 5 วินาทีแทนที่จะเป็น 10ms ก็มีคนสนใจเรื่องนี้น้อยมาก
เรื่องแบบนั้นเกิดขึ้นได้กับซอฟต์แวร์ที่มีบั๊กเยอะ แต่โดยทั่วไปแล้วผู้คนอยากจ่ายน้อยลง และยอมรับบั๊กบางส่วนในกระบวนการนั้น ลองคิดดูว่าต้องคิดราคาเท่าไร หากจะมีกระบวนการให้วิศวกรหลายคนรีวิวโค้ดทุกบรรทัดและใช้เวลากับ QA ที่เข้มงวดจำนวนมาก
ตอนอยู่ที่ Padova ผมเคยทำซอฟต์แวร์ให้ร้านหนังสือเล็ก ๆ แห่งหนึ่ง เพราะเป็นเพื่อนกันจึงทำอย่างรวดเร็วและไม่ได้คิดแพง มันไม่สมบูรณ์แบบ แต่ถ้ามีปัญหาก็แก้ให้ ปัญหาก็ไม่ได้เยอะ และเพื่อนก็พอใจกับดีลนั้น เพราะรู้ว่าผมคิดราคาถูก เขาจึงมีความอดทนด้วย
ผมเคยพูดหลายครั้งว่า ถ้าทีมของเราบอกลูกค้าว่า “โปรเจกต์เสร็จแล้ว แต่มีบั๊กและฝันร้ายด้าน UI เยอะพอ ๆ กับแพลตฟอร์ม back-office นี้” เราคงถูกตำหนิ ลดตำแหน่ง หรือไล่ออก
รวมถึงบริษัทอย่าง Google ที่ขาดการสนับสนุนจากมนุษย์ด้วย การสนับสนุนปรากฏได้หลายรูปแบบ: มีข้อมูลอย่างเอกสาร วิดีโอ บล็อก มีคนคอยช่วยอย่าง “แม่ครับ Google ใช้แบบนี้นะ” มีการรองรับสิ่งที่ใช้ เช่น ระบบปฏิบัติการ เบราว์เซอร์ รูปแบบไฟล์ และยังมีสิ่งที่รองรับวิธีทำงานของผมเองอย่าง Excel ด้วย
สุดท้ายคือคนจริง ๆ นี่คือปัจจัยอันดับหนึ่งที่ทำให้ ERP ที่แย่ที่สุดบนโลกยังอยู่รอดได้ การตลาดและการขายก็เป็นสัญญาณว่ามีการสนับสนุน สำหรับลูกค้าองค์กร ถ้ามองเห็นแต่วิศวกรอาจเป็นสัญญาณไม่ดี นักพัฒนามักทำงานอย่างอื่นไม่เป็น และงานอย่างอื่นนั้นก็คือการสนับสนุนที่สำคัญ
แม้ผลิตภัณฑ์จะดี แต่ถ้าไม่มีการสนับสนุนก็จบ การจะสู้กับผลิตภัณฑ์ที่แย่กว่า การลดความจำเป็นด้านการสนับสนุน เช่น บั๊ก ปัญหาประสิทธิภาพ แพลตฟอร์ม เพื่อลดต้นทุนของทีมตัวเองเป็นเรื่องฉลาด แต่ต้องเพิ่มการสนับสนุนในมิติอื่นอย่างแน่นอน สำหรับทีมเล็ก สิ่งที่ง่ายที่สุดคือใส่ คน ซึ่งเป็นทรัพยากรสนับสนุนที่ขาดแคลนที่สุดเข้าไป และขั้นต่อไปต้องใช้ความคิดสร้างสรรค์
นอกจากนี้ต้องสื่อสารจุดแข็งให้ดีด้วย บางคนให้ความสำคัญกับการสนับสนุนบางชนิดมากกว่า เช่น “มีโค้ดไว้ครอบครองได้ vs ผลิตภัณฑ์แบบปิด” หลายคนชอบผลิตภัณฑ์แบบปิดที่มีการสนับสนุนมากกว่าการมีโค้ด
ตั้งแต่ปี 1980 เป็นต้นมา โดยทั่วไปถือว่า พลังประมวลผล เพิ่มขึ้นประมาณ 1,000 เท่า
แม้การตรวจสอบขอบเขตของอาร์เรย์แบบไดนามิกจะมีต้นทุน 5% แต่ในความเป็นจริงมักน้อยกว่านั้นมาก และถ้าเปิดใช้ทุกที่ คอมพิวเตอร์ก็จะแค่เร็วขึ้นราว 950 เท่าเท่านั้น
ถ้าย้อนกลับไปปี 1980 แล้วให้เลือก ระหว่าง “คอมพิวเตอร์ที่เร็วขึ้น 950 เท่า ไม่มีช่องโหว่ด้านความปลอดภัยของหน่วยความจำกลุ่มใหญ่ และดีบักง่ายขึ้นหลายลำดับขั้น” กับ “คอมพิวเตอร์ที่เร็วขึ้น 1,000 เท่า แต่ซอฟต์แวร์ยังเต็มไปด้วยบั๊กหรือแย่กว่าเดิม และการดีบักเป็นฝันร้าย” ผู้คนคงตกใจมากแล้วกับแค่ 950 เท่า
แต่สิ่งที่เราเลือกคือแบบหลัง และโดยส่วนตัวคิดว่า ฝ่าย 1,000 เท่า ทำให้คนที่เหลือเสียหายไปด้วย
สุดท้ายเมื่อพวกเขา optimize ให้รันบน Sparc 20 ได้อย่างมีประสิทธิภาพ บริษัทก็มีฐานที่จะประสบความสำเร็จในตลาดที่กว้างขึ้นได้ การ optimize ควรถูกมองเป็นความได้เปรียบในการแข่งขัน และในบางกรณีอาจเป็นความได้เปรียบในการแข่งขันที่สำคัญที่สุดด้วย
ดังนั้นการบังคับตรวจสอบขอบเขตอาจทำให้ภาษานั้นเสียความสามารถในการแข่งขันในงานบางประเภท
ในกรณีส่วนใหญ่แทบไม่สำคัญเลยและน้อยกว่า 5% มาก ผมคิดว่าวิธีที่ดีคือแบ่งเป็น safe/unsafe หรือช่วงการใช้งานทั่วไป/ประสิทธิภาพ
CPU กระแสหลักน่าจะใกล้เคียงกับการเร็วกว่าเครื่องยุค 80 ถึง 1 ล้าน–2 ล้านเท่า มากกว่า ใช้เงินไม่กี่ร้อยดอลลาร์ก็ยังซื้อคอมพิวเตอร์สำนักงาน refurbished ที่อยู่ในระดับเร็วกว่า 1 ล้านเท่าได้
ปรากฏการณ์ที่คอมพิวเตอร์ตอนนี้ช้าและรู้สึกช้า ไม่ใช่แค่เพราะคอมพิวเตอร์ช้า แต่ก็ยังเกิดขึ้นอยู่ดี สาเหตุส่วนหนึ่งคือภาษา scripting ที่จัดสรรหน่วยความจำซ้ำ ๆ สำหรับการดำเนินการเล็ก ๆ และเพราะ dynamic typing ทำให้ต้องไล่ pointer ตามตัวแปรทุกตัว อีกทั้งยังมีคนที่ใช้โปรแกรมซึ่งไร้ประสิทธิภาพอย่างสุดขั้วบนสภาพแวดล้อมที่แย่อยู่แล้ว
ทุกวันนี้โปรแกรมส่วนใหญ่ถูกเขียนตามวิธีที่ผู้เขียนอยากทำงาน ไม่ใช่วิธีที่ผู้ใช้ต้องการ หลายคนไม่มีแนวคิดเรื่อง optimization หรือไม่รู้สึกว่าอะไรจะรันได้เร็วกว่า พอทำให้มันทำงานได้แล้วก็คิดว่า “โปรแกรมนี้ก็เร็วได้เท่านี้แหละ”
ความคิดที่ว่าซอฟต์แวร์เดียวกันสามารถเร็วขึ้นได้เองเป็นแนวคิดเฉพาะกลุ่ม และแม้แต่ใน Hacker News ก็ไม่ใช่ทุกคนที่คิดแบบนั้น
ภาษาแบบ garbage collection มักใช้หน่วยความจำมากกว่าหลายเท่า เพราะไม่ได้คืนหน่วยความจำที่ไม่ใช้งานแล้วทันที และตั้งแต่แรกก็มักต้องมีการจัดสรรหน่วยความจำมากกว่า
จากการทำงานที่ Google และ Facebook ทำให้รู้สึกได้ว่าฮาร์ดแวร์ราคาถูกแค่ไหน และในกรณีส่วนใหญ่การ optimize โค้ดมีคุณค่าน้อยเพียงใด
Google เริ่มบริหารการใช้ทรัพยากรดาต้าเซ็นเตอร์มานานกว่า 10 ปีแล้ว และแต่ละโปรเจกต์มีงบประมาณอย่าง CPU core, พื้นที่ฮาร์ดดิสก์, flash storage, disk spindle, หน่วยความจำ เป็นต้น ทรัพยากรเหล่านี้โดยทั่วไปแปลงเทียบกันได้ จึงเห็นต้นทุนสัมพัทธ์ได้
ตอนนั้น flash storage แพงกว่าฮาร์ดดิสก์ประมาณ 20 เท่า แต่เพราะ bottleneck ที่ spindle ในหลายกรณีเมื่อคิดต้นทุนรวมกลับถูกกว่า
ทั้งหมดนี้สามารถแปลงเป็น “mili-SWE” หรือ 1 ใน 1,000 ของแรงงานที่ SWE 1 คนทำงาน 1 ปีได้ โปรเจกต์สามารถประหยัดฮาร์ดแวร์แล้วจ้างคนเพิ่ม หรือจ้างคนน้อยลงแล้วรับฮาร์ดแวร์เพิ่มภายในงบปัจจุบันได้
จำไม่ได้แน่ชัดว่า CPU core กี่คอร์เท่ากับ SWE 1 คน แต่น่าจะเป็นหลักหลายพัน ถ้าใช้เวลา SWE 1 ปีไปกับการ optimize ทั้งโปรเจกต์แล้วยังประหยัด CPU core 5,000 คอร์ ไม่ได้ ก็ขาดทุนสุทธิ
โปรเจกต์ขนาดใหญ่มากใช้มากกว่านั้นเยอะ จึงสมเหตุสมผลที่จะ optimize แต่หลายกรณีก็ไม่คุ้ม โดยเฉพาะถ้าโค้ดที่เขียนมีโอกาสสูงที่จะถูกแทนที่ในสักวันหนึ่ง
อีกด้านหนึ่ง เว็บมีปัญหา usability โดยทั่วไป เว็บไม่ควรใช้ทรัพยากรมากเท่าที่ใช้ตอนนี้ ถ้ารู้จักคนที่เคยทำงานป้อนข้อมูล จะรู้ว่าเมาส์ค่อนข้างไม่มีประสิทธิภาพ เทอร์มินัลแบบข้อความเมื่อ 30–40 ปีก่อนให้ interface ที่มีประสิทธิภาพมากโดยใช้ทรัพยากรน้อยมาก
เคยคิดว่าสักวันเว็บจะถูก “แก้ปัญหา” ในแบบที่มี tech stack มาตรฐานตามที่คาดหวังกันทั่วไป แล้วเราก็ไปสนใจปัญหาอื่นต่อ แต่ก็ไม่เป็นเช่นนั้น ยังคงมี “framework ประจำสัปดาห์นี้” และมีเรื่องโง่ ๆ อย่างการเขียน scrollbar ใหม่ในโค้ดผู้ใช้ที่เข้ากับ mouse wheel ได้ไม่ดี ไม่รู้ว่าจะแก้ปัญหานี้ได้อย่างไร หรือแม้แต่จะ “แก้” ได้ตั้งแต่แรกหรือไม่
Google ทุ่มแรงอย่างมหาศาลกับ performance อีกสองด้านคือ latency และอัตราการใช้เครื่องโดยรวม ทั้งสองอย่างเป็นคำสั่งจากเบื้องบน ดูดเวลาและความสนใจของวิศวกรหลายพันคน และมีต้นทุนแรงงานสูงด้วย
แต่ถ้าเครื่องเป็นข้อจำกัด ต่อให้คอร์แต่ละคอร์จะถูก ก็ไม่อยากปล่อยให้มันว่างโดยไม่มีเหตุผล เพราะ opportunity cost ของการรอสร้างดาต้าเซ็นเตอร์ใหม่สูง ถ้าปริมาณการใช้งานอ่อนไหวต่อ latency มาก การลดระดับมิลลิวินาทีจึงสมเหตุสมผลไม่ใช่เพื่อลดต้นทุนฮาร์ดแวร์ แต่เพราะตัวชี้วัดทางธุรกิจ
การประเมินควรทำที่ ต้นทุนส่วนเพิ่ม ต่อให้ประหยัดได้เพียงไม่กี่เซนต์ต่อปีต่อ 1 ดอลลาร์ ก็ยังดีกว่าให้วิศวกรอยู่ว่าง ๆ
ปัญหาคือแทบไม่มีใครทำแบบนั้น วิธีตัดสินใจไม่เกี่ยวกับการคำนวณทางเศรษฐศาสตร์ และส่วนใหญ่แค่ทำตาม “สิ่งที่ Google ทำ” ดังนั้นจึงอธิบายความล้มเหลวในการทำงานหลายอย่างได้
แต่บริษัททั่วไป แม้แต่บริษัทใหญ่ ๆ ก็ไม่ได้อยู่ระดับนั้น นี่ดูเป็นตัวอย่างคลาสสิกของ “Facebook/Google/Netflix ฯลฯ เป็นชนชั้นแยกต่างหาก และแนวปฏิบัติส่วนใหญ่ของพวกเขาใช้กับคุณไม่ได้”
เราอาจจินตนาการถึงจักรวาลคู่ขนานที่ทุ่มทรัพยากรบุคคลไปกับ optimization ได้ แต่จักรวาลนั้นคงต่างจากตอนนี้โดยสิ้นเชิง ถ้าใช้วิศวกรเพิ่มอีกหนึ่งคนกับ optimization ก็หมายความว่าวิศวกรพัฒนาฟีเจอร์ลดลงหนึ่งคน เพื่ออะไร? เพื่อประหยัด CPU cycle ไม่กี่รอบ? ให้ความรู้สึกว่าน่าขำ
ถ้าดูแค่ชื่อเรื่อง ผมนึกว่า Carmack กำลังวิจารณ์ซอฟต์แวร์ที่ไม่ได้รับการปรับแต่งประสิทธิภาพอย่างเหมาะสม และเรียกร้องให้ปรับปรุงประสิทธิภาพบนฮาร์ดแวร์เก่า
แต่ทวีตจริง ๆ ไม่ใช่ทั้งสองอย่างเลย เป็นการพูดถึงการทดลองทางความคิดที่ความก้าวหน้าของฮาร์ดแวร์หยุดชะงัก แล้วสรุปว่า “หากไม่มีคอมพิวติ้งที่ขยายขนาดได้ในราคาถูกมาก ผลิตภัณฑ์ใหม่ที่เป็นนวัตกรรมก็ย่อมจะเกิดขึ้นน้อยลงมาก”
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
ผมกลับมองว่าในช่วง 18 ปีหลังสมาร์ตโฟน เราแทบไม่เห็นนวัตกรรมใหญ่ ๆ เท่าไร และเป็นเพราะทุนพึ่งพา ความก้าวหน้าของฮาร์ดแวร์ เพื่อขายผลิตภัณฑ์ที่โดยสาระแล้วเหมือนกับสิ่งที่ผู้บริโภคมีอยู่แล้ว
แน่นอนว่าหลังทวีตแรกผมอ่านต่อไม่ได้
จะมีช่วงชะงักงัน แต่ไม่ใช่ความชะงักงันถาวร
ถ้าสามารถจ้างคนด้วยภาษาที่ซับซ้อนน้อยกว่าแล้วทำให้พวกเขามีผลิตภาพได้ ตลาดแรงงานก็จะกว้างขึ้นและต้นทุนลดลง
ในต้นฉบับ Carmack โดยสาระแล้วกำลังเสนอว่า “นักพัฒนาที่ดีและฉลาดมีราคาแพง และยังมีงานที่ใหญ่กว่าให้ทำ จึงไม่จ่ายเงินให้พวกเขาปรับแต่งโค้ดและระบบจนสุดทาง ซอฟต์แวร์เลยช้า”
ดังนั้นจึงมีนัยว่า หากนักพัฒนาที่ดีจู่ ๆ มีราคาถูกมาก ทุกคนก็จะซื้อพวกเขามาใช้กับงานปรับแต่งประสิทธิภาพ และซอฟต์แวร์จำนวนมากอาจเร็วขึ้นทันที ถ้าอย่างนั้น ทำไมนักพัฒนาที่ดีจึงอาจถูกปล่อยออกมาในราคาถูกได้อย่างกะทันหัน?
คงจะดีถ้ายืดอายุฮาร์ดแวร์ออกไปได้อีก 5 ปี, 10 ปี หลังจาก “การทำให้ล้าสมัยโดยวางแผนไว้”
แบบนั้นจะลดขยะอิเล็กทรอนิกส์ได้มาก เก็บแร่หายากไว้ใต้ดิน และลดการปล่อยก๊าซเรือนกระจกได้อย่างมาก
แต่แรงตลาดของการผลิตซอฟต์แวร์ไม่ได้จ่ายต้นทุนให้ผลกระทบภายนอกแบบนั้น การรีบออกสินค้า ทดสอบ และทำซ้ำ ถูกกว่าการวางแผนและออกแบบเพื่อประสิทธิภาพมาก บางองค์กรในอุตสาหกรรมเกมพบสูตรที่ได้ทั้งประสิทธิภาพดีและยอดขาย แต่ก็ไม่ได้แพร่กระจายอย่างสม่ำเสมอ
ในซอฟต์แวร์สำหรับองค์กรและผู้บริโภค แรงจูงใจที่จะใส่เกณฑ์ด้านประสิทธิภาพไว้ในข้อกำหนดไม่ได้มากนัก ออกแบบให้อยู่ในระดับที่ผู้ใช้ทนได้ และต้องปล่อยการเปลี่ยนแปลงกับฟีเจอร์ต่อไปเรื่อย ๆ จึงเผื่อพื้นที่ไว้ให้มากที่สุด การเปลี่ยนแปลงทุกอย่างเป็นหนี้ที่อาจกระทบประสิทธิภาพและความพึงพอใจของผู้ใช้ จึงต้องกันงบเผื่อรับอัตราความผิดพลาด
ต่างจากวิธีแบบเดิมที่ออกแบบและพัฒนาอยู่หลังประตูปิด “จนกว่าจะพร้อม” มาก
เราควรมีเศรษฐกิจที่เน้นการดูแลและบำรุงรักษา และปรับความพยายามระดับมหภาคให้สอดคล้องกับประโยชน์ของมนุษยชาติทั้งหมด ไม่ใช่ความมั่งคั่งที่ถูกรับรู้โดยคนส่วนน้อย
ถ้าเราโฟกัสกับการดูแลรักษารถเก่า การนำคอมพิวเตอร์เก่ากลับมาใช้ใหม่ ฯลฯ หลุมฝังกลบเมื่อเทียบกับการเติบโตก็คงเล็กกว่านี้
แน่นอนว่าอาจมีการวางโครงแบบทฤษฎีเกมที่แสดงให้เห็นว่านักอนุรักษ์นิยมเป็นกลยุทธ์ที่ด้อยกว่าอย่างเป็นปรนัยก็ได้
เป็นเวลากว่า 10 ปีแล้วที่สามารถรัน order matching engine ของทั้งตลาดซื้อขายบนเธรดเดียวได้
ผมคิดว่าความสามารถในการคำนวณบางประเภทอย่างการประมวลผลธุรกรรมที่ต้องเรียงลำดับอย่างเคร่งครัด ไม่ได้เติบโตเร็วเท่าที่ตัวชี้วัดอื่น ๆ บ่งชี้ การเพิ่มคอร์อีก 31 คอร์ไม่ได้ทำให้ order matching engine เร็วขึ้น และอาจทำให้ช้าลงด้วยซ้ำ
ถ้าผลิตภัณฑ์กำลังมองหาคลัสเตอร์เครื่องทั้งที่ประมวลผลธุรกรรมได้น้อยกว่าหลายล้านรายการต่อวินาที ก็ควรถอยกลับไปสัก 15 ขั้นแล้วเริ่มใหม่ตั้งแต่ต้น
แค่การออกแบบเดิมก็ยังตอบโจทย์ 99% ของกรณีใช้งานได้อยู่แล้ว และเมื่อพิจารณาความสามารถในการประมวลผลในเครื่องสมัยนี้ ก็อาจรันทั้งตลาดบนเครื่องเดียวได้ด้วยซ้ำ
เป็นเพราะนอกจากการเรียงตามเวลาและราคาแล้ว ไม่มีการคำนวณอื่นมากพอหรือเปล่า?
ถ้าต้องทำการประมวลผลที่ซับซ้อนกว่านี้ในแต่ละธุรกรรม ก็คงไม่สามารถรองรับปริมาณมากขนาดนั้นได้ แต่ถ้าไม่ใช่คนในโดเมนนั้น ก็ยากจะจินตนาการว่าการประมวลผลที่ซับซ้อนกว่านั้นจำเป็นอย่างไร
พูดถูก นี่คือ ปัญหาทางเศรษฐกิจ หรือก็คือปัญหาการจัดสรรทรัพยากร
เป็นการเลือกว่า จะให้ใครสักคนใช้เวลากับการปรับแต่งซอฟต์แวร์ให้เหมาะสมมากขึ้น หรือให้เขาสร้างฟีเจอร์เพิ่มมากขึ้น ถ้าอย่างหลังทำเงินสดได้มากกว่า ก็จะให้ทำอย่างนั้น และถ้าอย่างแรกสำคัญต่อกระแสเงินสด ก็จะให้ทำอย่างนั้น
นี่เป็นตัวอย่างชัดเจนของ ผลกระทบภายนอกเชิงลบ ที่บริษัทซอฟต์แวร์ผลักภาระให้สาธารณะ บริษัทซอฟต์แวร์ส่วนใหญ่ไม่ได้จ่ายต้นทุนที่แท้จริงของพลังงาน เวลาที่สูญเสียไป และขยะอิเล็กทรอนิกส์เพิ่มเติม จึงไม่สนใจการปรับแต่งประสิทธิภาพ
หลายครั้งการปรับแต่งประสิทธิภาพอย่างละเอียดก็ไม่ได้มีความหมายมากนัก แต่แนวคิดที่ว่าแทนที่จะเขียนใหม่ก็แค่เพิ่มเซิร์ฟเวอร์เข้าไปอีก เป็นสภาพที่น่าเศร้า
ฟีเจอร์ใหม่ส่วนใหญ่ของ macOS, Windows, Android ผมไม่ได้ใช้ สิ่งที่ต้องการคือสภาพแวดล้อมที่มีประสิทธิภาพสำหรับรันแอป และการปรับปรุงด้านความปลอดภัย การปรับปรุงหลายอย่างอย่างแอป Settings ของ macOS ก็ไม่ได้ถูกใจนัก
ซอฟต์แวร์ออกแบบก็เช่นกัน ฟีเจอร์ใหม่ส่วนใหญ่ที่ Adobe ใส่มาผมไม่ได้ใช้ และผมคงมีความสุขได้พอ ๆ กันกับ Illustrator หรือ Photoshop เมื่อ 10 ปีก่อน สิ่งที่ต้องการคือซอฟต์แวร์ที่บวมน้อยลง
ในงานเสียงและการผลิตเพลง เวิร์กโฟลว์ยังอยู่ระหว่างการพัฒนา ผมจึงอยากได้ฟีเจอร์ใหม่ แต่ไม่ใช่ถึงขั้นต้องแลกกับประสิทธิภาพ
สำหรับตัวแก้ไขโค้ด ฟีเจอร์ของ VSCode ก็เพียงพอแล้ว ไม่ต้องการอะไรเพิ่ม อยากได้ LSP ที่ดีกว่า แต่ไม่ใช่แกนหลักของตัวแก้ไข แค่หวังว่า VSCode จะเร็วขึ้นและกินหน่วยความจำน้อยลง
การปรับแต่งประสิทธิภาพซอฟต์แวร์ก็มีเสน่ห์คล้ายกัน แต่ถ้าปัญหาคือระหว่าง “ใช้เวลาเอนจิเนียริ่งราคาแพงหลายชั่วโมงเพื่อปรับแต่ง” กับ “ใส่ RAM ราคาถูกเพิ่ม” ทางเลือกที่ถูกกว่าจะชนะ บางครั้งปัญหาใหญ่พอจนคุ้มค่าที่จะปรับแต่ง
ตลาดจะเป็นตัวตัดสินว่าทางเลือกใดน่าตามหา เมื่อถึงจุดผลตอบแทนลดลงจากการโยนฮาร์ดแวร์เพิ่มเข้าไป ก็จะหันมาปรับแต่งซอฟต์แวร์ กฎของมัวร์ กำลังช้าลง แต่ดูเหมือนว่ายังไม่ถึงจุดนั้น
แต่ความเป็นจริงกลับใกล้เคียงกับฝั่งตรงข้ามมากกว่า ถ้าป้ายราคาถูกลง ผู้คนก็น่าจะชอบเวอร์ชันที่ประสิทธิภาพต่ำกว่าด้วย
ไม่เชิงเป็นการโต้แย้ง Carmack แต่มีตัวอย่างเฉพาะที่ผมนึกถึงเป็นครั้งคราว
แอป Electron อยู่กึ่งกลางระหว่างสิ่งที่ผู้บริโภคยอมทนเพราะปัญหาประสิทธิภาพกับสิ่งที่ถูกเกลียดชัง แต่ก็อาจเป็นนวัตกรรมเดียวที่ทำให้การใช้โน้ตบุ๊ก Linux ในที่ทำงานเป็นเรื่องปฏิบัติได้จริง เช่น การเข้าร่วมประชุม MS Teams ได้โดยไม่ต้องติดตั้งอะไรนั้นมีประโยชน์จริง ๆ
ดังนั้นทุกคนจึงคร่ำครวญว่าสมัยนี้ไม่มีอะไรที่เขียนโค้ดแน่นหนาเหมือน Winamp แต่กลับลืมตัวอักษรสามตัวข้างหน้าไป
มันมีโอกาสพอสมควรที่จะรันบน Linux ได้ด้วย แต่ซอฟต์แวร์ Electron แย่ในทุกแพลตฟอร์ม
ในปี 2010 ผมทำงานเป็นพนักงานทำความสะอาด และรับงานผู้รับผิดชอบ IT เป็นงานเสริมไปด้วย
ตอนนั้นผมบอกบริษัทว่าโน้ตบุ๊กในช่วง 5 ปีที่ผ่านมา หรือประมาณรุ่นหลัง Nehalem ก็มีประสิทธิภาพเพียงพอสำหรับงานสเปรดชีตแล้ว สิ่งที่พวกเขาทำแทบทั้งหมดก็มีแค่นั้น และแค่ 2 คอร์, RAM 16GB, SATA SSD 500GB ก็พอแล้ว มีแค่ฝ่ายการตลาดไม่กี่คนที่ต้องการเครื่องแรงขึ้นเล็กน้อย แต่ก็ไม่ได้ต่างกันมาก และพวกเขาประหยัดเงินได้มากเพราะไม่ซื้อโน้ตบุ๊กระดับท็อปรุ่นล่าสุด
ตอนนี้ผมไม่ได้ทำงานที่นั่นแล้ว แต่ยังมั่นใจว่าทุกวันนี้คอมพิวเตอร์เหล่านั้นก็ควรยังยอดเยี่ยมพอสำหรับงานสเปรดชีต เวิร์กโฟลว์ไม่ได้เปลี่ยนไปมาก สิ่งที่เปลี่ยนคือซอฟต์แวร์ ถ้าอัปเดตต่อเนื่องมาเรื่อย ๆ ก็ไม่รู้เหมือนกันว่าตอนนี้จะ “รัน” MS Windows 10 หรือ 11 ได้ไหม แต่ความบวม และโดยเฉพาะ สเปรดชีตแบบออนไลน์เท่านั้น น่าจะทำให้ประสิทธิภาพการทำงานตกลงอย่างมาก
อินเทอร์เน็ตของที่นั่นก็แย่มาก ตัวเลือกมีแค่ DSL ไม่สมมาตรราว 16Mbit ราคาเดือนละ 300 ดอลลาร์เพราะอ้างว่าเป็น “ธุรกิจ” หรือเคเบิล Comcast 120Mbit ราคาเดือนละ 500 ดอลลาร์ แม้ 120Mbit ก็แค่พอประคองสเปรดชีตแบบออนไลน์เท่านั้น ส่วน 16Mbit นั้นไม่พอแน่นอน ที่แย่กว่านั้นคือถ้าอินเทอร์เน็ตล่ม ธุรกิจก็หยุดชะงัก
นี่แหละคือตัวตนที่แท้จริงของการขโมยที่คอมเมนต์อื่นพูดถึง และผมเห็นด้วยอย่างยิ่ง โน้ตบุ๊กในสำนักงานที่ใช้แก้ไขและอัปเดตสเปรดชีต ไม่มีเหตุผลใดเลยที่จะต้องพึ่งอินเทอร์เน็ต หรือทรัพยากรคำนวณ/จัดเก็บข้อมูลที่เกินเหตุ หรือแบนด์วิดท์ขนาดใหญ่
ประสิทธิภาพอันย่ำแย่ของคอมพิวเตอร์ในปัจจุบันไม่มีข้อแก้ตัวอื่นใด นอกจากการผลักต้นทุนไปให้ลูกค้า ทั้งบุคคลทั่วไปและบริษัท
https://news.ycombinator.com/item?id=43971960
โลกไม่ได้ขับเคลื่อนด้วยซอฟต์แวร์ที่งดงาม รวดเร็ว และไร้บั๊ก แต่ขับเคลื่อนด้วย ฟีเจอร์
สำหรับผู้ใช้ปลายทาง การไม่มีฟีเจอร์กับการมีบั๊กไม่ได้ต่างกันเลย การที่ประสิทธิภาพแย่จนต้องใช้เวลา 5 นาทีเพื่อทำงานหนึ่งให้เสร็จ กับการไม่มีฟีเจอร์จนผู้ใช้ต้องทำสิ่งเดียวกันด้วยมือเป็นเวลา 5 นาที ก็ไม่ได้มีความแตกต่างที่มีนัยสำคัญ ทั้งคู่คือ “ช้า”
หากยังคงเพิ่มมูลค่าให้ผู้ใช้ปลายทางให้สูงสุดต่อไป ก็ย่อมลงเอยด้วยการสร้างซอฟต์แวร์ที่ช้าและเต็มไปด้วยบั๊กอย่างหลีกเลี่ยงไม่ได้ ยิ่งไปกว่านั้น หากถามผู้ใช้ว่าต้องการฟีเจอร์ที่น้อยลงเพื่อแลกกับความเร็วที่มากขึ้นและบั๊กที่น้อยลงไหม น่าแปลกที่คำตอบคือไม่ ที่สำคัญกว่านั้น ในโลกธุรกิจ ผู้ซื้อซอฟต์แวร์มักไม่ใช่ผู้ใช้ปลายทาง และพวกเขาต้องการฟีเจอร์มากกว่า ต้องการประสิทธิภาพและความงดงามน้อยกว่า
หากชุดฟีเจอร์เหมือนกัน ผู้ใช้และผู้ซื้อก็จะเลือกซอฟต์แวร์ที่เร็วที่สุด บั๊กน้อยที่สุด และงดงามที่สุด แต่ถ้าขาดฟีเจอร์ไปแม้เพียงหนึ่งอย่าง ก็แพ้ เหตุผลที่ต้องรักษาซอฟต์แวร์ให้รวดเร็วและงดงามไว้ คือการทำเช่นนั้นทำให้มีโอกาสสูงที่สุดที่จะเพิ่มฟีเจอร์ต่อไปได้โดยไม่กลายเป็นผลิตภัณฑ์ที่มีฟีเจอร์น้อยกว่า
วิธีแก้ปัญหาที่รวดเร็วและงดงามอาจได้รับรีวิวดี ๆ และคำชมว่าใช้งานแล้วรู้สึกดี จึงอาจดูเหมือนเป็นปัจจัยสำคัญ แต่สุดท้ายแล้ว หากทำสิ่งที่ต้องการไม่ได้ ก็จะไม่ซื้อเลย ถ้ามีฟีเจอร์หลักที่จำเป็นอยู่ ก็จะเลือกซอฟต์แวร์ที่ช้า น่าหงุดหงิด และเต็มไปด้วยบั๊กอย่างเละเทะ
ควรจำไว้ด้วยว่า ตอนนี้ Microsoft ต้องลากผู้ใช้ไปยัง Windows เวอร์ชันถัดไปทั้งที่พวกเขาเตะถีบและร้องโวยวาย ถ้าปล่อยให้ผู้ใช้ตัดสินใจเอง หลายคนคงไม่อัปเกรดหลังจาก Windows XP แล้ว แม้เวอร์ชันหลังจากนั้นจะมีฟีเจอร์ใหม่สวย ๆ มากมายก็ตาม
เห็นด้วยว่าบริษัทและนักลงทุนต้องการตัวฟีเจอร์เอง แต่ผู้ใช้นั้นไม่ใช่อย่างแน่นอน
ถ้าเป็นไปได้ คงไม่มีใครอัปเกรดอะไรอีกต่อไปแล้ว แค่ดูว่า Microsoft พยายามหนักแค่ไหนในการทำให้คนอัปเกรดก็พอ ไม่เคยได้ยินใครบอกว่าอยากได้ Windows, Office, Slack, Zoom ฯลฯ เวอร์ชันใหม่เลย
นี่ก็เป็นเหตุผลที่ทุกอย่างอย่าง Photoshop ถูกบังคับให้ขึ้นคลาวด์ คนส่วนใหญ่ไม่ได้ต้องการฟีเจอร์ใหม่ที่นำเสนอ รวมถึงผู้ซื้อในองค์กรด้วย คำตอบในการรักษารายได้คือทำให้ผู้คนต้องซื้อ ไม่ว่าจะมีฟีเจอร์ให้หรือไม่ก็ตาม
อย่างไรก็ตาม ผู้ใช้เดิมกำลังทำสิ่งที่ต้องการด้วยซอฟต์แวร์อยู่แล้ว ดังนั้นฟีเจอร์ใหม่อาจทำให้เลิกใช้ซอฟต์แวร์อื่นได้ หรือทำให้ทำสิ่งใหม่ ๆ ได้ แต่ถ้ามันเป็นงานใหม่ที่สำคัญอย่างมหาศาลจริง ๆ ก็น่าจะไปหาซอฟต์แวร์อื่นมาใช้แล้ว และนั่นหมายความว่าจนถึงตอนนี้ก็ยังอยู่ได้โดยไม่มีมัน ดังนั้นถ้าผู้ใช้เดิมใคร่ครวญจริง ๆ ฉันคิดว่าพวกเขาจะเรียกร้องการปรับปรุงประสิทธิภาพก่อน และอาจต้องการการปรับปรุงเล็ก ๆ น้อย ๆ อีกไม่กี่อย่าง
ในทางกลับกัน ผู้ใช้ที่เป็นไปได้ยังไม่รู้จักซอฟต์แวร์ หรือก่อนจะรู้สึกว่ามันมีประโยชน์ พวกเขาต้องการฟีเจอร์อื่นบางอย่าง คนกลุ่มนี้แหละคือฝ่ายที่มองหาฟีเจอร์ใหม่อย่างสมเหตุสมผล
ดังนั้นการตัดสินใจเรื่อง “ฟีเจอร์ vs ประสิทธิภาพ” จึงเป็นสัญญาณด้วยว่าลำดับความสำคัญของนักพัฒนาคือการเพิ่มผู้ใช้ใหม่หรือทำให้ผู้ใช้เดิมพึงพอใจ เป็นธรรมดาที่คนสายเทคนิคจะชอบอย่างหลัง เพราะพวกเขาเคยเล่นเกมนี้มาแล้ว และรู้ว่าตนอยากเป็นลำดับความสำคัญในช่วงเวลาที่ใช้งานจริงอย่างยาวนาน ไม่ใช่แค่ในช่วงที่กำลังถูกดึงมาเป็นผู้ใช้
การที่ซอฟต์แวร์ซึ่งบั๊กเยอะและช้าแต่ฟีเจอร์แน่นครองตลาด ก็เป็นเพราะบริษัทให้ความสำคัญกับการเติบโตก่อน ประวัติศาสตร์เต็มไปด้วยซอฟต์แวร์ที่สวยงามและงดงามซึ่งผู้ใช้คิดถึง แต่ไม่ได้แพร่หลายมากพอให้บริษัทอยู่รอดต่อไปได้
การแลกเปลี่ยนมีอยู่จริงทั้งสองทาง คนส่วนใหญ่ใช้เวลาอยู่ในฐานะผู้ใช้มากกว่าในฐานะผู้ใช้ที่เป็นไปได้ นี่น่าจะเป็นสาเหตุสำคัญของความรู้สึกทั่วไปในทุกวันนี้ว่าซอฟต์แวร์และคอมพิวเตอร์แย่จนน่าเหลือเชื่อ
เงินที่ใช้กับ RAM และ CPU ที่ดีกว่าสำหรับคอมพิวเตอร์ในบ้านและสำนักงาน ช่วยให้ซอฟต์แวร์ทั้งหมดที่รันอยู่บนนั้นสามารถออกสู่ตลาดได้ในราคาถูกลงและมีฟีเจอร์มากขึ้น