ในยุคที่ JS Ecosystem เป็นใหญ่ ภาพที่เราเห็นกันจนชินตาคือ framework ออกใหม่รายสัปดาห์ และที่ประหลาดกว่าภาษาอื่น ๆ คือ runtime ยังมีออกมาใหม่เรื่อย ๆ ด้วย!

(Bun เพิ่ง stable release v1.0.0 เมื่อปีก่อน)
https://bun.sh/blog/bun-v1.0

หรือใหม่กว่านั้นหน่อยในยุคที่ Generative AI กำลังมา บริษัทต่าง ๆ พยายามทำยังไงก็ได้ให้ product หรือบริษัทของตัวเองได้แปะป้ายว่า

มันดูเป็นเรื่องปกติไปแล้วสำหรับคนเขียนโปรแกรมช่วง 2016 - ปัจจุบันไปแล้วที่ต้องตามข่าวและลองใช้ library, framework หรือ tooling ต่าง ๆ ที่ทยอยกันออกมา สิ่งที่ตามมาโดยไม่ได้ตั้งใจและทำให้หลาย ๆ ทีมและหลาย ๆ product ต้องพับตัวเก็บไปคือ "Hype-Driven Development"

ผมขอขยายความคำคำนี้หน่อย Hype-Driven Development เป็นปราฏการณ์ที่ทีมหรือบริษัทเลือกใช้ technology ตาม trend  หรือเลือกแบบรู้จักอย่างผิวเผิน มากกว่าเลือกโดย technical trade off

ถ้าจะเจาะลึกลงไปอีกหน่อย หลาย ๆ ครั้งจะเห็นทีมหรือบริษัทที่ขาดทีม tech ที่ mature หน่อยตัดสินใจเลือก technology stack จากหัวข้อเหล่านี้

แปลเป็นไทยง่าย ๆ คือ มันดูเป็นนวัตกรรมดีเลยใช้ มันต้องดีกว่าของที่เราใช้อยู่แน่ ๆ ตัวอย่างมีให้เห็นตั้งแต่สมัย GraphQL ออกใหม่ ๆ จนถึงล่าสุด ChatGPT integration

การเลือก technology ด้วย perceived innovation แบบผิวเผินไม่ได้ศึกษาให้ดีเป็นทางที่อันตรายมากสำหรับ tech product ตัวอย่างเช่นทีมที่เขียน fullstack PHP ที่มี working product อยู่แล้ว ไม่ได้มีปัญหาอะไรกับตัว product ปล่อย feature ได้เรื่อย ๆ มีปัญหาเล็กน้อยที่การ query ของจาก database ทำให้บาง flow มันรู้สึกว่าช้าแต่จู่ ๆ มี senior ในทีม คนนึงเดินมาบอกว่า

ทีมที่มี tech maturity คงพากันส่ายหน้าแล้วไล่ความลำบากและความไม่สมเหตุสมผลของการตัดสินใจนี้ แต่สำหรับบางทีมที่ mature ไม่พอ อาจกระโดดใส่เพราะความ hype เขียนทุกอย่างใหม่หมดด้วย React กับ Node แต่ไม่ได้ optimize query สุดท้ายโหลดช้าเป็นเต่าเหมือนเดิม

เสียเวลา rewrite ไป 1 quarter แลก performance gain อันน้อยนิดกับ product velocity ที่อาจทำ feature ใหม่ ๆ ออกไปได้มากกว่านี้ ทำ revenue ให้บริษัทได้มากกว่านี้

FOMO หรือกลัวตกเทรนเป็นอีกหัวข้อนึงที่พบบ่อยมาก ๆ ซึ่งผมคิดว่าแย่กว่า perceived innovation อีกนะ สำหรับ perceived innovation ยังไปดูมาว่ามันจะทำให้ระบบเราดีขึ้นยังไง (แต่อาจไม่ได้ตอบโจทย์และทำให้แย่ลงแทน) แต่สำหรับ FOMO นี่คืออยาก "แปะป้าย" ล้วน ๆ ตัวอย่างที่เห็นกันชัด ๆ เลยคือ LLM หรือ Large Language Model นี่แหละ

ยกตัวอย่างบริษัททำ order management system ที่ product หลักคือการทำ Point of Sale (PoS) เชื่อมกับระบบ stock และ manage order หลังบ้าน มี stackholder ที่มี FOMO จู่ ๆ เดินเข้ามาบอกทีมว่า

โอเคมันอาจหาที่ลงได้ แต่ด้วย nature ของตัว product นี้ ทุกอย่างมันค่อนข้างชัดอยู่แล้ว scan product นับ ของใน stock มี order เข้ามาจ่ายเงินแล้วตัด stock ออก invoice

คนในทีมที่ mature หน่อยคงเห็นว่า "เอาเวลาไปทำให้ระบบ scan barcode เรา scan ติดง่าย ๆ ดีกว่าไหมครับ ตอนนี้มัน library ที่เราใช้ scan ช้ามากเลย" หรือ "ระบบ analytic ของ order มันโหลดข้อมูลช้ามากเลยครับ ผมอยาก optimize query ให้มันก่อน" แต่อาจพบกับคำตอบว่า

กลายเป็นว่าเอาเวลาไป deliver ของที่ไม่ได้ทำให้ quality of life ของคนใช้ product จริง ๆ ซะงั้น

ข้อนี้ตรงตัวเลยคือ "เบื้องบน" สั่งมา หัวข้อนี้เจอได้ทั่วไปในบริษัทที่เบื้องบนมี tech literacy ระดับนึง พอให้ Dunning-Kruger effect ทำงาน

สำหรับผมข้อนี้อันตรายที่สุด สองข้อแรกถ้า stackholder เข้าใจระบบที่ทำอยู่และมี tech literacy มากพอจะยังพอหลบได้ แต่ถ้าเบื้องบนสั่งมาเมื่อไหร่คือ product รอดยากมาก วิธีแก้มีทางเดียวคือ educate stackholder ให้เข้าใจ technology ซึ่งถ้าอยู่ใน culture ที่ conservative มาก ๆ น่าจะหมดหนทาง เพราะว่าเคสสามารถยำสองข้อแรกที่กล่าวมาทั้งหมดเข้ามาในคราวเดียวได้

ทั้งสามข้อเป็นเรื่องใหญ่ ๆ ที่ผมเห็นว่าเป็นสาเหตุที่พบบ่อยสำหรับทีมที่ adopt tool จากความ hype แต่จริง ๆ ให้เขียนอีกหลายบทความก็คงไล่ไม่หมด แต่สำหรับข้อที่ผมเล่ามาคงจะพอให้หลาย ๆ คนเห็นภาพกันไม่มากก็น้อย

หลังจากที่เรามี awareness เรื่อง Hype-Driven Development แล้ว เราจะจัดการไม่ให้มันเกิดขึ้นในทีมหรือองกรณ์เรายังไงดีล่ะ?

เราควรกระตุ้นให้คนในทีมมี healthy skepticism (การสงสัยอย่างมีเหตุผล) ซึ่งทำให้เกิดการตั้งคำถามถึงความเหมาะสมของ technology ที่เลือกใช้ได้ตรงจุดมากขึ้น ทำให้ทีมคิดถี่ถ้วนขึ้นก่อนที่จะเลือกใช้ technology ต่าง ๆ และที่สำคัญคือต้องเพิ่มความรับผิดชอบในการตัดสินใจซึ่งจะทำให้คนในทีมมองผลลัพธ์ในระยะยาวมากขึ้นเพราะต้องรับผิดชอบการตัดสินใจแต่ละครั้ง เช่น มี KPI วัดผลเสมอหลัง adopt technology ใหม่เพื่อความชัดเจนว่าสิ่งที่นำมาใช้มันมีประโยชน์กับองกรณ์จริง ๆ

ถอยออกมามองปัญหาที่ทีมมีก่อนที่จะกระโดดไปเลือก solution ในทีมควรจะต้องคำนึงถึง business และ technical requirements ก่อนเลือกใช้ technology ต่าง ๆ เสมอ และในการเลือกใช้ solution ต่าง ๆ ต้องมองให้รอบด้าน เช่น บาง solution มันสเกลได้จริงแต่ตอนนี้ traffic เรา projection เป็นยังไง มันจะไปถึงจุดนั้นเมื่อไหร่ แลกกับ complexity และ overhead ที่เพิ่มมามันคุ้มหรือไม่

สิ่งที่จะทำให้เกิดการ adoption ได้ง่ายที่สุดและ effective ที่สุดคือการที่เราสามารถค่อย ๆ adopt technology ชิ้นนั้นได้ ถ้า technology ไหนทำให้เกิดการ rewrite เกิด bigbang effect เป็นวงกว้างให้คิดไว้เลยว่ามันไม่ตอบโจทย์

สิ่งที่ lead/manager หลายคนอาจลืมคิดถึงไปคือ contribution ที่สั่งสมมากับ solution ที่มันตอบโจทย์ธุรกิจอยู่แล้ว การที่ต้องทำทุกอย่างใหม่ทั้งหมดทำให้ต้องกลับไป revisit ทุก decision ที่เคยตกลงกันไปแล้วใหม่ ไม่ใช่แค่ฝั่ง tech แต่ยังรวมถึงฝั่ง business ด้วย ซึ่งทำให้ project rewrite, revamp ทุกอย่างจาก 0 ในโลกการทำงานจริง ๆ ไปไม่ค่อยรอด ถึงรอดก็แทบจะไม่คุ้ม effort ที่ลงไป

ทีมควรมองหา solution ที่ค่อย ๆ adopt เป็นส่วน ๆ ไปได้ ค่อย ๆ migrate ทีละส่วนซึ่งจะให้ ROI ที่ดีกว่าและที่สำคัญเลยคือการหันหลังกลับสามารถทำได้ทุกเมื่อและ cost น้อยกว่า สามารถ validate benefit ที่ได้บ่อยขึ้นและยังได้ประโยชน์เพิ่มขึ้นจาก technology ใหม่โดยไม่ต้องรอทุกอย่างเสร็จทั้งหมดอีกด้วย

ใน Software Engineering สิ่งสำคัญที่สุดคือการตัดสินใจระหว่าง trade-off ต่าง ๆ กับข้อจำกัดที่ระบบของเราต้องเจอ ทั้งเวลา งบ และ คน การเลือก tool ตาม trend จึงเป็นเรื่องค่อนข้างอันตรายและเป็นเรื่องที่ทีมควรให้ความสำคัญ คิดให้ถี่ถ้วน ก่อนตัดสินใจหยิบมาใช้ครับ

หวังว่า opinion ของผมจะเป็นประโยชน์ครับทุกคนที่เข้ามาอ่านครับ ทักมาคุยแลกเปลี่ยนเกี่ยวกับ Software Engineering กันได้ที่ X สำหรับ content ภาษาอังกฤษ หรือ follow page คนหัวโค้ด ของผมสำหรับ content ภาษาไทยได้ครับ