จงเลือกเทคโนโลยีที่น่าเบื่อ (2015)

• การยับยั้งการนำเทคโนโลยีใหม่มาใช้ และให้ความสำคัญกับ เทคโนโลยีที่ผ่านการพิสูจน์แล้ว (boring technology) ก่อน เป็นผลดีต่อความสำเร็จระยะยาวของบริษัท
• ทุกบริษัทมี innovation tokens อยู่ราว 3 เหรียญ เท่านั้น และทุกครั้งที่เลือก NodeJS, MongoDB หรือเครื่องมือเกิดใหม่ ก็จะใช้ไปหนึ่งเหรียญ
• เทคโนโลยีที่ผ่านการพิสูจน์แล้วมีทั้ง ความสามารถ (capabilities) และ รูปแบบความล้มเหลว (failure modes) ที่เป็นที่รู้กันดี จึงมีความเสี่ยงจาก unknown unknowns แบบที่มากับเทคโนโลยีใหม่ต่ำกว่า
• การเลือกเทคโนโลยีส่งผลต่อทั้งทีมและทั้งองค์กร และเพราะภาระด้านการปฏิบัติการกับภาระทางความคิด จึงมักเป็นประโยชน์กว่าที่จะใช้ เครื่องมือที่พอเหมาะกับหลายปัญหา แทนที่จะเป็น "เครื่องมือที่ดีที่สุดสำหรับงานนั้น"
• การเลือกเทคโนโลยีอย่างรอบคอบช่วยให้นักวิศวกรมี อิสระไปโฟกัสกับปัญหาที่ใหญ่กว่า และเทคโนโลยีเพื่อตัวเทคโนโลยีเองนั้นไม่มีความหมาย

---

ยอมรับความน่าเบื่อ (Embrace Boredom)

• ทุกบริษัทมี innovation tokens อยู่ราว 3 เหรียญ และอุปทานนี้คงที่อยู่พักใหญ่ — อาจเพิ่มขึ้นได้บ้างเมื่อมีเสถียรภาพและความสุกงอมเพียงพอ แต่ก็มักประเมินจำนวนที่ตัวเองมีสูงเกินจริง
• การเขียนเว็บไซต์ด้วย NodeJS, การใช้ MongoDB, หรือการเลือกเทคโนโลยี service discovery ที่เปิดตัวมาไม่ถึง 1 ปี ล้วนใช้ innovation token อย่างละ 1 เหรียญ ส่วนการเขียนฐานข้อมูลขึ้นมาเองนั้นคือหายนะเต็มรูปแบบ
  • ทางเลือกเหล่านี้อาจสมเหตุสมผลถ้าคุณเป็นบริษัทที่ปรึกษา javascript หรือบริษัทฐานข้อมูล แต่คนส่วนใหญ่กำลังสร้างบริษัทที่มีภารกิจใหญ่กว่า เช่น นิยาม global commerce ใหม่ หรือคิดค้นระบบชำระเงินบนเว็บขึ้นมาใหม่ — การเทความสนใจอันจำกัดไปกับนวัตกรรมในพื้นที่อย่าง ssh คือทางลัดสู่ความล้มเหลวหรืออย่างน้อยก็ความสำเร็จที่ล่าช้า
• "น่าเบื่อ (boring)" ไม่ได้เท่ากับ "แย่ (bad)" และก็มีเทคโนโลยีที่ทั้งน่าเบื่อและแย่จริง — ตัวอย่างของสิ่งที่น่าเบื่อแต่ดีพอ ได้แก่ MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• ข้อดีของเทคโนโลยีที่น่าเบื่อไม่ได้มีแค่ ความสามารถ (capabilities) แต่รวมถึงการที่ รูปแบบความล้มเหลว (failure modes) ของมันก็เป็นที่เข้าใจกันดีด้วย
• ในการเลือกเทคโนโลยี มีทั้ง known unknowns (เช่น ไม่รู้ว่าฐานข้อมูลจะทำงานอย่างไรเมื่อ CPU แตะ 100%) และ unknown unknowns (เช่น ไม่เคยนึกว่าการเก็บสถิติจะทำให้เกิด GC pause) อยู่ร่วมกัน และยิ่งเป็นเทคโนโลยีใหม่ ขนาดของ unknown unknowns ก็ยิ่งใหญ่กว่ามาก

ปรับให้เหมาะทั้งระบบ (Optimize Globally)

• การเอนเอียงไปทางเทคโนโลยีที่น่าเบื่อเป็นอคติที่ดี แต่ไม่ใช่ปัจจัยเดียวที่ต้องพิจารณา เพราะการเลือกเทคโนโลยีมี ขอบเขต (scope) ที่ส่งผลต่อทีม องค์กร และทั้งระบบ
• การเพิ่มเทคโนโลยีมีต้นทุน — ถ้าใช้ Ruby อยู่แล้วและเพิ่ม Python เข้าไป ความซับซ้อนมักเกินประโยชน์ส่วนเพิ่ม แต่พอเป็นการถกเถียงแบบ Python vs Scala หรือ MySQL vs Redis คนกลับชอบโยนข้อจำกัดทิ้งแล้วตะโกนหา "เครื่องมือที่ดีที่สุดสำหรับงานนั้น (best tool for the job)"
• แก่นของงานคือการ แมปปัญหาทางธุรกิจเข้าสู่พื้นที่คำตอบของการเลือกซอฟต์แวร์ และถ้าการตัดสินใจเหล่านี้ไม่มีภาระ เราก็คงเลือกเครื่องมือที่เหมาะที่สุดเฉพาะจุดสำหรับแต่ละปัญหาได้ แต่โลกจริงมีภาระนั้นอยู่
  • ภาระดังกล่าวคือ operations และในระดับที่น้อยกว่านั้นคือ cognitive overhead — ความรู้ที่ต้องใช้ในการมอนิเตอร์, เขียน unit test, แก้ไขปัญหา, สคริปต์ init ฯลฯ สะสมขึ้นอย่างรวดเร็ว
• ปัญหาของแนวคิด "เครื่องมือที่ดีที่สุดสำหรับงานนั้น" คือมองทั้ง "ดีที่สุด" และ "งานนั้น" แบบสายตาสั้น — งานที่แท้จริงคือทำให้บริษัทยังอยู่รอด และเครื่องมือที่ "ดีที่สุด" คือเครื่องมือที่ แย่น้อยที่สุด (least worst) สำหรับปัญหาให้ได้มากที่สุด
• ต้นทุนระยะยาว ของการทำให้ระบบคงเสถียรนั้นสูงกว่าความไม่สะดวกระหว่างการสร้างอย่างท่วมท้น และนักพัฒนาที่มีวุฒิภาวะและสร้างผลงานได้จริงจะเข้าใจสิ่งนี้

บางครั้งก็เลือกเทคโนโลยีใหม่ (Choose New Technology, Sometimes)

• ถ้าดันตรรกะข้างต้นไปสุดทาง เราคงต้องสร้างเว็บไซต์ด้วย Java อย่างเดียว ซึ่งไม่สมจริง — เราจำเป็นต้องมีวิธีเพิ่มเครื่องมือใหม่เข้าไปในกล่องเครื่องมือ
• แต่สุดท้ายเทคโนโลยีใหม่ก็มีผลกระทบทั้งบริษัท ดังนั้นการเพิ่มจึงเป็นการตัดสินใจที่ต้องมี การมองเห็นในระดับทั้งบริษัท (company-wide visibility) — ต้องสร้างความคาดหวังทางวัฒนธรรมว่า "นี่เป็นเรื่องที่พวกเราทุกคนต้องคุยกันร่วมกัน"
• แบบฝึกหัดที่ควรทำที่สุดคือถามตัวเองว่า จะจัดการปัญหาตรงหน้าอย่างไรโดยไม่เพิ่มเทคโนโลยีใหม่ — มันช่วยให้มองออกว่าบางครั้ง "ปัญหา" ที่แท้จริงก็แค่มีใครบางคนอยากใช้เทคโนโลยีนั้น และถ้าเป็นเช่นนั้นก็ควรหยุดทันที
  • แค่มีตัวเลือกเทคโนโลยีไม่กี่อย่างก็ไปได้ไกลมาก และคำตอบจริงมักไม่ใช่ "ทำไม่ได้" แต่เป็น "ทำได้ แค่ยากเกินไป" มากกว่า — ถ้าคุณรู้สึกว่าไม่มีทางไปถึงเป้าหมายได้ด้วยทรัพยากรปัจจุบัน ก็อาจเป็นไปได้ว่าคุณยังคิดอย่างสร้างสรรค์ไม่พอ
• การ บันทึกให้ชัดเจน ว่าทำไมการแก้ปัญหานั้นด้วยสแตกปัจจุบันจึงแพงและยากเกินไป เป็นสิ่งที่ช่วยได้
• การเลือกเทคโนโลยีใหม่อาจเป็น การเพิ่มแบบล้วน ๆ (เช่น ยังไม่มี caching เลยจึงเพิ่ม memcached) หรืออาจซ้ำซ้อน/มาแทนของเดิมก็ได้ — ถ้าเป็นแบบแทนที่ ต้องตั้งความคาดหวังที่ชัดเจนเรื่อง การย้ายระบบของฟังก์ชันเดิม และนโยบายก็มักอยู่ในรูปของการ "สัญญาว่าจะย้าย" พร้อมกำหนดการที่เสนอไว้
  • จุดประสงค์คือควบคุมซากตกค้างให้อยู่ในระดับที่จัดการได้ และป้องกันไม่ให้วิธีแก้เฉพาะจุดที่เหมาะที่สุดกระจัดกระจายเต็มไปหมด
• กระบวนการนี้ไม่ได้หนักหนาอะไร แค่คำถามไม่กี่ข้อให้กรอกเป็นการบ้าน และประชุมหนึ่งครั้งเพื่อคุยกัน — ถ้าเทคโนโลยีใหม่หรือบริการใหม่ผ่านด่านนี้ไปได้อย่างไม่มีปัญหา การเพิ่มมันก็เหมาะสม

แค่ปล่อยของให้ถึงมือผู้ใช้ (Just Ship)

• polyglot programming มักถูกขายด้วยคำสัญญาว่า ถ้าให้อิสระเต็มที่กับนักพัฒนาในการเลือกเครื่องมือ พวกเขาจะ حلปัญหาได้อย่างมีประสิทธิภาพกว่าเดิม แต่การมองแบบนี้อย่างดีก็คือนิยามปัญหาอย่างไร้เดียงสา และอย่างแย่คือเป็นการหาเหตุผลเข้าข้างตัวเองแบบหมู่คณะ — toil ของงานปฏิบัติการประจำวันจะถ่วงนักพัฒนาจนจม
• การเลือกเทคโนโลยีอย่างรอบคอบต่างหากที่ให้อิสระแก่วิศวกรในการ ขบคิดคำถามที่ใหญ่กว่า และเทคโนโลยีเพื่อตัวเทคโนโลยีเองก็คือ snake oil

กรณีของ Etsy (เชิงอรรถ)

• ในช่วงแรก Etsy เจอปัญหานี้อย่างหนัก — หลังจากจ้างโปรแกรมเมอร์ Python มาเป็นจำนวนมาก ก็พยายามหาอะไรให้พวกเขาทำ จนสุดท้ายสร้างชั้นกลางที่ไร้ความหมายขึ้นมา และใช้เวลาหลายปีกว่าจะลบมันออกได้ / ในเวลาเดียวกัน latency ของการค้นหาที่เปอร์เซ็นไทล์ 90 อยู่ที่ราว 2 นาที — Etsy ไม่ได้ล้มเหลว แต่ความสำเร็จล่าช้าเพราะหลายปีแทบไม่ได้ปล่อยอะไรออกมาเลย
• จุดตัดระหว่างเทคโนโลยีที่น่าเบื่อกับที่แย่ มักถูกเรียกรวม ๆ ว่า "enterprise software" แต่ก็อาจไม่แม่นนัก
• กรณีของ activity feeds ที่ Etsy - ถูกสร้างขึ้นในช่วงที่บริษัทกำลังรวมหลายอย่างเข้าไว้กับ PHP, MySQL, Memcached และ Gearman / มันซับซ้อนกว่าการใช้เครื่องมืออย่าง Redis มาก แต่ก็ยังสร้างได้ด้วยสแตกนี้
  • หลายปีต่อมา แม้ความสนใจจะย้ายไปอยู่ที่อื่น และการใช้งาน activity feeds เพิ่มขึ้น 20 เท่า แต่เพราะอยู่บน แพลตฟอร์มร่วม จึงยังทำงานได้ตามปกติโดยแทบไม่ต้องแก้อะไร — นี่คือข้อดีระยะยาวของความยับยั้งชั่งใจในการเลือกเทคโนโลยี
  • อย่างไรก็ดี นี่ไม่ใช่แนวคิดแบบสุดโต่ง — Etsy มองว่า activity feeds ที่ใช้ memcached เป็นหลักนั้นใช้งานได้จริง แต่ก็ไม่ได้ถึงขั้นจะทำ full-text search แบบมืออาชีพที่มี faceted search ด้วย PHP ล้วน ๆ ดังนั้น Etsy จึงใช้ Solr