- บทบาทโดยเนื้อแท้ของซอฟต์แวร์ คือการรู้ให้ชัดว่าปัญหาที่ตัวเองต้องแก้คืออะไร และตระหนักถึงขีดจำกัดของตัวเอง
- ซอฟต์แวร์ที่ดีจะไม่พยายามใส่ทุกฟีเจอร์เข้าไป, แต่จะจัดการเฉพาะส่วนที่จำเป็นต้องปรับปรุง และไม่หลุดออกจากวัตถุประสงค์
- ยกตัวอย่างสมมติที่คำสั่ง
ls ถูกแทนที่ด้วยฟีเจอร์ AI เพื่อ เสียดสีปรากฏการณ์ที่เครื่องมือเดิมถูกขยายเกินความจำเป็น
- อ้างอิงหลักการจาก ‘Getting Real’ และ ‘Rework’ ของ 37Signals เพื่อเน้นว่าควรมองข้อจำกัดเป็นข้อได้เปรียบ และปฏิเสธคำขอฟีเจอร์ที่ไม่จำเป็น
- ท่ามกลางกระแส AI ยังเป็นการเตือนว่า ความเสถียรของมาตรฐานเดิมและการนิยามปัญหาอย่างชัดเจน มีคุณค่ามากกว่าเทรนด์ใหม่
บทบาทและขีดจำกัดของซอฟต์แวร์
- บทความเริ่มต้นด้วยฉากสมมติหลังอัปเดตลินุกซ์ดิสโทรแล้วคำสั่ง
ls ถูกเปลี่ยนเป็น AI-based directory intelligence
- คำสั่งใหม่
als จะคาดเดาความตั้งใจของผู้ใช้ จัดอันดับไฟล์ และแสดงข้อความว่า ls เดิมจะหยุดการสนับสนุนในอีก 30 วัน
- ฉากนี้เป็นตัวอย่างการเสียดสี ฟีเจอร์ล้นเกินและนวัตกรรมที่ไม่จำเป็น
- พร้อมย้ำว่า “โชคดีที่เรื่องแบบนี้ไม่ได้เกิดขึ้นจริง” และ ซอฟต์แวร์ที่ดีรู้ว่าตัวเองควรหยุดเมื่อไร
หลักการสำคัญของซอฟต์แวร์ที่ดี
- ซอฟต์แวร์ที่ดีรู้ว่า ตัวเองมีไว้เพื่อทำอะไร ไม่พยายามทำทุกอย่าง และแยกให้ออกว่าอะไรคือจุดที่ควรหยุดกับอะไรคือจุดที่ควรปรับปรุง
- แนวคิดแบบสุดโต่ง ของมนุษย์มีแนวโน้มจะทำให้ทุกอย่างใหญ่ขึ้นและซับซ้อนขึ้น
- แต่ซอฟต์แวร์ควร นิยามบทบาทและตำแหน่งของตัวเองให้ชัดเจน และหากไอเดียใหม่ไม่สอดคล้องกับวิสัยทัศน์เดิม ก็ควร แยกออกไปเป็นโปรเจกต์ต่างหาก
ปรัชญาการสร้างผลิตภัณฑ์ของ 37Signals
- ‘Rework’ และ ‘Getting Real’ ที่ผู้ก่อตั้ง Basecamp เขียนไว้ มอบบทเรียนสำคัญต่อการออกแบบผลิตภัณฑ์
- ข้อจำกัดคือข้อได้เปรียบ (Constraints are advantages): ทีมเล็ก งบจำกัด และขอบเขตจำกัด ช่วยนำไปสู่การตัดสินใจที่ดีกว่า
- เพิกเฉยต่อคำขอฟีเจอร์ (Ignore feature requests): แทนที่จะทำตามฟีเจอร์ที่ผู้ใช้ร้องขอโดยตรง ควร ทำความเข้าใจปัญหารากฐาน ให้ได้ก่อน
- ปล่อยให้เร็ว ปล่อยบ่อย (Ship early, ship often): ผลิตภัณฑ์ที่ยังไม่สมบูรณ์แต่ใช้งานได้จริง มีค่ามากกว่า ผลิตภัณฑ์ที่สมบูรณ์แบบแต่ไม่เคยปล่อย
- ออกแบบจากแกนกลาง (Epicenter design): ควรออกแบบจาก อินเทอร์เฟซหลักและปฏิสัมพันธ์หลัก ก่อนระบบนำทางหรือองค์ประกอบรอบข้าง
- ให้คำตอบเป็น ‘ไม่’ โดยปริยาย (Say no by default): ฟีเจอร์ใหม่มีต้นทุนแฝงคือ ความซับซ้อน ค่าบำรุงรักษา และการจัดการกรณียกเว้นที่เพิ่มขึ้น
- สร้างสิ่งที่ตัวเองต้องการใช้ (Scratch your own itch): ผลิตภัณฑ์ที่แก้ ปัญหาที่ตัวเองต้องการแก้จริงๆ จะนำไปสู่การตัดสินใจที่ดีกว่า
คุณค่าของความต่อเนื่องมากกว่าความเปลี่ยนแปลง
- ช่วงหลังมานี้มีแนวโน้มที่หลายผลิตภัณฑ์จะ ปรับชื่อและฟังก์ชันใหม่โดยมี AI เป็นศูนย์กลาง
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- ไม่ใช่ว่าทุกอย่างจำเป็นต้องเปลี่ยนแปลงอย่างหวือหวาเสมอไป
- การกลายเป็น มาตรฐานโดยพฤตินัย (de facto standard) ในขอบเขตปัญหาเฉพาะด้านนั้น มีคุณค่ามากกว่า
1 ความคิดเห็น
ความเห็นจาก Hacker News
พอเห็นคำแนะนำที่ว่า “จงเมินคำขอฟีเจอร์” ก็ทำให้นึกถึงกรณีของ Blizzard และ World of Warcraft Classic
ตลอดหลายปีที่ผ่านมา ผู้เล่นเรียกร้องเวอร์ชันคลาสสิก แต่ Blizzard ปฏิเสธโดยบอกว่า “พวกคุณไม่ได้ต้องการสิ่งนั้นหรอก”
สุดท้ายก็เปิดตัว WoW Classic และมันก็ ประสบความสำเร็จอย่างถล่มทลาย
ภายหลังทีมพัฒนายอมรับว่า “ผู้เล่นรู้จริง ๆ ว่าตัวเองต้องการอะไร”
ดังนั้น แทนที่จะเมินคำขอฟีเจอร์เสมอไป ก็ควรยอมรับว่าบางครั้งผู้ใช้ก็อาจถูกต้องอย่างแม่นยำ
ตรงกันข้าม ถ้าเป็น ผู้ใช้ที่หยาบคายหรือเห็นแก่ตัว ตัวบทสนทนาเองก็ชวนให้เหนื่อยจนไม่อยากตอบ
สุดท้ายบทเรียนก็คือ เวลาจะขออะไรควรทำอย่างมีมารยาท
หลังจากนั้นค่อยตัดสินว่านั่นเป็นคำขอที่ใช้ได้ไหม และจะนำไปทำอย่างไร
ปัญหาที่แท้จริงคือ ‘เกมที่สูญเสียความรู้สึกแบบดั้งเดิมไปแล้ว’ และถ้าเข้าใจจุดนี้ ก็อาจแก้ได้ด้วยวิธีอื่นที่ไม่ใช่ Classic
WoW Classic เป็นการแสดงออกของ ความต้องการตื้น ๆ ที่อยากได้ ‘อารมณ์เก่า ๆ’ กลับคืนมา แต่ลึกลงไปข้างล่างนั้นคือความไม่ไว้วางใจต่อ ‘ทิศทางการพัฒนาที่ไม่น่าเชื่อถือ’
ในโลกอุดมคติ เราอาจสร้างรูปแบบสมบูรณ์แบบที่ผสมข้อดีของทั้งสองเวอร์ชันได้ แต่ในโลกจริงก็คงมีแต่ความขัดแย้งของความเห็นจนยิ่งสับสน
พอเพิ่มอินสแตนซ์แบบไม่ใช่ PVP ตามคำขอผู้ใช้ ความตึงเครียดก็หายไป ทำให้เกมจืดชืดลง
กรณีนี้จึงกลายเป็นว่านักพัฒนารู้ดีกว่าผู้ใช้
คิดว่าควรมี ซอฟต์แวร์ที่เสร็จสมบูรณ์และหยุดเพิ่มฟีเจอร์ ให้มากกว่านี้
เราต้องมีความกล้าที่จะพูดว่า “แค่นี้ก็พอแล้ว”
มีหลายกรณีอย่าง Evernote หรือ Dropbox ที่หลังจากช่วงเวลาสมบูรณ์แบบแล้วกลับสับสนเพราะ ฟีเจอร์มากเกินไป
มันถูกขายเป็นกล่อง และถ้ามีเวอร์ชันใหม่ก็ต้องซื้อกล่องใหม่
นั่นคือยุคก่อนเว็บแอปที่อัปเดตกันอย่างไม่สิ้นสุดแบบทุกวันนี้
แถมหลายครั้งยิ่งอัปเดตก็ยิ่งแย่ลง
ผลิตภัณฑ์ที่ดีขึ้นจริง ๆ มีน้อยมากจนนับได้
สุดท้ายก็กลับไปสร้างปัญหาเดิมที่ตั้งใจจะแก้แต่แรก
แต่เมื่อเวลาผ่านไป มันไม่รองรับ iOS เวอร์ชันใหม่และสุดท้ายก็ใช้งานไม่ได้
มันทำให้รู้สึกทั้งถึงความงามของความสมบูรณ์ และความโหดร้ายของวิวัฒนาการทางเทคโนโลยีไปพร้อมกัน
ตอนที่ย้ายจากงานอินฟรามาเป็น นักพัฒนา Java ในปี 2020 ผมเห็นว่าไลบรารีหลักหลายตัวอยู่ในโหมดบำรุงรักษา เลยคิดว่า “Java ตายแล้วหรือเปล่า?”
แต่ภายหลังถึงได้รู้ว่านั่นคือสภาวะ ฟังก์ชันครบสมบูรณ์
มันเป็นสภาพที่มั่นคงและผ่านการแก้ edge case มานับไม่ถ้วนแล้ว
ปัญหาคือผู้คนไม่ได้ต้องการความมั่นคงแบบนั้น แต่ต้องการของใหม่อยู่เสมอ
สุดท้ายก็สร้างเฟรมเวิร์กเดิมซ้ำไปซ้ำมา แค่เปลี่ยนภาษาเท่านั้น
เลยชอบโปรเจกต์ที่ยังพัฒนาต่อเนื่องมากกว่า
อีกทั้งบางบริษัทก็ใช้ได้เฉพาะซอฟต์แวร์ที่ยังมีอัปเดตต่อเนื่องเพราะ ข้อกำหนดด้าน compliance
ตอนนั้นล้อกันว่า “มันก็แค่เสร็จสมบูรณ์แล้ว เลยไม่มีอะไรให้ปรับปรุงอีก” แต่สุดท้ายก็เปลี่ยนอยู่ดี
เหตุผลที่ชอบ Sublime Text คือความเรียบง่ายและความเร็ว
มันไม่ใส่ AI หรือฟีเจอร์ซับซ้อน แต่โฟกัสกับ เป้าหมายเดียว
ซอฟต์แวร์ที่ดีไม่จำเป็นต้องเป็นซอฟต์แวร์ที่ทำเงิน
แต่ถ้าจะทำเงิน ก็ต้องมีฟีเจอร์ที่ผู้คนใช้งานจริง
เพราะผู้ใช้แต่ละคนใช้ ฟีเจอร์อีก 20% ที่ต่างกันไป ดังนั้นจึงต้องคำนึงถึงความหลากหลาย
ผมเคยคิดว่า Notepad.exe เป็นตัวอย่างคลาสสิกของซอฟต์แวร์ที่เสร็จสมบูรณ์แล้ว
แต่กลับตกใจที่บน Windows 11 การเปลี่ยน file association ต้องใช้ การงัดแงะระดับแฮ็ก
ดูจาก บล็อก Windows Insider และ
ประกาศด้านความปลอดภัย
ก็จะเห็นว่าปัญหาคือการอัปเดตที่ไม่รู้จักหยุด
ผมยอมรับใน ความงามของซอฟต์แวร์ที่เสร็จสมบูรณ์แล้ว แต่ทุกวันนี้ส่วนใหญ่กลับอยู่ในสภาพ “เบต้านิรันดร์”
เมื่อการเชื่อมต่ออินเทอร์เน็ตกลายเป็นข้อสมมติพื้นฐาน โครงสร้างแบบ “อัปเดตได้ทุกเมื่อ” ก็เกิดขึ้น
การแก้บั๊กกับการยัดฟีเจอร์ที่ไม่ต้องการจึงไม่ถูกแยกออกจากกัน
เว็บบริการอย่าง YouTube ก็เลือกเวอร์ชันไม่ได้เลยด้วยซ้ำ
โดยเฉพาะเมื่อเพิ่ม ฟีเจอร์ Canvas เข้ามา ปรัชญาความเรียบง่ายดั้งเดิมก็เริ่มสั่นคลอน
ถ้ามันเป็นโอเพนซอร์ส ตอนนั้นผมอาจ fork มันไปแล้วก็ได้
Signal ฟรี เป็นโอเพนซอร์ส และเน้นความเป็นส่วนตัว จึงมีฟีเจอร์ไม่มาก
แต่นั่นกลับเป็นสิ่งที่ผมชอบ
ส่วน WhatsApp กลับเพิ่มแต่ฟีเจอร์ที่ไม่จำเป็น
แต่ก่อนผมไม่เข้าใจความสำคัญของแนวคิด ‘สิ่งที่จำเป็นเสมอ (evergreen)’ จากหนังสือของ 37signals โดยเฉพาะเรื่อง ความเร็ว
แต่พอเวลาผ่านไปแล้วเห็นว่าแอปต่าง ๆ ช้าลงเรื่อย ๆ ก็ยิ่งตระหนักว่าซอฟต์แวร์ที่เร็วมีคุณค่ามากแค่ไหน
มันทำให้นึกถึงประโยคใน 『REAMDE』 ของ Neal Stephenson ที่ว่า “นักเขียนชอบชุมชนที่อยู่อาศัย”
เหมือนที่นักเขียนสร้างงานขึ้นมาเรื่อย ๆ เพื่อรักษาชุมชนที่ตัวเองอยู่ นักพัฒนาเองก็มี แนวโน้มจะเปลี่ยนโค้ดเพื่อสร้างงานให้ตัวเอง เช่นกัน
สุดท้ายพวกเราก็กำลังทำ การเปลี่ยนแปลงเพื่อการเปลี่ยนแปลง ซ้ำไปซ้ำมา