แม้ความเรียบง่ายจะมีข้อดี แต่น่าเสียดายที่ความซับซ้อนกลับขายได้ดีกว่าในโลกจริง (2022)
(eugeneyan.com)- เบื้องหลังที่วิธีการแบบเรียบง่ายมักถูกประเมินค่าต่ำในการพิจารณาบทความวิชาการหรือการประเมินเลื่อนตำแหน่ง คือ อคติที่เข้าข้างความซับซ้อน เพราะผลงานที่ซับซ้อนดูเหมือนบรรจุความพยายาม ทักษะ และนวัตกรรมไว้มากกว่า
- ระบบที่มีตัวเลือกและองค์ประกอบจำนวนมากดูยืดหยุ่น แต่ในการปฏิบัติงานจริง การอธิบาย ทดสอบ และแก้ปัญหาจะยากขึ้น และอาจทำให้ ความผิดพลาดและความไร้ประสิทธิภาพ เพิ่มขึ้น
- ไอเดียและระบบที่เรียบง่ายทำความเข้าใจ ใช้งาน รับฟีดแบ็ก และขยายต่อได้ง่าย โดยตอนที่ Instagram ถูกซื้อกิจการในปี 2012 บริษัทให้บริการผู้ใช้หลายสิบล้านคนด้วยทีม 13 คน ขณะยังคงใช้เทคโนโลยีที่พิสูจน์แล้วอย่าง PostgreSQL และ Redis
- ในแมชชีนเลิร์นนิง เทคนิคที่ซับซ้อนก็ไม่ได้เหนือกว่าเสมอไป โดยในชุดข้อมูลแบบตารางขนาดกลาง 45 ชุด โมเดลแบบ tree-based ทำได้ดีกว่า deep neural network และในงานแนะนำกับค้นหา มีกรณีที่ dot product ทำได้ดีกว่า neural collaborative filtering
- หากให้รางวัลกับความซับซ้อนในตัวมันเอง จะยิ่งส่งเสริมการทำให้ซับซ้อนโดยไม่จำเป็นและแนวโน้มแบบ not invented here ดังนั้นยิ่งปัญหาซับซ้อนเท่าไร ยิ่งควรถามก่อนว่าเป็นไปได้ไหมที่จะใช้วิธีแก้ที่เรียบง่าย และต้นทุนของความซับซ้อนนั้นสมเหตุสมผลหรือไม่
ทำไมความซับซ้อนจึงดูน่าดึงดูดกว่า
- ความซับซ้อนมักถูกมองเป็นสัญญาณของความพยายาม
- บทความวิชาการที่มีไอเดียยากและรายละเอียดทางเทคนิคมาก ดูเหมือนใช้เวลาและความพยายามมาก
- ระบบที่มีองค์ประกอบและฟีเจอร์จำนวนมากมักถูกประเมินว่าเป็นผลงานที่ตั้งใจทำมากกว่าระบบที่เล็กกว่า
- ความรู้สึกว่าทำได้ยากจึงทำหน้าที่เหมือนสัญญาณของคุณค่าและคุณภาพ
- ยังถูกตีความเป็น สัญญาณของทักษะความชำนาญ ด้วย
- ระบบที่มีชิ้นส่วนเคลื่อนไหวจำนวนมากทำให้รู้สึกว่าผู้ออกแบบมีความสามารถในการเข้าใจและผสานรวมแต่ละส่วน
- บทความที่มีศัพท์เฉพาะและบทพิสูจน์จำนวนมากอาจเข้าถึงยาก แต่ก็ดูเหมือนแสดงความเชี่ยวชาญในหัวข้อนั้นมากขึ้น
- แนวปฏิบัติในการสัมภาษณ์งานที่ถามอัลกอริทึมและโครงสร้างข้อมูลซึ่งแทบไม่ใช้ในงานจริง ก็เชื่อมโยงกับสัญญาณลักษณะนี้
- ยังมีการรับรู้ว่าเป็น สัญญาณของนวัตกรรม
- บทความที่สร้างสถาปัตยกรรมโมเดลใหม่ทั้งหมด มักถูกประเมินว่าใหม่กว่าบทความที่ปรับแก้เครือข่ายเดิม
- ระบบที่มีองค์ประกอบจำนวนมากที่สร้างขึ้นตั้งแต่ต้น ดูมีความเป็นต้นฉบับมากกว่าระบบที่นำชิ้นส่วนเดิมมาใช้ซ้ำ
- การประเมินว่า “เปลี่ยนแค่อย่างเดียว ส่วนที่เหลือเหมือนงานวิจัยเดิม” อาจลดคุณค่าของไอเดียที่เรียบง่ายลง
- ยิ่งมีฟีเจอร์มาก ก็ยิ่งเกิดภาพลวงตาว่าครอบคลุมกว่า
- ระบบที่รองรับทั้งที่เก็บข้อมูล SQL และ NoSQL หรือทำได้ทั้ง batch และ streaming pipeline ดูเหมือนครอบคลุมทุกกรณี
- ยิ่งมีบล็อกเลโก้มาก ก็ยิ่งถูกมองว่าปรับตัวรับการเปลี่ยนแปลงได้ดีกว่า
- การตัดสินเช่นนี้นำไปสู่ complexity bias หรืออคติที่ชอบสิ่งซับซ้อนมากเกินไป เมื่อเทียบกับไอเดียและระบบที่เรียบง่าย
จุดที่ความเรียบง่ายกลายเป็นข้อดีจริง
- ไอเดียและฟีเจอร์ที่เรียบง่าย เข้าใจและใช้งานได้ง่าย
- โอกาสถูกนำไปใช้และผลกระทบจริงจึงสูงขึ้น
- สื่อสารและรับฟีดแบ็กได้ง่ายขึ้นด้วย
- ระบบที่ซับซ้อนอธิบายและจัดการยาก ทำให้ผู้ใช้เข้าใจได้ยากว่าต้องทำอะไรและทำอย่างไร
- หากมีรายการให้ปรับมากเกินไป ความผิดพลาดจะเพิ่มขึ้น และหากมีขั้นตอนมากเกินไป ก็เกิดความไร้ประสิทธิภาพ
- ระบบที่เรียบง่าย สร้างและขยายได้ง่าย
- เมื่อมีองค์ประกอบน้อย การ implement ก็ง่ายขึ้น
- หากใช้เทคโนโลยีสำเร็จรูปที่เป็นมาตรฐาน ก็หาคนมาพัฒนาและบำรุงรักษาได้ง่ายขึ้น
- โค้ดและปฏิสัมพันธ์ภายในลดลง ทำให้ภาระในการทำความเข้าใจและทดสอบลดลงด้วย
- ระบบที่ซับซ้อนโดยไม่จำเป็นทำให้ต้องใช้เวลาและทรัพยากรมากขึ้นในการสร้าง จนนำไปสู่ความสูญเปล่า
- กรณีของ Instagram แสดงให้เห็นข้อดีของการเลือกเทคโนโลยีอย่างเรียบง่าย
- ตอนถูกซื้อกิจการในปี 2012 Instagram ให้บริการผู้ใช้หลายสิบล้านคนด้วยทีม 13 คน
- แทนที่จะใช้เทคโนโลยีใหม่ตามกระแส บริษัทคงเทคโนโลยีที่พิสูจน์แล้วไว้ เพื่อลดภาระปฏิบัติการต่อวิศวกรหนึ่งคน
- ขณะที่สตาร์ทอัพอื่น ๆ นำที่เก็บข้อมูล NoSQL ที่กำลังฮิตมาใช้แล้วเจอความยากลำบาก Instagram ใช้ PostgreSQL และ Redis ที่เข้าใจง่าย
ต้นทุนการดำเนินงานและความสามารถในการบำรุงรักษา
- การ deploy ระบบไม่ใช่จุดจบ แต่เป็นจุดเริ่มต้น
- ความพยายามส่วนใหญ่เกิดขึ้นหลังจากนำเข้าสู่ production
- งานปฏิบัติการมีโอกาสสูงที่จะถูกดูแลโดยคนอื่นที่ไม่ใช่ทีมที่สร้างขึ้นมาแต่แรก
- ระบบที่เรียบง่ายสามารถลดต้นทุนการบำรุงรักษาและยืดอายุการใช้งานได้
- ยิ่งมีชิ้นส่วนเคลื่อนไหวน้อย ก็ยิ่งเชื่อถือได้และซ่อมง่าย
- ส่วนที่อาจเสียหายได้ลดลง
- ปฏิสัมพันธ์ภายในน้อยลง ทำให้อัปเกรดหรือเปลี่ยนองค์ประกอบแต่ละส่วนได้ง่ายขึ้น
- ระบบที่ซับซ้อนมีองค์ประกอบจำนวนมากที่ทีมจำกัดต้องเข้าใจ จึงมีต้นทุนบำรุงรักษาสูง
- หากมีส่วนที่พึ่งพากันจำนวนมาก การแก้ปัญหาก็ยิ่งยากขึ้น
- Thomas Paine กล่าวไว้ใน 『Common Sense』 ว่า “สิ่งใดก็ตาม ยิ่งเรียบง่ายเท่าไร ก็ยิ่งมีโอกาสเสียรูปเสียระบบน้อยลง และเมื่อเสียรูปเสียระบบแล้ว ก็ยิ่งแก้ไขได้ง่ายขึ้น”
ตัวอย่างที่เทคนิคเรียบง่ายไม่ได้เป็นรอง แม้ในแมชชีนเลิร์นนิง
- เทคนิคที่ประณีตกว่าไม่ได้ให้ประสิทธิภาพดีกว่าเสมอไป
- Tree-based models > deep neural networks: ในชุดข้อมูลแบบตารางขนาดกลาง 45 ชุด โมเดลแบบ tree-based ดีกว่า deep neural network
- Greedy algorithms > graph neural networks: ในปัญหากราฟเชิงผสมผสาน greedy algorithm ดีกว่า graph neural network
- Simple averaging ≥ complex optimizers: ในปัญหา multi-task learning การเฉลี่ยแบบง่ายดีไม่น้อยกว่า optimizer ที่ซับซ้อน
- Simple methods > complex methods: ในความแม่นยำการพยากรณ์โดยรวมของบทความ 32 ฉบับ วิธีเรียบง่ายดีกว่าวิธีซับซ้อน
- Dot product > neural collaborative filtering: ในการแนะนำและค้นหาไอเท็ม dot product ดีกว่า neural collaborative filtering
ปัญหาที่เกิดขึ้นเมื่อให้รางวัลกับความซับซ้อน
- เมื่อให้รางวัลกับความซับซ้อน คนจะมีแรงจูงใจให้สร้างสิ่งที่ซับซ้อนโดยไม่จำเป็น
- วิธีหรือระบบที่เรียบง่ายอาจถูกประเมินว่ามีค่าน้อยกว่า เพียงเพราะดูง่าย
- หากทำให้ระบบซับซ้อนเพื่อให้ได้รางวัล วิธีแก้ที่เรียบง่ายที่สุดก็จะไม่ใช่ตัวเลือกที่ชัดเจนอีกต่อไป
- ความซับซ้อนก่อให้เกิดความซับซ้อนเพิ่มขึ้น และสุดท้ายอาจพาไปสู่ระดับที่ทำงานต่อไม่ได้
- แนวโน้มแบบ not invented here ก็ถูกเสริมให้แรงขึ้นด้วย
- แม้การนำองค์ประกอบเดิมมาใช้ซ้ำจะประหยัดเวลาและความพยายามได้ แต่ก็เกิดแนวโน้มอยากสร้างใหม่ตั้งแต่ต้น
- สิ่งนี้อาจทำให้เสียเวลาและทรัพยากร และนำไปสู่ผลลัพธ์ที่แย่กว่า
- ในกระบวนการเลื่อนตำแหน่งและการรีวิวบทความแมชชีนเลิร์นนิง ความซับซ้อนก็อาจถูกเน้นมากเกินไป
- Bryan Liles ชี้ว่า วิธีแก้ที่เรียบง่าย implement และขยายได้ง่ายกว่าวิธีที่ซับซ้อน แต่การเลื่อนตำแหน่งมักมอบให้คนที่สร้างวิธีแก้ที่ซับซ้อน
- Micah Goldblum กล่าวว่าในการรีวิว ML มักมีคำวิจารณ์ว่าวิธีนั้นเรียบง่ายเกินไปหรือประกอบจากชิ้นส่วนเดิม แต่ความเรียบง่ายไม่ใช่จุดอ่อน หากเป็นจุดแข็ง
- นวัตกรรมอย่าง Kalman Filters, PageRank, SVM, LSTM, Word2Vec, Dropout ก็เคยถูกปฏิเสธมาแล้ว
วิธีรับมือความซับซ้อนที่ดีกว่า
- เป้าหมายคือการแก้ ปัญหาที่ซับซ้อน ด้วยวิธีที่เรียบง่ายที่สุดเท่าที่เป็นไปได้
- ควรโฟกัสที่ความซับซ้อนของปัญหา ไม่ใช่ความซับซ้อนของวิธีแก้
- วิธีแก้ที่เรียบง่ายแสดงให้เห็นความเข้าใจลึกซึ้งต่อปัญหา และความสามารถในการหลีกเลี่ยงวิธีแก้ที่วกวนและมีต้นทุนสูงกว่า
- เชื่อมโยงกับคำกล่าวของ Albert Einstein ที่ว่า “ทุกสิ่งควรเรียบง่ายที่สุดเท่าที่เป็นไปได้ แต่ต้องไม่เรียบง่ายเกินกว่านั้น”
- อาจพิจารณาวิธีแก้หลายแบบที่มีจุดโฟกัสชัดเจน แทนวิธีแก้ซับซ้อนที่ครอบคลุมทุกอย่าง
- วิธีแก้แบบ one-size-fits-all อาจยืดหยุ่นและนำกลับมาใช้ซ้ำได้น้อยกว่าที่คาด
- เมื่อรองรับหลาย use case และผู้มีส่วนได้ส่วนเสียพร้อมกัน ระบบจะถูกผูกกันแน่น และต้องอาศัยการประสานงานมากขึ้นในการวางแผนและ migration
- ระบบที่มีวัตถุประสงค์เดียวปฏิบัติการได้ง่าย และเลิกใช้ได้ง่ายเมื่อจำเป็น
- วิธีลดอคติที่เข้าข้างความซับซ้อนคือการใช้ Occam’s razor
- เป็นหลักการที่ว่าวิธีแก้หรือคำอธิบายที่เรียบง่ายที่สุดมักถูกต้อง
- ไม่ควรรีบปัดตกไอเดียที่เรียบง่ายเร็วเกินไป หรือเพิ่มความซับซ้อนที่ไม่จำเป็นเพื่อทำให้คุณค่าดูสมเหตุสมผล
- ควรคำนึงถึงต้นทุนของความซับซ้อนและถามว่า “คุ้มค่าหรือไม่”
อคติอีกด้านหนึ่ง: การนำความซับซ้อนที่คุ้นเคยมาใช้ซ้ำ
- อีกด้านหนึ่งของ “not invented here” คืออคติที่ชอบองค์ประกอบเดิมโดยอัตโนมัติ
- เพราะรู้อยู่แล้ว จึงง่ายกว่าตามประสบการณ์ส่วนตัว และลดเวลาและความพยายามของตัวเองได้
- แต่หากองค์ประกอบเดิมนั้นซับซ้อนมากในตัวเอง ก็อาจทำให้เสียเวลาและทรัพยากรมากกว่า และได้ผลลัพธ์ที่แย่กว่าการสร้างสิ่งที่เรียบง่ายกว่าใหม่
- เมื่อไม่มีตัวเลือกที่เรียบง่าย การสร้างใหม่อาจจำเป็น
- ของที่สร้างใหม่อาจไม่ได้เรียบง่ายขึ้นจริง และกลายเป็นของอีกชิ้นที่ซับซ้อนพอ ๆ กับของเดิม
- ปัญหาบางอย่างซับซ้อนโดยธรรมชาติ และมี essential complexity ที่ไม่สามารถกำจัดได้จริง
- ORM ถูกยกเป็นตัวอย่างที่ไม่ดี
- ORM ถูกสร้างใหม่อยู่เรื่อย ๆ และตอนแรกเริ่มจากความเรียบง่าย แต่สุดท้ายความซับซ้อนก็ระเบิดออกมา
- object/relational impedance mismatch เป็นที่รู้จักกันดี และแนวคิด ORM เองก็ซับซ้อนโดยเนื้อแท้
- สิ่งที่ดูเหมือนรักษาความเรียบง่ายไว้ได้ อาจไม่ใช่ ORM แต่เป็น query builder หรือ data mapper มากกว่า
- PSR cache API เป็นตัวอย่างของความซับซ้อนที่กำจัดได้
- หลัง PSR-6 cache API ก็มี PSR-16 cache API ที่เรียบง่ายกว่าออกมา
- PSR-16 ลดความซับซ้อนและจำนวนแนวคิด ทำให้ API เล็กลงและกำหนดแนวทางน้อยลง
- การที่สามารถสร้าง PSR-6 adapter สำหรับ implement PSR-16 และ adapter ทิศทางตรงข้าม ได้ แสดงว่าความซับซ้อนที่ถูกตัดออกจาก PSR-16 ไม่ใช่สิ่งจำเป็นโดยเนื้อแท้
- ไลบรารีและเฟรมเวิร์กบางตัวอาจขยายใหญ่เกินความซับซ้อนโดยเนื้อแท้ ภายใต้ชื่อ developer experience
- ความเรียบง่ายจริงมีลักษณะที่วัดได้ด้วยตัวชี้วัด เช่น จำนวนบรรทัดโค้ด จำนวน public method และ coupling
- มีกรณีที่ไลบรารีขยายใหญ่เป็น 10 เท่าของขนาดเดิมภายในไม่กี่ปี และออก breaking change ใหญ่ทุก 6–12 เดือน
- แรงจูงใจที่มองไลบรารีซึ่งไม่เติบโตว่า “ตายแล้ว” และย้ายไปแพ็กเกจที่ “แอคทีฟ” กว่า ก็อาจเป็นอาการของอคติที่เข้าข้างความซับซ้อน
- บางครั้งการเลือกสร้างใหม่ก็จำเป็นเพื่อหลีกเลี่ยงความซับซ้อนที่แพร่กระจาย
- หากสามารถตรึงความต้องการและหลีกเลี่ยงการเติบโตแบบ scope creep ได้ implementation ใหม่อาจเป็นตัวเลือกที่เรียบง่ายกว่า
- ต้องระวังไม่ให้เสริมอคติข้างใดข้างหนึ่ง
1 ความคิดเห็น
ความเห็นจาก Hacker News
เคยทำงานที่บริษัทหนึ่งในกลุ่ม FAANG ในช่วงที่ใช้ การแก้ปัญหาที่ซับซ้อน เป็นเกณฑ์เลื่อนตำแหน่ง ยิ่งแก้ปัญหาที่ซับซ้อนได้มาก ระดับ ค่าตอบแทน และสถานะก็ยิ่งสูงขึ้น
ตามธรรมชาติแล้วผู้คนจึงเริ่มมองหาปัญหาซับซ้อนที่พอจะหยิบมาแก้ได้ และเมื่อบริษัทอื่นๆ ก็ลอกไอเดียของบริษัทนั้นตามไปด้วย สุดท้ายแม้แต่บริษัทเล็กๆ ที่ไม่จำเป็นต้องมีวิธีแก้ซับซ้อน ก็ยังมี tech stack คล้ายๆ กัน
พักหลังมานี้พอเห็น UI ของรถยนต์ โดยเฉพาะ UI ที่ซับซ้อนและใช้งานยาก ของรถ EV ก็ทำให้นึกคล้ายๆ กัน และมันถึงขั้นทำให้ผมไม่อยากซื้อรถที่ต้องพึ่งสิ่งนี้
บทสรุปคือผู้บริโภคที่มีรสนิยมเฉียบคมกับผู้บริโภคแบบโหยหาสถานะนั้นต่างกันมาก และผู้บริโภคแบบหลังมีจำนวนมากกว่ามาก
ดังนั้นการยอมสละผู้บริโภคที่มีรสนิยมเฉียบคมเพื่อไปตอบโจทย์ผู้บริโภคแบบโหยหาสถานะจึงสมเหตุสมผลในเชิงเศรษฐกิจ
ผู้บริโภคแบบโหยหาสถานะยอมรับข้อบกพร่องและภาพลวงตาราวกับเป็นสัญลักษณ์แห่งความสำเร็จในการบริโภค
พูดแบบหยาบๆ คือพวกเขาชอบการขับรถ “หรู” มากจนมองไม่เห็นขยะที่แถมมาด้วย ส่วนสำหรับคนที่ซื้อรถหรูมาหลายสิบปีแล้ว ก็แค่อยากให้คันเกียร์ดูออกง่ายๆ ก็พอ
จุดที่ต้องแตะเล็กลงมากโดยไม่มีเหตุผล ดูเหมือนนักพัฒนาจะออกแบบและทดสอบ UI บนจอที่วางอยู่บนโต๊ะนิ่งๆ หรือในรถที่ไม่เคลื่อนที่
แต่พออยู่ในรถที่กำลังวิ่ง ทุกอย่างพังหมด
รถรุ่นใหม่ที่ไม่มีคันเกียร์ ไฟเลี้ยว ที่ปัดน้ำฝน และก้านไฟ กลายเป็นความโกลาหล
ต้องนั่งหลังพวงมาลัยแล้วคอยจิ้มเป้าเล็กๆ บนจอที่ไม่มีที่ให้วางมือ ทำให้การขับแย่ลงทุกด้าน ทั้งการควบคุมทางอ้อม ความสับสน ความไม่แม่นยำ และการเสียสมาธิ
มันช่วยทำงานจุกจิกให้เป็นอัตโนมัติ เช่น ล็อกและปลดล็อก ปิดหน้าต่าง อุ่นหรือทำความเย็นล่วงหน้า ตั้งนำทางอัตโนมัติไปที่ทำงานตอนเช้าและกลับบ้านตอนเย็น รวมถึงปรับเบาะและการตั้งค่าตามโทรศัพท์ที่ใช้เป็นกุญแจ
ด้วยการเชื่อมต่อฟรี ระบบนำทางจึงใช้งานได้จริง และ GPS ในรถที่เคยใช้มาก่อนหน้านี้ไร้ประโยชน์ทั้งหมด
หน้าจอเลือกเพลงและเล่นเพลงก็ดี และคำสั่งเสียงก็ใช้เลือกเพลงได้ค่อนข้างดี
มันไม่สมบูรณ์แบบ แต่ผมว่าเหนือกว่ารถเครื่องยนต์สันดาปภายในทุกคันที่เคยขับมา
ขั้นตอนออกจากบ้านไปทำงานตอนเช้ามีแค่เปิดประตูแล้วเข้าโหมดขับขี่สองขั้นตอนก็จบ
แต่รถเครื่องยนต์สันดาปภายในช่วงหน้าหนาวเคยมีเกิน 10 ขั้นตอน ทั้งหากุญแจ ปลดล็อกรถ เปิดประตู ปรับเบาะหลังภรรยาขับ กดปุ่มสตาร์ต ละลายน้ำแข็งกระจกหน้า เปิดไล่ฝ้ากระจกหลัง ขูดน้ำแข็งที่กระจกหน้า เลือกที่ทำงานใน GPS ปลดเบรกมือ เหยียบคลัตช์ แล้วเข้าเกียร์
คนที่ไม่ได้เป็นเจ้าของจริงชอบบ่นเรื่องหน้าจอสัมผัสบนอินเทอร์เน็ตไม่หยุด แต่เจ้าของ Tesla กลับอยู่กับแบรนด์นี้ต่อ เพราะมันยอดเยี่ยมกว่ารถอื่นไม่ว่ามีจอสัมผัสหรือไม่ก็ตาม
Technology Connections พูดในวิดีโอล่าสุดว่าต้องกดค้างคันโยกหน้าตาเชยแบบยุค 90 อยู่ 4 วินาทีเพื่อเปลี่ยนที่ปัดน้ำฝน และยังต้องอ่านคู่มือเพื่อหาวิธีนั้นอีก
ในรถที่ประกอบจากชิ้นส่วนแยกๆ แปะรวมกัน พฤติกรรมขยะๆ แบบนี้พบได้บ่อยมาก
ในทางกลับกัน รถของผมส่งการแจ้งเตือนวิดีโอเฝ้าระวังแบบเรียลไทม์มาที่โทรศัพท์ ช่วยขับระหว่างเดินทางไปทำงาน และเรื่องเปลี่ยนเกียร์ก็แทบเป็นระดับที่แค่คาดเข็มขัดกับเหยียบเบรก รถก็เลือกทิศทางให้เอง
ฟังก์ชันสำคัญไม่ได้กระจายเป็นปุ่ม 50 ปุ่ม แต่เข้าถึงได้ตามบริบทผ่านพวงมาลัย
มันเรียบง่ายแต่ทรงพลัง และปัญหาคืออย่างที่บอกไปก่อนหน้า ว่ารถหรูเหล่านั้นทำออกมาได้แย่มาก
ผมดู YouTuber ชื่อ Theo Browne อยู่เป็นครั้งคราว เขาเป็นนักพัฒนาฝั่งฟรอนต์เอนด์เป็นหลัก
เวลาดูเขาอธิบายวิธีแก้ปัญหา มันให้ความรู้สึกเหมือนโดนไม้เบสบอลฟาดหัว และจำนวนองค์ประกอบที่ใส่เข้าไปในเดโมก็มากจนน้ำตาจะไหล
ยังตกใจกับจำนวนคำศัพท์ยากๆ เกี่ยวกับ React ที่เขาพูดถึงในวิดีโอหนึ่งด้วย
ไม่ได้จะเจาะจงด่าใครเป็นพิเศษ แต่ก็อดกังวลไม่ได้ว่านี่อาจเป็นสิ่งที่ทำให้ ความซับซ้อน ยังคงได้รับความนิยม
ในทางกลับกัน Pieter Levels กลับเอา PHP เพียวๆ ขึ้นโปรดักชันตรงๆ โดยไม่พูดถึงเรื่องอย่าง Suspense, server-side rendering หรือ Hydration
สุดท้ายทั้งคู่ก็ไปถึงเป้าหมายเดียวกัน แต่ Pieter Levels น่าจะทำเงินได้มากกว่ามาก และช่องว่างด้านความซับซ้อนก็ใหญ่มาก
เอาจริงๆ แล้วสิ่งอย่าง Nomad List ก็ดูมีฟีเจอร์มากกว่าสิ่งที่เห็นจาก Theo เสียอีก
หลังจากนั้นก็มีคนอื่นจำเขาได้ และผมเห็น Theo ถกเถียงเสียงดังแบบเป็นกันเองในประเด็นที่เขาพูดไว้อย่างหนักแน่นบนช่องของตัวเอง
บุคลิกของเขาดูเหมาะอย่างยิ่งกับการเพิ่มการมีส่วนร่วมของสื่อให้สูงสุดผ่านความซับซ้อนที่ไม่จำเป็น
ยิ่งซับซ้อนก็ยิ่งมีเรื่องให้ถกเถียงมากขึ้น และยังทำให้ดูฉลาดกว่าสำหรับคนที่ไม่คุ้นกับตัวเลือกอันยากจะเข้าใจเหล่านั้น
ปริมาณไลบรารีและโค้ดที่ใช้ในตัวอย่างแบบของเล่นนั้นมากกว่าสิ่งที่เห็นในโปรดักชันมาก และผมเองก็เคยเห็นระบบสัตว์ประหลาดอยู่ไม่น้อย
ไม่รู้เหมือนกันว่าสิ่งนี้จะอยู่ต่อไปได้นานแค่ไหน
มันพ่วงของจุกจิกที่ไม่เคยได้ใช้เข้ามาเต็มไปหมด และกลับไปขัดขวางส่วนที่เราจะใช้จริง
พอเกิดปัญหาขึ้นมา คุณก็ไม่ได้ต้องเข้าใจแค่ภาษาโปรแกรมกับโค้ดของตัวเองอีกต่อไป แต่ต้องเข้าใจโค้ดตามเส้นทางที่ตัวเองไหลผ่านอยู่ภายในเฟรมเวิร์กด้วย
เส้นทางนั้นลงลึกได้ง่ายๆ ถึง 10~20 ฟังก์ชัน และแทบจะหาเอกสารที่อธิบายอย่างเจาะจงพอว่ามีอะไรเกิดขึ้นใน edge case ต่างๆ ได้ยากมาก
จำนวนเครื่องมือที่ใช้เพื่อสร้างสิ่งที่ค่อนข้างเรียบง่ายนั้นมหาศาล และก็รู้สึกว่าใน DevOps ก็มีเรื่องคล้ายกันเกิดขึ้น
ปัญหานี้เหมือนถูกสร้างขึ้นโดย “นักพัฒนาฟรอนต์เอนด์” ในองค์กร
คล้ายกับว่าความรู้สึกด้อยกว่าต่อ “วิศวกรรมจริงๆ” ที่ฟูลสแต็กหรือแบ็กเอนด์ดีเวลอปเปอร์ทำอยู่ ทำให้ฝั่งฟรอนต์เอนด์เองก็อยากสร้างปัญหา “วิศวกรรมจริงๆ” ขึ้นมาบ้าง
หลังจากพัฒนาระบบ legacy มาหลายสิบปี บางครั้งเป็นงานออกแบบของบริษัทเรา บางครั้งเป็นงานตามสัญญาของลูกค้า ผมได้เห็นบ่อยมากจนเชื่อว่าลูกค้าบางรายชอบซอฟต์แวร์ที่ซับซ้อนและมีบั๊ก
เหตุผลคือมันใช้เป็นที่หลบได้
ประมาณว่า “ซอฟต์แวร์มีบั๊กเลยทำไม่ทัน”, “ซอฟต์แวร์ไม่รองรับ Y เลยทำ X ไม่ได้”, หรือ “หมากินการบ้าน”
หลายครั้งเราสามารถออกแบบวิธีแก้ที่ง่าย ใช้ง่าย และมีบั๊กน้อยกว่ามากได้ แต่ถ้าทำแบบนั้น ผู้ใช้ก็จะปกปิดได้ยากขึ้นว่าความล้มเหลวบางอย่างอาจไม่ได้เกิดจากซอฟต์แวร์ แต่เกิดจากความไร้ความสามารถของตัวเอง
เพราะอย่างนั้น โดยเฉพาะในบริษัทที่มีแรงกดดันจากเบื้องบนมาก ผู้จัดการจึงดูจะชอบทำงานกับซอฟต์แวร์ที่ตัวเองไม่เข้าใจทั้งหมด และเป็นที่รู้กันว่ามีบั๊กกับปัญหา อยู่จริงๆ
ตอนอายุ 27 ตอนย้ายออกจากงานแรกที่ทำมา 5 ปี ผมแทนที่โปรแกรม GUI ที่ซับซ้อนสุดๆ ด้วย GUI เล็กๆ ที่ครอบโปรแกรม CLI สองตัว
มันทำงานได้ทุกครั้งแม้จะป้อนข้อมูลผิด และถึงจะล้มเหลวบ้างเป็นครั้งคราวก็ยังให้ข้อความ error ที่มีประโยชน์
ผู้หญิงสามคนที่ใช้งานมันเกลียดผมมาก
หลังจากออกจากบริษัทไปแล้วประมาณหนึ่งปี ผมถึงเข้าใจเหตุผล และตอนนั้นผมก็ไม่ได้ฉลาดนัก
พอเวลาผ่านไป ผมก็เริ่มคิดว่าคนเราต้องการของแบบ Microsoft Teams เพราะเวลาจำเป็นพวกเขาจะใช้มันเป็นข้ออ้างปกป้องตัวเองได้
สำหรับ UI ทางกายภาพ กลุ่มของเราเรียกสิ่งนี้ว่า ปัญหาไมโครเวฟ
ปุ่มพิเศษเพิ่มอีก 20 ปุ่มบนไมโครเวฟนั้นไม่มีใครใช้ และคนส่วนใหญ่ก็ใช้แค่ปุ่มเดียวหรือสองปุ่ม แต่ไมโครเวฟที่มีปุ่มน้อยกลับไม่มีใครซื้อ
ผมชอบ Samsung ME82V ของผมมา 10 ปีแล้ว และมีแค่ปุ่มหมุนสองอันก็จบ
เพราะงั้นการแอบหาอะไรกินตอนตีสองจึงกลายเป็นการเฝ้าไมโครเวฟเหมือนปี 1999
สิ่งที่ต้องการมีแค่ ปุ่มหมุนปรับความเร็ว, สวิตช์ pulse, และสวิตช์เปิดปิด และทุกคนก็ต้องการแค่นั้น แต่ไม่รู้ทำไมทุกครั้งที่เปลี่ยนรุ่นกลับมีฟีเจอร์ที่ไม่มีใครใช้งอกมาเต็มไปหมด
ไม่ใช่ว่าจะใช้แค่สองปุ่มเดิมตลอดเวลาเสมอไป ดังนั้นผมก็ชอบที่มีตัวเลือกให้ใช้ปุ่มอื่นได้
และหลายครั้งการมีปุ่มมากกว่าก็มักมาพร้อมสเปกที่ดีกว่าด้วย
วิธีควบคุมก็น้อย ฟีเจอร์ก็น้อย แต่ประสบการณ์ผู้ใช้นั้นยอดเยี่ยม
ผมยังจำความเรียบสะอาดของ iPod ได้เมื่อเทียบกับสินค้าคู่แข่งที่ฟีเจอร์ล้นเกินและซับซ้อน
การคร่ำครวญแบบนี้น่ารำคาญเพราะเต็มไปด้วยคติพจน์ซ้ำๆ เดิมๆ
การอ้าง Einstein กับ Dijkstra ทำให้ดูฉลาดได้ง่าย และยังง่ายที่จะเหมารวมพร้อมชี้นิ้วใส่วิธีแก้ที่ซับซ้อน ทั้งที่อาศัยข้อได้เปรียบจากการมองย้อนหลังและความไม่รู้ต่อข้อกำหนดจริง
“ทำให้เรียบง่ายที่สุดเท่าที่เป็นไปได้ แต่ไม่ให้ง่ายไปกว่านั้น” เป็นคำพูดที่ถูกเสมอ
ถ้าวิธีแก้ยุ่งเหยิง ก็แปลว่าควรทำให้มันง่ายกว่านี้ และถ้าวิธีแก้แบบดิบๆ ก่อปัญหา ก็แปลว่าไม่ควรทำให้ง่ายเกินไป
เหมือนกับถามว่าทำไมไม่คิดจะทำให้สมบูรณ์แบบไปเลย
ในโลกความเป็นจริง ต่อให้มีทางเลือกหลายแบบให้แลกเปลี่ยนกัน ก็ยังยากมากที่จะตกลงกันว่าอะไรคือความเรียบง่าย
การดูแลฐานข้อมูลที่ซับซ้อนเพียงตัวเดียว อาจง่ายกว่าการมีฐานข้อมูลที่ “เรียบง่าย” สามตัวแล้วต้องทำงานดูแลเพิ่มสามเท่า ก่อนจะลงเอยด้วยการทำ synchronization หรือ distributed transactions เอง
สิ่งที่ทำได้ง่ายในตอนนี้อาจสร้างปัญหาซับซ้อนในภายหลัง และวิธีแก้สำเร็จรูปที่แก้ปัญหาได้ไม่ครบก็อาจก่อให้เกิดทางอ้อมที่ซับซ้อนสำหรับกรณีที่ไม่รองรับ ก่อนจะเพิ่มความซับซ้อนจากการย้ายไปใช้สิ่งที่เหมาะสมจริงๆ อีกชั้น
คำแนะนำว่า “ก็ทำให้ง่ายเข้าไว้” มักมาจากการไม่รู้ว่าวิธีแบบนั้นไม่ใช่ยาครอบจักรวาล และในความเป็นจริงก็แทบไม่มีตัวเลือกที่ชัดเจนระหว่างความซับซ้อนกับความเรียบง่าย
โปรเจกต์ต่างๆ มีข้อจำกัดอย่างระบบเก่าที่เละเทะอยู่แล้ว, ข้อกำหนดทางกฎหมายที่ไม่สอดคล้องกัน, และความต้องการทางธุรกิจที่เปลี่ยนไป รวมถึงอาจต้องให้ความสำคัญกับความเร็วในการปล่อยงานหรือทักษะที่พอจะจ้างได้
เรื่องความคุ้มค่าก็โหดร้าย เพราะถึงระบบส่งออกรายงานประจำปีจะเหมือนเครื่อง Rube Goldberg แต่ถ้าใช้แค่ปีละครั้ง ต่อให้เขียนใหม่ก็อาจไม่คืนทุนภายใน 50 ปี
การถกเรื่องความซับซ้อนแทบไม่ยอมรับเลยว่าโปรเจกต์และข้อกำหนดนั้นเติบโตขึ้น
สิ่งที่ตอนนี้เรียบง่ายอย่างสมบูรณ์แบบ วันหน้าก็อาจกลายเป็นสิ่งซับซ้อนได้อย่างมีเหตุผลเต็มที่ โดยไม่ใช่เพราะไร้ความสามารถหรือมีเจตนาร้าย
ตอนแรกการเก็บข้อมูลไว้ในไฟล์ข้อความธรรมดาอาจดูเรียบง่ายอย่างสวยงาม แต่ภายหลังก็อาจกลายเป็นฐานข้อมูล NIH ที่แย่มากได้
แต่ถ้าจะใช้ฐานข้อมูลตั้งแต่แรกเพื่อเก็บข้อมูลแค่ 3 บรรทัด ก็เป็น overengineering เช่นกัน
การ refactor มีต้นทุน ดังนั้นการใช้วิธีที่เหมาะสมในอุดมคติเสมอไปก็ไม่ได้เรียบง่ายขนาดนั้น
สิ่งที่เป็นเรื่อง очевидent จริงๆ มีน้อยกว่าที่คิดมาก
การตีความว่า “ทำให้เรียบง่ายที่สุดเท่าที่เป็นไปได้ แต่ไม่ให้ง่ายไปกว่านั้น” คือการเรียกร้องความสมบูรณ์แบบนั้น ไม่ได้ตามตรรกะเลย
ในงานจริงเรารู้ว่า การทำซ้ำเอาชนะแผนการได้
ถ้าตกลงกันไม่ได้ว่าอะไรเรียบง่าย ก็ไม่ต้องขออนุญาต ให้ค่อยไปขออภัยเอาทีหลัง
นี่เป็นกฎที่ใช้ได้ในอุตสาหกรรมนี้ และอาจรวมถึงอีกหลายอุตสาหกรรมด้วย
มีรูปแบบบางอย่างของความซับซ้อนที่เกิดขึ้นโดยบังเอิญซึ่งพบได้ชัดในพวกนักเพ้อฝันกับนักพัฒนา frontend
ความซับซ้อนก็คือความซับซ้อน
ระบบที่ซับซ้อนกว่ามักมีผลข้างเคียงระดับที่สอง คือสร้าง สื่อประกอบ อย่างบทสอนหรือวิดีโอออกมาจำนวนมาก
อีกทั้งสำหรับคนที่เรียนรู้มันได้ สิ่งนั้นยังทำให้พวกเขากลายเป็นคนที่บริษัทต้องการเพราะมีทักษะและความรับผิดชอบดังกล่าว จึงให้ความมั่นคงในการจ้างงานมากกว่าสิ่งที่แค่ทำงานได้ดีอยู่แล้วจนไม่ต้องมีคนแบบนั้น
มีงานในสายไอทีจำนวนมากเกินไปที่คงไม่เกิดขึ้นเลย หากซอฟต์แวร์ถูกทำให้เรียบง่ายและใช้งานได้เลย
ในกรณีง่ายๆ มัน “ก็ทำงานได้เลย” แต่จะโอเคก็ต่อเมื่อคุณไม่พยายามมองเข้าไปข้างในหรือทำอะไรที่ไม่ใช่เรื่องเล็กน้อย
ซึ่งอาจเป็นอุปมาเปรียบเทียบที่แม่นใช้ได้ทีเดียว
ถ้าพูดถึงการรีวิวเปเปอร์ ในฐานะผู้รีวิว สิ่งที่ฉันมองหาในงานไม่ได้มีทั้งความเรียบง่ายหรือความซับซ้อน และไม่ใช่ “ความใหม่” ด้วย
สิ่งที่ฉันมองหาคือ การวิเคราะห์เชิงประจักษ์ที่รอบด้านและชวนให้คิดเกี่ยวกับปัญหา
งานที่ส่งเข้ามามีอยู่มากทั้ง 1) งานที่เสนอระบบแบบ Frankenstein ซึ่งเอาไอเดียเดิมเป็นสิบอย่างมาเย็บติดกัน ใช้ของเล่นใหม่ล่าสุดที่จับต้องได้ให้มากที่สุดเพื่อให้ได้ “ตัวเลขหนาๆ” โดยไม่ได้วิเคราะห์เชิงลึกว่าชิ้นส่วนแต่ละชิ้นจะล้มเหลวอย่างไร และ 2) งานที่แค่ปรับวิธีเดิมนิดหน่อยแล้วประสิทธิภาพดีขึ้นโดยบังเอิญ แต่ไม่มีเหตุผลรองรับเชิงประจักษ์และเชิงทฤษฎีอย่างเหมาะสมว่าทำไมมันถึงช่วยได้
งานประเภทที่สองอาจมีคุณค่าต่อชุมชนหรือผู้อ่านอยู่เล็กน้อย แต่โดยมากฉันมองว่าแทบไม่มีประโยชน์
สิ่งที่มีคุณค่าต่อผู้อ่านคือกรณีที่นักศึกษาปริญญาเอกเฝ้ามองปัญหาอยู่นานพอ จนเชื่อมสัญชาตญาณของตัวเองไปสู่การยืนยันเชิงปริมาณที่ตรวจสอบได้ และได้ข้อสังเกตที่ทำซ้ำได้พร้อมพลังในการพยากรณ์
เช่น “เราได้ตรวจสอบเชิงทดลองในทุกกรณีแล้วว่า X ส่งผลต่อ Y ผ่านกลไก Z ที่อธิบายในเปเปอร์นี้ ดังนั้นจึงปรับปรุงตัวชี้วัด A ได้ B% ซึ่งสอดคล้องกับ Z” อะไรทำนองนั้น
ไม่ว่ามันจะซับซ้อนแค่ไหน การพูดแค่ว่า “ทำ X แล้ว A เพิ่มขึ้น B%” นั้นยังไม่พอ
น่าเสียดายที่ไม่ใช่ผู้รีวิวทุกคนจะเห็นด้วย
ครูประวัติศาสตร์สมัยมัธยมปลายของฉันเคยมอบหมายงานเขียนเรียงความเกี่ยวกับเหตุการณ์ที่นำไปสู่สงครามโลกครั้งที่สอง
คำถามแรกคือมันควรยาวแค่ไหน และครูก็ตอบว่าถ้าใครสามารถอธิบายหัวข้อที่ซับซ้อนนี้ได้ใน A4 หนึ่งหน้า จะให้เต็มทันที แต่ก็สงสัยอย่างจริงใจว่าจะมีใครทำได้ด้วยความยาวแค่นั้นหรือไม่
ทุกคนอึ้งกับตรรกะนั้น
ไม่มีใครเคยได้ยินครูพูดแบบนั้นมาก่อน และมันแสดงให้เห็นว่าเราถูกสอนมาตั้งแต่เด็กว่าของที่มากกว่านั้นดีกว่าเสมอ
คำอธิบายสามารถทำให้ยาวหรือสั้นได้เสมอ ขึ้นอยู่กับระดับนามธรรมที่เลือก และคนส่วนใหญ่ก็มักเลือกระดับนั้นตามบริบทกับธรรมเนียมทางสังคม
ตัวอย่างเช่น “การกดแป้นพิมพ์ทำให้กลายเป็นตัวอักษรบนหน้าจอได้อย่างไร” อธิบายเป็นประโยคเดียวก็ได้ หรือจะขยายไปถึง firmware, software stack, วิศวกรรมอิเล็กทรอนิกส์, วัสดุศาสตร์, และกระบวนการผลิต จนกลายเป็นหนังสือหนาๆ หลายเล่มก็ได้
สงครามโลกครั้งที่สองก็อาจอธิบายได้ว่าเริ่มต้นเมื่อ Hitler บุก Poland และ France หรือจะย้อนไปถึงสนธิสัญญา Versailles ก็ได้ หรือจะเล่าไปถึงวิวัฒนาการของสิ่งมีชีวิตบนโลกก็ยังได้
อันสุดท้ายนั้นอาจดูอวดภูมิ แต่ในทางเทคนิคก็ถือว่าเป็นเหตุการณ์ที่นำไปสู่สงครามโลกครั้งที่สองจริง
ขอแนะนำอย่างยิ่งให้ดูบรรยาย Simple Made Easy ของ Rich Hickey
ความซับซ้อนขายไม่ค่อยออกเลย แต่ความง่ายขายได้ดี
ถ้าบริษัทสามารถจ้างคนที่ใช้ ‘foo’ เป็นได้จำนวนมาก และทั้งวงการยังคงพูดถึง ‘foo’ กันอยู่ ก็จะเลือกมันแม้ว่า foo จะเป็นความยุ่งเหยิงเต็มรูปแบบก็ตาม
ดูได้จาก lambda architecture, โปรเจกต์ส่วนใหญ่ของ Apache, คอนเทนเนอร์ เป็นต้น