โค้ดมักถูกนำไปรันมากกว่าถูกอ่าน

• หลักการที่ว่า “โค้ดมักถูกอ่านมากกว่าถูกเขียน” เริ่มจากแนวคิดให้ความสำคัญกับ ผู้ดูแลรักษามากกว่าผู้เขียน แล้วขยายเป็นโมเดลการตัดสินใจที่คำนึงถึงผู้ใช้ การปฏิบัติการ และธุรกิจด้วย
• คุณค่าของโค้ดไม่ได้อยู่ที่ความประณีตในตัวมันเอง แต่อยู่ที่ว่า ตอบสนองเป้าหมายของผู้ใช้หรือไม่ และกระบวนการนำไปให้ผู้ใช้เห็นตั้งแต่เนิ่น ๆ และบ่อย ๆ พร้อมนำฟีดแบ็กมาปรับใช้เป็นสิ่งสำคัญ
• การ “รัน” โค้ดในโปรดักชันครอบคลุมตั้งแต่การดีพลอย อัปเกรด สังเกตการณ์ ตรวจสอบ เฝ้าระวัง แก้ไข ไปจนถึงเลิกใช้งาน และต้นทุนการปฏิบัติการระยะยาวอาจสูงกว่าความไม่สะดวกระหว่างการพัฒนามาก
• KISS ไม่ได้หยุดอยู่แค่การทำให้โค้ดเรียบง่าย แต่ขยายเป็นหลักการด้านปฏิบัติการที่ลดชิ้นส่วนที่เคลื่อนไหว และทำความเข้าใจ โหมดความล้มเหลว เพื่อให้ระบบยังทำงานได้แม้เกิดความล้มเหลว
• งบประมาณ การตลาด เดดไลน์ ผู้มีส่วนได้ส่วนเสีย นักลงทุน และผลประโยชน์ทางการเมืองล้วนเข้ามาเกี่ยวข้องกับการตัดสินใจ จึงต้องยอมรับว่าการทำให้ผู้ใช้พอใจกับการสร้างรายได้ไม่ได้สอดคล้องกันเสมอไป

---

การขยายโมเดลลำดับความสำคัญ

• คำกล่าวที่ว่า “โค้ดมักถูกอ่านมากกว่าถูกเขียน” หมายความว่าคนที่เขียนโค้ดครั้งแรกไม่ควรมองข้ามต้นทุนของคนที่จะมาอ่านและแก้ไขมันในอนาคต
• หลักการนี้กลายเป็นเหตุผลในการลงทุนกับ ความสามารถในการดูแลรักษา เช่น ความเรียบง่าย การทดสอบ และเอกสารประกอบ
• หากย่อให้สั้น โมเดลนี้มองได้เป็น maintainer > author

ผู้ใช้อยู่ก่อนนักพัฒนา

• โค้ดเป็นเครื่องมือเพื่อเป้าหมายบางอย่าง และซอฟต์แวร์ต้องให้บริการแก่ผู้ใช้บางกลุ่ม
• ต่อให้โค้ดเขียนดีหรือเทคโนโลยีประณีตเพียงใด หากไม่ตอบโจทย์เป้าหมายและไม่มอบประสบการณ์ผู้ใช้ที่ดี คุณค่าก็ลดลง
• ลำดับความสำคัญขยายเป็น user > maintainer > author และหากไม่แยกบทบาทของนักพัฒนา ก็จะกลายเป็น user > dev
• แทนที่จะเดาหรือเพียงถามว่าผู้ใช้ต้องการอะไร ควร นำโปรแกรมไปไว้ต่อหน้าผู้ใช้ตั้งแต่เนิ่น ๆ และบ่อย ๆ แล้วนำสิ่งที่เรียนรู้จากฟีดแบ็กมาปรับใช้

การรันครอบคลุมถึงการปฏิบัติการในโปรดักชัน

• “การรัน” ไม่ได้หมายถึงแค่การเปิดโปรแกรม แต่รวมถึงกระบวนการทั้งหมดของการปฏิบัติการในโปรดักชัน
  • การดีพลอย
  • การอัปเกรด
  • การสังเกตการณ์
  • การตรวจสอบ
  • การมอนิเตอร์
  • การแก้ไข
  • การเลิกใช้งาน
• Dan McKinley ใน Choose Boring Technology มองว่าต้นทุนระยะยาวในการทำให้ระบบทำงานต่อไปได้อย่างเสถียร แทบจะมากกว่าความไม่สะดวกระหว่างสร้างเสมอ
• เมื่อใส่มุมมองนี้เข้าไป โมเดลจะกลายเป็น user > ops > dev
• ซอฟต์แวร์จำนวนมากไปไม่ถึงโปรดักชันในสเกลที่มีความหมาย และถูกสร้างขึ้นบนสมมติฐานที่ยังไม่ได้รับการตรวจสอบ
• เมื่อปฏิบัติการโค้ดในโปรดักชัน KISS จะกลายเป็นปัญหาที่เกินกว่าระดับโค้ด คือ การลดชิ้นส่วนที่เคลื่อนไหวและทำความเข้าใจโหมดความล้มเหลว
• สิ่งสำคัญคือการดีพลอยบางสิ่งออกไป และรับประกันว่ามันยังทำงานได้แม้เกิดความล้มเหลว

ธุรกิจเป็นแกนแยกต่างหาก

• การพัฒนาโดยคิดถึงผู้ใช้จะพาไปได้ไกล แต่สมมติฐานที่ว่า “ซอฟต์แวร์ที่มีคุณค่าต่อผู้ใช้ ย่อมมีคุณค่าต่อองค์กรด้วย” เป็นนามธรรมที่ถูกทำให้ง่ายเกินไป
• จากมุมมองนักพัฒนา มันง่ายที่จะแยกว่าเราสร้างซอฟต์แวร์ที่ดี แล้วธุรกิจนำมันไปแปลงเป็นเงิน แต่ท้ายที่สุดจะมีช่วงเวลาที่ต้องรวม มุมมองทางธุรกิจ เข้ามาในกระบวนการทำงาน
• การแบ่งแบบนี้โดยทั่วไปใช้ได้กับซอฟต์แวร์ผู้บริโภคและซอฟต์แวร์องค์กร
• โมเดลขยายเป็น biz > user > ops > dev
• งบประมาณเป็นตัวอย่างที่ชัดที่สุด เพราะทรัพยากรในการตอบสนองความต้องการของผู้ใช้ไม่ได้มีไม่จำกัด จึงต้องวัดต้นทุนและผลประโยชน์
• การตลาด เดดไลน์ ผู้มีส่วนได้ส่วนเสีย นักลงทุน ผลประโยชน์ส่วนตัว และการเมืองก็ส่งผลต่อการตัดสินใจเช่นกัน
• การตัดสินใจที่ดูถูกต้องเมื่อมองเฉพาะซอฟต์แวร์ ทีม และผู้ใช้ อาจไม่ถูกต้องเมื่อพิจารณาทั้งองค์กร
• บางครั้งต้องทำ สิ่งที่สร้างรายได้ มากกว่าสิ่งที่ทำให้ผู้ใช้พอใจ

กลิ่นผิดปกติขององค์กรพัฒนาที่มองผ่านโมเดล

• โค้ดที่ดูแลรักษาไม่ได้: author > maintainer

  • โค้ดที่ฉลาดแต่ขี้เกียจกลายเป็นสปาเกตตีและ “ป่าผี”
  • รวมถึงปัญหาอย่างการ optimize ก่อนเวลาอันควร และโมดูลที่มีเพียงบางคนเท่านั้นที่แตะต้องได้

• ซอฟต์แวร์ที่ใช้ไม่ได้: dev > user

  • เกิดจากทีมที่ไม่เรียนรู้จากผู้ใช้ หรือทีมที่ให้ความสำคัญกับเทคโนโลยีก่อน
  • ตัวอย่างเช่น โปรแกรมที่ออกแบบเกินจำเป็น “การทำให้ทันสมัย” ที่ทำให้ประสบการณ์ผู้ใช้แย่ลง และเว็บแอปที่ทำให้ฟีเจอร์ของเบราว์เซอร์พัง

• “บนเครื่องผมใช้ได้นะ”: dev > ops

  • คือซอฟต์แวร์ที่ไม่ได้ออกแบบโดยคำนึงถึงการปฏิบัติการ
  • รวมถึงความซับซ้อนเกินจำเป็น เช่น ใช้ฐานข้อมูลหรูหรากับโหลดข้อมูลเล็ก ๆ หรือให้ทีมเล็ก ๆ ทีมเดียวดูแลระบบนิเวศไมโครเซอร์วิส
  • ซอฟต์แวร์ที่คนถูกปลุกกลางดึกเมื่อระบบล่มเป็นคนละคนกับคนออกแบบ ก็เข้าข่ายนี้เช่นกัน

• “สิ่งที่ถูกต้อง”: dev > biz

  • คือกรณีที่ปฏิบัติต่อโค้ดราวกับมันเป็นเป้าหมายในตัวเอง
  • ตัวอย่างเช่น ช่างฝีมือจอมโอ้อวด นักดนตรีบนเรือไททานิก และ Lisp Hackers

• การพัฒนาที่ขับเคลื่อนด้วยเรซูเม่: dev > *

  • คือซอฟต์แวร์ที่เกิดขึ้นเมื่อไม่มีอะไรเป็นเดิมพัน และนักพัฒนาสามารถทำตามที่ตนต้องการได้

• ซอฟต์แวร์ในจินตนาการ: biz > user > ops > dev

  • คือซอฟต์แวร์ที่สร้างขึ้นแล้ว แต่แทบไม่เคยหรือไม่เคยไปถึงโปรดักชันเลย
  • Charity Majors เรียกสิ่งนี้ว่า living a lie
  • ซอฟต์แวร์ที่ไม่มีผู้ใช้ก็จัดเป็นซอฟต์แวร์ในจินตนาการเช่นกัน คือกรณีที่ไม่ได้แก้ปัญหา หรือแก้ปัญหาผิด หรือแก้ปัญหาที่ไม่เคยมีใครมี
  • รวมถึงกรณีที่ถือเทคโนโลยีที่ถูกโฆษณาเกินจริงไปเคาะทุกอย่าง จนได้บางสิ่งที่ดูเหมือนกรณีใช้งานอันคลุมเครือออกมา

• “ทุนนิยมระยะปลาย”

  • คือกรณีที่ซอฟต์แวร์ที่พึ่งพาเงินลงทุนร่วมไม่มีโมเดลธุรกิจ หรือมีโมเดลธุรกิจที่เติบโตจนผูกขาดแล้วจึงเอาเปรียบผู้ใช้

ความตึงเครียดระหว่างผู้ใช้กับธุรกิจ

• biz > user มีผลกระทบที่ยอมรับได้ยาก
• วิธีที่เราเคยเรียนรู้ซอฟต์แวร์คือการแก้ปัญหาให้ผู้ใช้ปลายทาง และหนึ่งในคำแนะนำท้าย ๆ ของ The Pragmatic Programmer สรุปเป้าหมายไว้ว่าไม่ใช่แค่ส่งมอบโค้ด แต่ต้อง ทำให้ผู้ใช้พอใจ
• เมื่อซอฟต์แวร์แพร่หลายทั่วไป การรักษาสมมติฐานนี้ไว้ยิ่งทำได้ยากขึ้น
• ซอฟต์แวร์จำนวนมากไม่สนใจผู้ใช้ ชักจูงผู้ใช้ หรือเปลี่ยนผู้ใช้ให้กลายเป็นผลิตภัณฑ์
• ปัญหานี้ไม่ได้จำกัดอยู่แค่โซเชียลมีเดีย
  • แม้แต่การจองห้อง การสั่งอาหาร หรือการคลิกปุ่ม Start ของ Windows ก็มีป๊อปอัปที่พยายามดึงความสนใจของผู้ใช้
  • Google Search ถูกบรรยายว่าให้ผลลัพธ์ราวกับกองขยะ
• ความไม่สอดคล้องกันระหว่างสิ่งที่เราเคยเชื่อว่าเป็นการทำสิ่งที่ดี กับสิ่งที่อุตสาหกรรมส่วนใหญ่มองว่าทำกำไรได้ อธิบายความไม่สบายใจของผู้เชี่ยวชาญซอฟต์แวร์จำนวนมาก
• เราไม่สามารถย้อนกลับไปสู่อดีตที่เพิกเฉยต่อความเป็นจริงทางเศรษฐกิจได้ แต่จำเป็นต้องมี จุดยืนทางจริยธรรม ที่เข้มแข็งขึ้นเพื่อไม่ทำร้ายผู้ใช้
• ผู้ใช้อาจไม่ได้มาก่อนธุรกิจเสมอไป แต่ธุรกิจก็ไม่ควรมาก่อนโดยไม่มีเงื่อนไขเช่นกัน
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

ความคิดเห็นจาก Hacker News

• ผู้ใช้บางคนไม่ได้ใช้ระบบเพราะชอบ แต่ใช้เพราะ บริษัทซื้อมาแล้ว
  ในสถานการณ์แบบนี้ โดยนิยามแล้ว ธุรกิจมาก่อนผู้ใช้ และนักพัฒนาก็จะปรับให้ตรงกับความต้องการของผู้จัดการระดับกลางฝั่งลูกค้า มากกว่าผู้ใช้จริง เพราะถ้าไม่ทำแบบนั้นก็จะชนะสัญญาไม่ได้ สุดท้ายผู้ใช้จึงถูกผูกติดอยู่กับฟีเจอร์ที่ถูกทำมาแบบพอถูไถ ในขณะที่ทีมพัฒนายุ่งอยู่กับการทำฟีเจอร์ใหม่ ๆ ที่ผู้จัดการระดับกลางจะชอบ
  ฟังดูเหน็บแนมนิดหน่อย แต่ในฐานะวิศวกร การรู้ว่าตัวเองอยู่ในบริษัทประเภทนั้นโดยพื้นฐานหรือไม่ก็มีประโยชน์ เช่น ผู้ค้าปลีกออนไลน์จะอ่อนไหวต่อผู้ใช้มาก จนถึงขั้นมีเว็บไซต์คนละเวอร์ชันตามประเทศ เพราะชาวเยอรมันชอบ X ส่วนชาวอเมริกันชอบ Y การเปลี่ยนแปลงเล็ก ๆ อาจสร้างความแตกต่างด้านยอดขายได้มาก
  ในทางกลับกัน บางบริษัทแทบไม่อ่อนไหวต่อ ความง่ายในการใช้งาน เลย เพราะคนที่ซื้อผลิตภัณฑ์ไม่ใช่ผู้ใช้จริง

  • เคยทำงานที่บริษัทที่ขาย SaaS ให้บริษัทขนาดใหญ่
    เพื่อให้ได้สัญญา เราต้องทำให้ตรงตามเช็กลิสต์ของลูกค้า แต่เราก็ใส่ใจประสบการณ์ผู้ใช้ด้วย ประสบการณ์ผู้ใช้ที่ดีแทบไม่เคยเป็นข้อกำหนดที่เข้มงวดของลูกค้าเลย
    ซอฟต์แวร์ของคู่แข่งใช้งานแล้วทรมานมาก เราจึงอยากสร้างความแตกต่างในจุดนั้น และเพราะแบบนั้น การอบรมจึงง่ายขึ้น ผู้ใช้พึงพอใจมากขึ้น และเมื่อมีโอกาส พวกเขาก็แนะนำผู้จัดการของตัวเองให้ซื้อผลิตภัณฑ์ของเราเพิ่มด้วย
    ท้ายที่สุด 80% ของเรื่องนี้มาจากความภูมิใจและความเห็นอกเห็นใจว่า “ซอฟต์แวร์ของเราไม่ได้ห่วย” แต่ในระยะยาวมันก็เป็นประโยชน์กับเราเช่นกัน เพราะช่วยสะสมแบรนด์
  • เคยทำงานในบริษัทในตลาดที่มีโครงสร้างการซื้อคล้ายกัน แต่เรามุ่งเน้นเฉพาะผู้ใช้
    เราเลือก กลยุทธ์การเติบโตที่ขับเคลื่อนด้วยผลิตภัณฑ์ จึงไม่มีพนักงานขาย และทีมผลิตภัณฑ์ก็มุ่งเน้นประสบการณ์ผู้ใช้ทั้งหมด ปัญหาคือเราไม่ได้ขายให้ผู้ใช้ คนที่ซื้อซอฟต์แวร์เป็นคนกลุ่มอื่นในองค์กรของผู้ใช้ และไม่เคยมีประสบการณ์ใช้ผลิตภัณฑ์จริงโดยตรง
    เป็นแนวทางที่ถูกกำหนดไว้แล้วว่าต้องล้มเหลว เราต้องมี พนักงานขาย ที่เข้าใจสิ่งที่อยู่ในหัวผู้ซื้อ อธิบายประโยชน์ให้พวกเขาฟัง และโค้ชให้ผู้ใช้ไปอธิบายประโยชน์กับคนอื่น ๆ ภายในองค์กร ต้องเชื่อมช่องว่างระหว่างผู้ใช้กับผู้ซื้อ
  • โดยปกติผู้จัดการระดับกลางก็เป็นผู้ใช้เหมือนกัน แต่เป็นส่วนน้อยในฐานผู้ใช้ และฟีเจอร์ที่ใช้ก็แตกต่างออกไป เช่น รายงาน
    ดังนั้นจึงกลายเป็นคำถามว่าจะให้ความสำคัญกับผู้ใช้กลุ่มไหน และต้องหาสมดุลระหว่างการให้ความสำคัญกับประสบการณ์ของคนส่วนน้อยที่มีอิทธิพลต่อผู้ใช้อื่น ๆ กับการรักษาให้ผู้ใช้อื่น ๆ ยังใช้ผลิตภัณฑ์ได้มากพอที่จะให้ข้อมูลที่มีความหมายแก่ฝ่ายบริหาร
  • เคยเจอเรื่องแบบนี้ที่บริษัทที่ขายซอฟต์แวร์ให้เทศบาลเมือง
    สิ่งที่สำคัญมีแค่ความเห็นของนายกเทศมนตรี ผู้จัดการเมือง และสภาเมืองเท่านั้น ถ้ารายงานดูดีและราคาถูกต้อง ก็จะต่ออายุ
    ยังจำภาพในการประชุมภาคสนามได้ ที่คนที่ใช้มันทุกวันพูดต่อหน้าเราว่ามันเลวร้ายแค่ไหน ถึงอย่างนั้น โดยไม่มีข้อยกเว้น ลูกค้ารายนั้นก็ต่ออายุด้วยคำสัญญาว่าจะแก้บั๊กเฉพาะบางตัวและขึ้นราคาขั้นต่ำ
  • การที่นักพัฒนาต้องปรับตามความต้องการของผู้จัดการระดับกลางฝั่งลูกค้า แทนที่จะเป็นผู้ใช้จริง คือ เหตุผลที่ซอฟต์แวร์องค์กรทั้งหมดไม่ค่อยดี

• วันนี้เพิ่งรู้จักสัญลักษณ์ ≹ ว่ากันว่า “ใช้แสดงความสัมพันธ์ที่ในบรรดาสองสิ่งที่ถูกเปรียบเทียบ ไม่มีฝ่ายใดมากกว่าหรือน้อยกว่าอีกฝ่าย แต่ก็ไม่จำเป็นต้องกล่าวได้ว่าเท่ากัน เป็นความแตกต่างเชิงละเอียดอ่อนที่สำคัญในโดเมนที่มีวิธีเปรียบเทียบซึ่งไม่ใช่เชิงตัวเลขอย่างเคร่งครัด” (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • ตัวอย่างที่ยกว่าสำหรับจำนวนเชิงซ้อน z_1, z_2 มี z_1 ≹ z_2 นั้นแปลก
    เขียนเป็น |z_1| = |z_2| หรือก็คือจำนวนเชิงซ้อนสองตัวมีค่าสัมบูรณ์เท่ากัน น่าจะชัดเจนกว่า
    มีประโยคว่า “โดยสรุป สัญลักษณ์ ≹ มีบทบาทสำคัญในการเป็นพื้นที่กึ่งกลางระหว่างตัวดำเนินการความสัมพันธ์แบบดั้งเดิม” แต่ในฐานะนักศึกษาปริญญาเอกคณิตศาสตร์ ผมไม่เคยเห็นมันเลยสักครั้ง ยากจะเชื่อว่ามันมีบทบาทสำคัญ
  • รู้สึกว่ากลิฟนี้ควรเป็นผลจากการรวมอีโมจิแอปเปิลกับอีโมจิส้ม
  • นึกถึงแนวคิด เกม ในทฤษฎีเกมเชิงผสม
    เกมเป็นซูเปอร์เซตของจำนวนเหนือจริง และจำนวนเหนือจริงเป็นซูเปอร์เซตของจำนวนจริง โดยเป็นการผ่อนคลายนิยามของจำนวนเหนือจริงจนทำให้สูญเสียคุณสมบัติลำดับรวมไป
    ดังนั้นจึงเกิดจำนวนแปลก ๆ ที่ “อาจสับสนได้” หรือ “ฟัซซี” กับจำนวนอื่น ตัวอย่างที่ง่ายที่สุดคือ * (star) ซึ่งไม่มากกว่าและไม่น้อยกว่า 0 จึงสับสนกับ 0 ได้ มันเหมือนกลุ่มเมฆฟัซซีรอบ ๆ 0 และเขียนเป็น 0║*
    สวิตช์ ซึ่งเป็นเกมที่ซับซ้อนกว่า สามารถสับสนกับช่วงของจำนวนที่กว้างกว่า และถือว่า “ร้อน” หากใช้สวิตช์สร้างจำนวน ก็สามารถสร้างเกมร้อนที่น่าสนใจกว่านี้ได้
  • ผมมองว่าแนวคิดนี้สำคัญต่อการทำความเข้าใจลำดับเชิงเหตุใน ระบบกระจาย เช่น ในบริบทของ CRDT
    เหตุการณ์ที่เกิดบนอุปกรณ์เครื่องเดียวจะมีลำดับสมบูรณ์เสมอ แต่ถ้าสร้างเหตุการณ์บนอุปกรณ์สองเครื่องที่ออฟไลน์อยู่ เราไม่สามารถบอกได้ว่าอันไหนเกิดก่อน และจึงเกิดความสัมพันธ์ ≹ ระหว่างสองเหตุการณ์นั้น พูดอีกอย่างคือถือว่าเหตุการณ์เกิดพร้อมกัน
    ดังนั้นอาจเกิดลำดับ “d > b > a” และ “d > c > a” ได้ แต่จะเป็น “c ≹ b”
    การนิยามวิธีจัดการกรณีเสมอแบบนี้ให้ทำได้อย่างกำหนดแน่นอน เป็นส่วนสำคัญของปัญหาที่ CRDT แก้
  • ใน “ตัวอย่าง 1: บริบทเชิงตัวเลข” ของลิงก์ มีการยกจำนวนจริงสองตัว a และ b แล้วบอกว่าถ้า a ไม่มากกว่าและไม่น้อยกว่า b แต่ก็ไม่ได้ระบุชัดว่าเท่ากัน ความสัมพันธ์คือ ≹
    แบบนี้เป็นไปได้อย่างไร?

• สำหรับพวกเราหลายคน ต้นทุนของการรันโค้ด 1 พันล้านครั้งอาจถูกกว่าเวลาของนักพัฒนาไม่กี่นาที
  ถ้าใช้เงินค่าเซิร์ฟเวอร์บน AWS เดือนละ 200 ดอลลาร์ ก็สามารถรันโค้ดเว็บ API ของผมได้เป็นจำนวนมากถึง 100,000 ล้านครั้ง
  ดังนั้นการปรับให้เหมาะกับผู้อ่านที่เป็นมนุษย์จึงดีกว่าเสมอ และควรทำการปรับแต่งแบบอื่นก็ต่อเมื่อพิสูจน์ได้ว่ามันช้าจนรับภาระทางเศรษฐกิจไม่ไหวเท่านั้น

  • ผู้เขียนก็น่าจะคิดแบบเดียวกัน แต่ดูเหมือนเลือกชื่อเรื่องให้ชวนสับสน
    บทความจบด้วยสมการต่อไปนี้:
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    ข้อสรุปดูใกล้เคียงกับว่า โค้ดมีอยู่เพื่อผู้ใช้ปลายทางและธุรกิจ เครื่องหมาย ≹ ในสมการสุดท้ายสื่อได้อย่างเรียบร้อยว่า ความต้องการของผู้ใช้ปลายทางกับธุรกิจไม่เหมือนกัน แต่ทั้งสองฝ่ายสำคัญเท่ากันต่อการมีอยู่ของโค้ด
  • ปัญหาของการคำนวณว่า “ต้นทุนต่ำกว่าเวลาของนักพัฒนา” มักอยู่ตรงที่คนจ่ายต้นทุนนั้นไม่ใช่ตัวเอง
    ผู้ใช้เป็นคนจ่ายในรูปแบบที่เห็นไม่ชัด เช่น ค่าไฟที่สูงขึ้น อายุการใช้งานที่สั้นลง[0] โอกาสที่เสียไป ความหงุดหงิดที่มากขึ้น และการอัปเกรดฮาร์ดแวร์ที่ถี่ขึ้น
    อีกทั้งผู้ใช้ส่วนใหญ่ไม่ได้มีเงินเดือนหรือคุณภาพชีวิตแบบนักพัฒนา ความเสียหายจึงรู้สึกหนักกว่าเป็นหลายเท่า
    [0] การทำให้เวลาของคนอื่นสูญเปล่าคือการลด QALY
  • ในบทความไม่ได้ใช้คำว่า “รัน” ในความหมายง่าย ๆ ว่าแค่รันโปรแกรม
    แต่หมายถึงการดำเนินงานในโปรดักชันทั้งหมด รวมถึงการ deploy, upgrade, observe, audit, monitor, fix, decommission ฯลฯ
  • จากประสบการณ์ของผม latency เป็นสิ่งที่ต้องใส่ใจ เพราะมันกระทบประสบการณ์ผู้ใช้ การซื้อ latency ที่ดีกว่าด้วยเงินนั้นค่อนข้างยาก
  • ปฏิกิริยาที่คิดว่าจะได้อ่านคือแนวนี้ แต่บทความนี้เป็นอีกแบบหนึ่ง คุ้มค่าที่จะลองอ่านสักครั้ง

• ถ้าพูดนัยของชื่อเรื่องย้อนกลับไปหาผู้เขียน ก็คงไม่ใช่ “โค้ดถูกอ่านมากกว่าถูกใช้” แต่ใกล้กับว่า โค้ดที่อ่านไม่ออกจะรันอยู่ได้ไม่นาน
  อย่างไรก็ดี ผมเป็นผู้ดูแลระบบที่มีประสบการณ์และกำลังจะย้ายสายไปเป็นนักพัฒนา ในความหมายนั้นจึงเป็นมือใหม่เต็มตัว

  • มีโค้ดที่แข็งตัวแล้วอยู่จำนวนมาก ที่ผู้คนไม่เข้าใจจนกลัวจะแตะต้อง แต่ธุรกิจก็ยังพึ่งพาอยู่บนนั้น
  • ซอฟต์แวร์กรรมสิทธิ์ที่ไม่มีซอร์ส เช่น ไลบรารีของบุคคลที่สาม หรือระบบกล่องดำแทบทุกชนิด เป็นตัวอย่างโต้แย้งของนัยนั้น
  • ทั้งอุตสาหกรรมการเงินน่าจะไม่เห็นด้วย แล้วไม่คิดจะกลับมาจากวัยเกษียณชั่วคราวเพื่ออธิบายโค้ด COBOLของคุณให้นักพัฒนาคนอื่นฟังหน่อยหรือ?
  • ผมคิดว่าถ้ามีโครงสร้างพื้นฐานที่ถูกต้อง มันก็ยังรันต่อไปได้
    พูดให้แม่นกว่าคือ “โค้ดที่อ่านไม่ออกจะแก้ไขได้ต่อไปได้ไม่นาน”
  • ไม่ใช่ประเด็นที่แย่ แต่ดูเป็นคนละเรื่องมากกว่า
    ถ้าไม่ได้พูดถึงการทำ obfuscation โดยตั้งใจ โค้ดส่วนใหญ่คนที่เต็มใจลงแรงก็อ่านได้ และถ้าจำเป็นก็มี code formatter

• มีนัยที่อยากเสริมตรงนี้ ระหว่างแต่ละขั้นต่อไปนี้ จำนวนครั้งที่ใช้งานจะเพิ่มขึ้นแบบเอ็กซ์โพเนนเชียล

  1. ผู้ออกแบบภาษาและผู้พัฒนาไลบรารีมาตรฐาน
  2. ผู้พัฒนาโมดูลหรือไลบรารีที่ใช้ร่วมกัน
  3. นักพัฒนาทั่วไป
  4. ผู้ใช้ปลายทาง
     ในหลายภาษา อัตราส่วนของแต่ละขั้นอยู่ราว ๆ 1000 เท่า ดังนั้นต่อผู้ออกแบบภาษา 1 คน อาจมีคนออกแบบและเผยแพร่โมดูล 1000 คน นักพัฒนา 1 ล้านคน และผู้ใช้ 1 พันล้านคน ตัวเลขจริงอาจต่างกันมากตามสถานการณ์ แต่สำหรับการอภิปรายเชิงคุณภาพ ขนาดคร่าว ๆ นี้ถือว่าใกล้เคียง
     ประเด็นสำคัญคือ ความขี้เกียจเล็กน้อยมาก ๆ ในขั้นแรกหรือขั้นที่สองจะถูกทวีคูณอย่างรุนแรงในปลายน้ำ แฮ็กสกปรกที่ทำขึ้นในขั้นที่ 1 เพื่อประหยัดเวลา 1 นาที “เพื่อความสะดวกของตัวเอง” อาจทำให้ชีวิตอันมีค่าของคนอื่นสูญเปล่าเป็นล้าน ๆ ชั่วโมงจริง ๆ ไม่ว่าจะเพราะต้องรอซอฟต์แวร์ที่ช้า หงุดหงิดกับการแครช หรือเพราะการพัฒนาฟีเจอร์ในขั้นที่ 2 และ 3 ล่าช้าจนต้องรอ
     การรักษาระดับคุณภาพที่จำเป็นในสองขั้นแรกต้องอาศัยวินัยในตนเองและจริยธรรมส่วนบุคคลอย่างมหาศาล ในทางกลับกัน ทุกครั้งที่ได้ยินคนปกป้องจุดยืนที่ไม่อาจให้เหตุผลได้เกี่ยวกับการออกแบบภาษาหลักหรือไลบรารีมาตรฐาน ก็รู้สึกเศร้าใจอย่างลึกซึ้ง
     มักได้ยินคำพูดทำนองว่า “ถ้าคุณรู้ประวัติทั้งหมดที่ทำให้เกิดจุดคมนี้ขึ้นมาก็ไม่เป็นไร! ถ้าระวังตลอดไปก็ไม่ใช่ปัญหา มันไม่ unsafe ไม่เสี่ยงด้านความปลอดภัย ไม่ช้า และไม่เป็นปัญหา ตราบใดที่คุณไม่ใช้ผิด” เพราะรู้ว่าสิ่งเหล่านั้นจะทำให้นักพัฒนาสะดุดล้มไปอีกหลายสิบปี และทำให้ซอฟต์แวร์ของผู้คนนับล้านนับพันล้านช้าลง

• ดูเหมือนผู้เขียนหยิบกฎคร่าว ๆ ที่ค่อนข้างดีมา แล้วพยายามสร้างเป็นทฤษฎีสรรพสิ่ง
  มันดูเรียบร้อยและฉลาด แต่ถ้าตัดสำนวนที่ฝืน ๆ ออกไป ก็ใกล้เคียงกับการเอาคำพูดชัดเจนที่รู้กันทั่วไปมาเคี้ยวซ้ำ

  • theory > /dev/null
  • ถึงจะบอกว่า “สำนวนที่ฝืน ๆ” แต่เราควรนึกอยู่บ่อย ๆ ว่าในวงการนี้มีคนจำนวนมากที่ไม่ใช่เจ้าของภาษาอังกฤษ และไม่ได้อยู่ในประเทศที่ใช้ภาษาอังกฤษ แต่ก็พยายามเขียนเป็นภาษาอังกฤษ
    เพราะฉะนั้นสำนวนอาจดูขัด ๆ ได้
    และถึงจะเป็น “คำพูดชัดเจนที่รู้กันทั่วไป” บทความนี้ก็ร้อยเรียงสิ่งเหล่านั้นได้ดีเป็นพิเศษในแบบที่สอดคล้องกัน จึงเป็นเอกสารอ้างอิงที่มีประโยชน์
  • ผมคิดว่าการดัดแปลงกฎคร่าว ๆ และใช้การดัดแปลงนั้นมองสิ่งที่เราคิดว่ารู้อยู่แล้วอีกครั้งและจัดวางบริบทใหม่ ก็มีคุณค่าเช่นกัน
    สำหรับบางคน ทุกอย่างเป็นเรื่องใหม่ และแม้มันจะแค่ยืนยันอคติของผมเอง ก็ยังเป็นมุมมองที่น่าสนใจ
  • พูดให้แม่นกว่าคือ เป็นทฤษฎีสรรพสิ่งว่าทุกอย่างในงานพัฒนาซอฟต์แวร์สามารถผิดพลาดได้อย่างไร แต่ก็อ่านแล้วน่าสนใจ
  • ได้อ่านจนจบไหม? ที่เหลือทั้งหมดเป็นแค่เรื่องปูพื้น

• กรอบการเล่าเรื่องของผู้เขียนถูกเข้าใจผิดได้หลายแบบเกินไป จึงยากที่จะเป็นสำนวนย่อที่มีประโยชน์ได้ ระหว่างโทเค็นเหล่านี้ไม่มีลำดับความสำคัญแบบตายตัวได้เลย
  ก่อนอื่น “dev” ในที่นี้ไม่ใช่คนคนเดียว แต่เป็นกลุ่มคนที่มีความเชี่ยวชาญและประสบการณ์หลากหลาย ครอบคลุมองค์กรผลิตภัณฑ์ วิศวกรรม และดีไซน์ในหลายองค์กร
  “ops” ก็ไม่ใช่สิ่งเดียว และไม่ได้หมายถึงแค่การปฏิบัติการด้านวิศวกรรมเท่านั้น อาจรวมถึงปฏิบัติการทางธุรกิจ การสนับสนุนลูกค้า ฯลฯ ด้วย
  “biz” เองก็ไม่ใช่สิ่งเดียวเช่นกัน มีทั้งแบรนดิ้ง การตลาด ฝ่ายขาย ฝ่ายกฎหมายและผู้บริหาร คณะกรรมการ หน่วยงานกำกับดูแล สถาบันปล่อยกู้ นักลงทุน ฯลฯ
  คนทั้งหมดนี้ล้วนมีอิทธิพลต่อว่าโค้ดอะไรจะถูกเขียน เขียนอย่างไร และจะถูกปล่อยให้ผู้ใช้เมื่อไรและอย่างไร ทุกคนต้องแก้ ปัญหา เดียวกัน
  คนจำนวนมากในองค์กรมีอยู่เพื่อทำให้ทุกคนเข้าใจและมองเห็นปัญหาเดียวกัน และทำงานไปสู่เป้าหมายเดียวกัน
  แต่ความเข้าใจนั้นวิวัฒน์อยู่ตลอด และมีความล่าช้าในการแพร่กระจายไปทั่วทั้งองค์กร ดังนั้นแม้ทุกคนกำลังทำงานไปสู่เป้าหมายเดียวกัน ก็ยังมีความล่าช้าในขณะที่ตัวเป้าหมายเองกำลังเปลี่ยนไป
  สุดท้าย “user” ก็ไม่ใช่สิ่งเดียว และกลุ่มผู้ใช้ใด ๆ ก็ไม่ได้หยุดนิ่ง มีกลุ่มผู้ใช้หลากหลาย และพฤติกรรมของพวกเขาอาจไม่เสถียรในระยะยาว
  ดังนั้นจึงเป็นประโยชน์ที่จะเข้าใจและยอมรับว่าตัวแปรทั้งหมดรอบตัวเปลี่ยนไปอย่างไร แล้วตีความโลกที่ไม่สมบูรณ์และพังเสียหายในบริบทนั้น มิฉะนั้นจะเผลอไถลไปสู่ความคิดว่า คนอื่นทุกคนแย่ไปหมด ทุกอย่างพังหมด จึงอยากสร้างทุกอย่างใหม่ตั้งแต่ศูนย์

• ดีใจที่ได้เห็นประเด็นที่ใกล้เคียงกับจริยธรรมถูกนำมาถกกัน
  ในตอนที่บทความบอกว่า “ผมคิดว่ามีความไม่สอดคล้องกันระหว่างสิ่งที่เราคิดว่าเป็นการทำสิ่งที่ดี กับสิ่งที่อุตสาหกรรมส่วนใหญ่เห็นว่าทำกำไรได้ และนี่คือเหตุผลที่ความไม่สบายใจของผู้เชี่ยวชาญด้านซอฟต์แวร์จำนวนมากเพิ่มขึ้น” คำว่า ความไม่สบายใจ ถือว่าเบาไปมาก ยังมีอีกหลายอย่างที่ไม่ได้ถูกพูดออกมา
  อยากเสริมคำถามบางข้อเข้าไปด้วย จะเกิดอะไรขึ้นเมื่อผู้ใช้ไม่ใช่ลูกค้า หรือก็คือไม่ใช่คนที่จ่ายเงิน? ธุรกิจมีพันธะทางจริยธรรมต่อผู้ใช้ทุกคน รวมถึงผู้ใช้ที่ไม่ได้จ่ายเงินหรือไม่? จะเกิดอะไรขึ้นหากลูกค้าที่จ่ายเงินต้องการใช้ธุรกิจของคุณในแบบที่สร้างผลกระทบปลายน้ำเชิงลบต่อผู้ใช้?
  ตัวอย่างเช่น ถ้าแพลตฟอร์มทำให้การฉ้อโกงง่ายกว่าทางเลือกเดิม ทำให้การแพร่ข้อมูลเท็จง่ายขึ้น หรือทำให้การ shaping ความคิดเห็นของผู้ใช้ในแบบที่ทำลายล้างระยะยาว แต่ดึงดูดและก่อให้เกิดนิสัยทำได้ง่ายขึ้น จะเป็นอย่างไร? สิ่งเหล่านี้ทั้งหมดเคยพิสูจน์มาแล้วว่าเป็นโมเดลธุรกิจที่ประสบความสำเร็จได้ในช่วงเวลาหนึ่ง
  หากพลวัตเหล่านี้เป็นความจริง ธุรกิจควรไล่ตามโมเดลที่เอารัดเอาเปรียบเช่นนั้นหรือไม่? ถ้าไล่ตาม จะทำได้อย่างรับผิดชอบมากขึ้นหรือไม่? ธุรกิจเวอร์ชันที่มีจริยธรรมมากกว่าจะช่วยบรรเทาแนวโน้มที่เลวร้ายที่สุดของคู่แข่งได้หรือไม่ หรือท้ายที่สุดก็กลายเป็นส่วนหนึ่งของปัญหา?
  ข้อสรุปหลักชัดเจน ปัญหาบางประเภทใหญ่และสำคัญกว่าโมเดลธุรกิจ มีปัญหาที่อาจวางกรอบได้ว่า “ต้องมีบรรทัดฐานและกฎแบบใด จึงจะทำให้บริษัทต่าง ๆ ทำงานอยู่ภายในขอบเขตสามัญสำนึกระดับหนึ่งได้”
  สุดท้ายอยากทำให้ชัดเจน ธุรกิจส่งมอบชุดของ คุณค่า โดยเนื้อแท้ และหลีกเลี่ยงไม่ได้ แม้จะยึดจุดยืนเพียงว่า “ความนิยมชนะ” นั่นเองก็เป็นการเลือกที่มีนัยลึกซึ้งต่อคุณค่า นักรัฐศาสตร์และนักประวัติศาสตร์รู้จักปัญหาเรื่องทรราชเสียงข้างมากมานานแล้ว ไม่ว่าปรัชญาการเมืองของคุณจะเป็นแบบไหน ก็เป็นเรื่องที่ควรคิด
  ไม่รู้ว่าระบบจริยธรรมที่ “ดีที่สุด” คืออะไร แต่รู้ว่าจริยธรรมบางแบบดีกว่าอีกบางแบบ และหวังว่าเราจะปรับปรุงจริยธรรมของเราต่อไป แทนที่จะปล่อยไว้โดยไม่ตรวจสอบ

  • ผมมองว่านี่เป็นคนละปัญหากับปัญหาที่บทความพูดถึง
    คุณสามารถเลือกได้ว่าปัญหาและขอบเขตแบบใดสอดคล้องกับจริยธรรมของตนเอง บทความนี้พูดถึงวิธีสร้างระบบและวิธีจัดลำดับความสำคัญของงาน

• ธุรกิจไม่ได้มีอยู่จริง ๆ แต่เป็น โครงสร้างเชิงจินตนาการ ที่เราสร้างขึ้นเพื่อจัดระเบียบทรัพยากรและทำงานร่วมกัน
  ธุรกิจไม่ได้สำคัญเหนือสิ่งอื่นใด ผู้ใช้มีหลายคน และบางครั้งผลประโยชน์ก็ขัดแย้งกัน เราไม่อาจอยู่ได้ทุกที่หรือเป็นทุกอย่างได้ จึงต้องจัดลำดับความสำคัญ การมุ่งหาผู้ใช้ที่ทำกำไรได้มากกว่า หรือผู้ใช้ที่สอดคล้องกับกลยุทธ์ระยะยาว อาจดูเหมือนว่า “ดีต่อธุรกิจ” แต่จริง ๆ แล้วเป้าหมายคือการรับใช้ผู้ใช้ เพียงแต่อ้อมผ่านอีกหลายขั้นเท่านั้น
  หากการเมืองภายในยุ่งเหยิงจนถึงขั้นตัดสินใจเพื่อผลประโยชน์ของธุรกิจล้วน ๆ โดยไม่พิจารณาว่าสิ่งนั้นจะเชื่อมโยงไปสู่ความสุขของผู้ใช้อย่างไร องค์กรนั้นก็กลายเป็นพิษแล้ว ไม่ควรมีอยู่อีกต่อไป แม้มันอาจโซซัดโซเซไปได้อีกพักหนึ่งในสภาพซอมบี้ แต่กำลังอยู่ในขาลง และคนเก่ง ๆ ทั้งหมดจะจากไป

  • การบอกว่าธุรกิจไม่ได้มีอยู่จริง ก็คล้ายกับการบอกว่าอารมณ์ไม่ได้มีอยู่จริง
    อาจพูดได้ว่าอารมณ์ก็เป็นเพียงโครงสร้างที่เราสร้างขึ้นเพื่ออธิบายปฏิกิริยาต่อสถานการณ์ แต่การที่มันไม่ได้ประกอบขึ้นจากอะตอมไม่ได้แปลว่ามันไม่ “เป็นจริง”
    ธุรกิจมีอยู่จริงในฐานะปัจจัยหลักที่กำหนดชีวิตของคนส่วนใหญ่ มันหล่อหลอมเมือง สื่อ กฎหมาย การเมือง และนโยบายต่างประเทศ และส่งอิทธิพลอย่างมากต่อแทบทุกสิ่งที่สำคัญ ไม่ว่าจะเป็นจริงในเชิงภววิทยาหรือไม่ มันก็มี ผลกระทบจริง ต่อสิ่งรอบตัวเรา
    นอกโลกโอเพนซอร์ส ค่อนข้างชัดเจนว่าผู้ที่จ่ายเงินเป็นผู้กำหนดว่าสิ่งต่าง ๆ จะถูกสร้างขึ้นอย่างไร แม้ว่าการตัดสินใจนั้นจะไม่ดีต่อผู้จ่ายเงินเอง ไม่ดีต่อผู้ใช้ และไม่ดีต่อสาธารณะทั่วไปหรือสิ่งแวดล้อมก็ตาม แน่นอนว่ามีอุตสาหกรรมและกฎระเบียบของรัฐอยู่ แต่โดยทั่วไปบริษัทเป็นฝ่ายมีอำนาจตัดสินใจ
  • นี่ไม่จริง ธุรกิจมีอยู่ในฐานะ โครงสร้างทางกฎหมาย และมีหลายอย่างที่ดีต่อธุรกิจแต่เลวร้ายต่อแทบทุกคน นอกจากนี้ ธุรกิจไม่ได้มีอยู่เพื่อรับใช้ผู้ใช้
    น่าเสียดายที่ธุรกิจมีอยู่เพื่อรับใช้เจ้าของ ในกรณีส่วนใหญ่ โดยเฉพาะบริษัทใหญ่ที่ไม่ใช่กิจการขนาดจิ๋วต่ำกว่า 5 คน เจ้าของต้องการเงิน ดังนั้นทุกคนในบริษัทจึงมีอยู่เพื่อหาเงินให้เจ้าของมากขึ้น ความสุขของคนอื่น แม้แต่ความสุขของผู้ใช้ ก็ไม่เกี่ยวข้องเลย เว้นแต่เมื่อมันสัมพันธ์กับรายได้
    แรงจูงใจสากลอีกอย่างหนึ่งภายในบริษัทคือการรักษาตัวเองให้อยู่รอด ดังนั้นนอกจากการหาเงินแล้ว ผู้มีอำนาจตัดสินใจยังคำนึงถึงความมั่นคงของงานของตนเองด้วย
    พนักงานไม่ได้ลาออก เพราะบริษัททำให้พวกเขาพอใจมากพอ จ่ายเงินดี และทำให้รู้สึกเหมือนเป็นส่วนหนึ่งของ “ชุมชน” การทำให้คนทำงานต่อไปในองค์กรที่ชั่วร้ายหรือไร้ใบหน้านั้นง่ายอย่างน่าประหลาดใจ ลองดูสำนักงานของ FAANG ก็จะเห็นรายการละเอียดของกลเม็ดด้าน HR เหล่านี้
    ผมเห็นด้วยว่าบริษัทแบบนี้เป็นพิษและไม่ควรมีอยู่ แต่ในความเป็นจริง บริษัททำงานแบบนี้ นี่ไม่ใช่สัญญาณของความเสื่อมถอย แต่เป็นภาพของธุรกิจที่เติบโตเต็มที่และแข็งแรง ซึ่งสามารถดำรงอยู่ได้นานหลายทศวรรษ ผู้บริหาร ผลิตภัณฑ์ และเจ้าของอาจเปลี่ยนไป แต่ธุรกิจยังคงอยู่
  • ตอนแรกผมก็มีปฏิกิริยาแบบเดียวกัน เห็นบทความที่สรุปได้ว่า เงิน > คน แล้วมันดูผิด
    แต่ความสำคัญเป็นเรื่องอัตวิสัย ถ้าเป็นโค้ดส่วนตัวเพื่อความสนุกของตัวเอง ธุรกิจก็ไม่สำคัญ ถ้าอยากเปลี่ยนมันให้เป็นแหล่งรายได้หลัก ธุรกิจก็สำคัญที่สุด เพราะถ้าซอฟต์แวร์ไม่สามารถรับใช้ใครได้ ต่อให้ผู้ใช้ชอบแค่ไหน ก็ไม่แปรเป็นรายได้จริง
  • ลองตีความ “ธุรกิจ” ในที่นี้อย่างใจกว้างว่าเป็น “โมเดลเงินทุนที่ยั่งยืน ซึ่งรองรับการบำรุงรักษา การสนับสนุน และการพัฒนาในอนาคตได้”
    หากไม่มีโมเดลธุรกิจ ซอฟต์แวร์ที่ยอดเยี่ยมซึ่งผู้ใช้ชอบ แจกจ่ายได้ และบำรุงรักษาได้ ก็อาจค่อย ๆ มอดลงได้

• ตอนแรกผมก็สงสัย แต่ผมชอบ โมเดลการคิด นี้
  แน่นอนว่าไม่ควรทำตามอย่างมืดบอด มีข้อยกเว้นที่ dev > biz อยู่เหมือนกัน เหตุการณ์ OpenAI ก็เป็นเช่นนั้น และก็มีข้อยกเว้นที่ dev > ops ด้วย ในสตาร์ทอัพระยะเริ่มต้นจำเป็นต้องเคลื่อนที่เร็ว ดังนั้นโดยเฉพาะเพราะเหตุผลทางธุรกิจ dev > ops จึงอาจเกิดขึ้นได้