ต้นทุนที่ YAGNI ไม่เคยพูดถึง

 (newsletter.kentbeck.com)
3 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • YAGNI ไม่ใช่กฎประหยัดง่าย ๆ ที่บอกว่า “อย่าเขียนโค้ดที่ยังไม่จำเป็น” แต่เป็นหลักการที่พูดถึงต้นทุนของการ ยึดโครงสร้างไว้ล่วงหน้าจากการคาดเดา ก่อนที่ความต้องการจะได้รับการยืนยัน
  • แก่นของปัญหาไม่ใช่ตัวการออกแบบเอง แต่คือ ควรออกแบบเมื่อไร และการจัดโครงสร้างเร็วเกินไปก็อาจเสี่ยงพอ ๆ กับการจัดโครงสร้างช้าเกินไป
  • โครงสร้างที่ทำไว้ล่วงหน้าสร้างทั้ง ต้นทุนของทางเลือก จากการปิดตัวเลือกก่อนที่ข้อมูลจะมาถึง และ ต้นทุน NPV จากการดึงต้นทุนมาไว้ข้างหน้าและเลื่อนผลตอบแทนออกไป
  • ต่อให้ต้นทุนการสร้างโค้ดลดลงจนแทบเป็นศูนย์ YAGNI ก็ไม่ได้หายไป กลับกัน การสร้างที่ราคาถูกอาจทำให้สร้าง framework ที่อิงการคาดเดา ได้ง่ายขึ้น
  • ข้อสรุปที่ว่าให้สร้างเมื่อจำเป็น ไม่ได้มาจากต้นทุนการเขียนโค้ด แต่เพราะคุณค่าของ ทางเลือก ที่ยังไม่ใช้ และ เงิน ที่ยังไม่จ่าย ยังคงมีอยู่

YAGNI ไม่ได้ห้ามการออกแบบ

  • YAGNI ย่อมาจาก “You Aren’t Gonna Need It” และไม่ใช่ข้ออ้างว่าจะต้องไม่ออกแบบสิ่งที่ยังไม่จำเป็นโดยเด็ดขาด
  • ถ้าจำเป็นก็สร้างได้ แต่ประเด็นสำคัญคือ จังหวะเวลา
  • จุดตั้งต้นมาจากเรื่องเล่าว่า ระหว่างทำโปรเจกต์ เมื่อมีสถานการณ์แบบ “อีก 3 สัปดาห์ implementation แบบง่ายคงไม่พอ งั้นอยากทำอะไรที่ซับซ้อนกว่านี้ตั้งแต่ตอนนี้” ก็จะมีคำตอบกลับมาซ้ำ ๆ ว่า “You aren’t going to need it”
  • หลักการนี้มองว่าทั้งการสร้างโครงสร้างเร็วเกินไปและช้าเกินไปต่างก็มีความเสี่ยง

ปัญหาไม่ใช่ต้นทุนการเขียนโค้ด แต่คือโครงสร้างที่ตั้งอยู่บนการคาดเดา

  • การตีความที่พบบ่อยคือมอง YAGNI เป็น กฎประหยัด แบบ “โค้ดที่ยังไม่จำเป็นมีราคาแพง จึงไม่ควรเขียน”
  • แต่สิ่งที่ YAGNI มุ่งเป้าไม่ใช่ต้นทุนการผลิตโค้ด หากเป็น โครงสร้างเชิงคาดการณ์ (speculative structure) ที่สร้างไว้ล่วงหน้าก่อนที่ฟีเจอร์จริงจะต้องการมัน
  • โครงสร้างแบบนี้ก่อให้เกิดต้นทุนอยู่ 2 ประเภท ด้วยจังหวะเวลาและเหตุผลที่ต่างกัน

ต้นทุนประเภทแรก: ทางเลือก

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

ต้นทุนประเภทที่สอง: NPV

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

ต่อให้การสร้างโค้ดถูกลง YAGNI ก็ยังอยู่

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • มองว่า ต้นทุนในการเปลี่ยนโครงสร้าง ก็ลดลงเช่นกัน
    ด้วย AI ต้นทุนในการเสริมการทำงานด้วยเทสต์ก่อนเปลี่ยนโครงสร้างลดลง และต้นทุนในการทำ migration แบบไม่มี downtime ก็ลดลงด้วย
    หนึ่งในเหตุผลสำคัญที่ Rust ได้รับความสนใจตั้งแต่ก่อนยุค AI ก็คือต้นทุนในการเปลี่ยนโครงสร้างภายในแอปพลิเคชันต่ำ และตอนนี้ก็ยิ่งเป็นเช่นนั้น
    ค่าเสียโอกาสจากการไม่สามารถเปลี่ยนโครงสร้างได้อย่างปลอดภัยเพิ่มขึ้นมาก และตอนนี้จึงปรับให้ความสามารถในการเปลี่ยนส่วนใหญ่ของโค้ดและผลิตภัณฑ์ได้อย่างรวดเร็วและปลอดภัยเป็นสิ่งสำคัญที่สุด

    • ความสามารถในการเปลี่ยนส่วนใหญ่ของโค้ดและผลิตภัณฑ์ได้อย่างรวดเร็วและปลอดภัยนั้นเดิมทีก็เป็นสิ่งที่ดีอยู่แล้ว และมีคุณค่าโดยไม่เกี่ยวกับการมาถึงของ AI coding
      เพียงแต่ก่อนยุค AI การเปลี่ยนโครงสร้างใช้เวลานานกว่ามาก ดังนั้นอาจมองได้ว่าคุณค่าของสิ่งที่กำลังพยายาม optimize ในตอนนี้กลับลดลงก็ได้
      ยังมีคุณค่าอยู่ แต่บางทีอาจน้อยกว่าเมื่อก่อนเล็กน้อย
    • เห็นด้วยได้ยาก
      เมื่อ เทสต์ที่ AI สร้างซึ่งเปราะบาง เพิ่มขึ้น ต้นทุนในการเปลี่ยนโครงสร้างจึงสูงกว่าเดิม
      การจัดระเบียบชุดเทสต์ให้ตรวจสอบแก่นของปัญหา ไม่ใช่ตรวจสอบการตัดสินใจเชิงออกแบบที่เกิดขึ้นโดยบังเอิญ ยังเป็นสิ่งที่ AI ทำได้ไม่ดี
    • ถูกต้อง
      แต่ถ้าไม่ทำแบบนั้น การได้ ชุดเทสต์ที่เปราะบาง ซึ่งสุกงอมแค่ราว 75% ก็ง่ายเกินไป
      หลายคนพอใจโดยมองว่าการเปลี่ยนจาก “เทสต์ธรรมดาและเปราะบางไม่กี่ตัวที่คนเขียน” ไปเป็น “เทสต์ธรรมดาและเปราะบางจำนวนมากที่ AI เขียน” คือการปรับปรุงอย่างเป็นรูปธรรม
      เห็นด้วยอย่างยิ่งว่าควรใช้เครื่องมือในลักษณะนี้ แต่จึงยังบอกได้ยากว่าไม่ต้องกังวลกับการสร้างปราสาทลอยฟ้าที่ผิดพลาดเร็วเกินไป
      สัญญาของเทสต์ที่สมบูรณ์แบบและทนต่อการ refactoring ยังออกแบบได้ค่อนข้างยากอยู่ดี
    • เรื่องนี้ทำให้นึกถึง Open-Closed Principle ที่ว่า “เปิดให้ขยาย ปิดไม่ให้แก้ไข”
      ของเก่ากลับมาเหมือนเป็นของใหม่อีกครั้ง
      ตั้งแต่ประสิทธิภาพด้าน context ของแนวทางอย่าง DDD หรือ Clean Architecture ไปจนถึงประเด็นเหล่านี้ AI ไม่ได้สร้าง trade-off ใหม่ แต่ทำงานเหมือน เครื่องขยายสัญญาณ
      มันเพิ่ม productivity ของทีมที่ทำอย่างถูกต้อง และเพิ่มหนี้ของทีมที่มีมาตรฐานด้านคุณภาพการออกแบบและสถาปัตยกรรมต่ำด้วย
    • ดูเหมือนว่ากำลังเพิ่ม การคลำทางแบบสะเปะสะปะ มากขึ้นเรื่อย ๆ โดยเดิมพันว่า AI จะช่วยแก้ให้แทน
      สิ่งที่ได้มาก็มีแค่ไม่ต้องคิดให้ลึกเท่านั้น
      การคิดให้ลึกไม่ได้ใช้เวลาหรือความพยายามมากขนาดนั้น ดังนั้นจะถูกคนที่ใช้ AI แบบเดียวกันแต่คิดมากพอไม่ให้กลายเป็นการคลำทางสะเปะสะปะทิ้งห่างไป

  • Kent Beck เปรียบโค้ดที่ยังไม่ได้เขียนกับ financial option ที่ซื้อได้ในราคาหนึ่ง
    แต่นั่นก็เป็นเพียงคำเปรียบเทียบ และถ้าลากไปไกลเกินก็จะเริ่มแปลก
    ถ้ายังไม่ได้เขียนโค้ดเลย ตัวเลือกจะไม่มีที่สิ้นสุดหรือ? แม้ยังไม่ได้ใช้เวลา ก็ดูไม่น่าจะถูก
    มันอาจกลายเป็นเหตุผลให้ค้างอยู่ในขั้นวางแผนและเลื่อนการเขียนโค้ดออกไปไม่มีกำหนด เพื่อไม่ต้องตัดสินใจอะไรเลย
    อย่างไรก็ดี หากคำเปรียบนี้ใช้ได้ ต้นทุนอาจอยู่ที่การอ่านโค้ด
    โค้ดที่ไม่ได้เขียนก็ไม่จำเป็นต้องอ่าน และถ้าใช้ coding agent ก็ไม่ทำให้ context รกด้วยรายละเอียดที่ไม่เกี่ยวข้อง
    โค้ดที่ยังไม่ได้เขียนก็ไม่ต้องทดสอบ และเทสต์ที่ยังไม่ได้เขียนก็ไม่กินเวลาในการรัน
    ดังนั้นจึงควรรักษาโปรเจกต์ให้เล็กที่สุดเท่าที่ทำได้ และการเลื่อนฟีเจอร์ออกไปจะช่วยชะลอการเติบโตของ codebase ได้มากที่สุด
    นั่นยังหมายความว่าการรันโค้ดของคนอื่นช่วยหลีกเลี่ยงต้นทุนได้มากมาย
    หากใช้ API มาตรฐานได้ ก็ไม่จำเป็นต้องเข้าใจ implementation อย่างละเอียดหรือรันเทสต์ของมัน แต่การเพิ่ม dependency ก็มีความเสี่ยง

    • ใน “Tidy, First?” ของ Kent มองว่าซอฟต์แวร์สร้างคุณค่าได้สองแบบ: งานที่ทำวันนี้ และความเป็นไปได้ที่จะทำสิ่งใหม่ในวันพรุ่งนี้
      โค้ดที่ไม่ได้เขียน ไม่มีคุณค่า
      เพื่อให้โค้ดที่เขียนในวันนี้สร้างคุณค่าได้ มันต้องแก้คำขอหรือ issue ของวันนี้ หรือเอนเอียงไปทางทำให้บางอย่างในวันพรุ่งนี้ง่ายขึ้น
      หากก่อหนี้ทางเทคนิคด้วยวิธีแก้แบบ hacky หรือเสียเวลากับสิ่งที่ขัดกับ YAGNI ก็ไม่ได้สร้างคุณค่า
      สิ่งสำคัญไม่ใช่โค้ดที่ไม่ได้เขียน แต่เป็นโค้ดที่จะเขียนต่อจากนี้และจุดประสงค์ของมัน
      ต้องประนีประนอมให้ถูกต้องระหว่างการแก้ ticket/สิ่งที่ต้องทำของวันนี้ กับการไม่ยิงเท้าตัวเองในอนาคต
      การเขียนโค้ดคือ คำมั่นสัญญา และคุณค่าของวันนี้มองเห็นได้ แต่คุณค่าของวันพรุ่งนี้ใกล้เคียงกับการคาดประมาณ
      ถึงอย่างนั้น ต้นทุนที่ต้องจ่ายภายหลังก็มีอยู่เสมอ จึงต้องคาดเดาว่าอะไรจะจำเป็นเพื่อพยายามลดต้นทุนให้น้อยที่สุด

  • คิดว่าไม่ได้เน้น best practices ในยุค AI มากพอ แต่มีส่วนหนึ่งที่ Kent พลาดไปจริง ๆ
    การค้นหาให้เร็วขึ้นว่าฟีเจอร์ที่จำเป็นคืออะไรมีคุณค่ามาก
    การสร้างโครงสร้างเชิงคาดเดาอาจเป็นกลไกบังคับให้ requirement ชัดเจนขึ้น และอย่างน้อยก็เริ่มเผยให้เห็นรูปแบบความล้มเหลว
    เพราะอาจแพงกว่าการรอ จึงไม่ควรทำแบบนั้นกับ requirement ส่วนใหญ่ แต่บางครั้งอาจเป็นทางเลือกที่ดีที่สุด
    ต้นทุนในการสร้างสิ่งที่ผิดลดลงมากแล้ว ดังนั้นการคำนวณเกี่ยวกับ YAGNI ก็เปลี่ยนไป
    แต่ก็ยังต้องคำนวณอยู่ดี และตอนนี้แต่ละทีมต้องหาคำตอบเองว่าสำหรับพวกเขามันเปลี่ยนไปอย่างไร

    • ถ้าสร้างโครงสร้างเชิงคาดเดาเป็น spike แล้วทิ้งไปก็โอเค
      ถ้าไม่ทิ้ง มันก็จะกลายเป็นกลไกบังคับให้ได้ผลลัพธ์ที่เละเทะ
    • มองว่าฟีเจอร์ที่จำเป็นมาจาก requirement และการออกแบบระบบที่จะตอบสนอง requirement นั้นอยู่แล้ว
      YAGNI คือปัญหาของการสร้างสิ่งที่ไม่ได้อยู่ใน requirement ปัจจุบัน เพราะคาดว่า requirement จะเปลี่ยนในภายหลัง
      มันต่างจากการทำให้ requirement และข้อจำกัดปัจจุบันเป็นรูปธรรม
      สิ่งเหล่านั้นส่วนใหญ่มาจากการสนทนากับ stakeholder·ผู้ใช้·ลูกค้า ทรัพยากร ข้อจำกัดทางวิศวกรรม และขีดความสามารถ
      prototype มีคุณค่าเมื่อคุยกับ stakeholder สร้างโมเดลการจัดการโปรเจกต์ หรือทำการวิจัยทางวิศวกรรม
      นอกเหนือจากนั้นคือการกลับเหตุและผล

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

  • เมื่อถึงจุดหนึ่ง ความคิดก็เปลี่ยนไป
    เลื่อนสิ่งที่เป็นรูปธรรมออกไปด้วย YAGNI และเขียน เวอร์ชันที่เป็นนามธรรม ให้มากที่สุดเท่าที่ทำได้
    จะสร้าง UserStore ดีไหม? นั่นดูเหมือนจะเรียบง่ายที่สุด แต่เราอาจไม่จำเป็นต้องมีรูปแบบเฉพาะอย่าง User ก็ได้
    ดังนั้นจึงสร้าง Store ที่เก็บอะไรก็ได้ที่สามารถจัดเก็บได้
    ถ้าไม่คุ้นเคย มันอาจดูเหมือนการออกแบบเกินจำเป็นและ เต็มไปด้วย generic แต่กลับกัน มันเป็นวิธีที่ให้คำมั่นกับการใช้งานจริงแบบใดแบบหนึ่งน้อยที่สุด

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

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

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

  • ไม่นานมานี้ต้องแยกตัวออกจากโค้ดเบสที่สะสม YAGNI ไว้เต็มไปหมดในเชิงฟังก์ชัน และแม้จะมีเอเจนต์ก็ยังเป็น งานมหึมา
    ในระบบแบบกระจาย เราจะรู้ได้อย่างไรว่าอะไรยังถูกใช้งานจริง? มีทั้งสิ่งที่ผมพลาดและสิ่งที่เอเจนต์พลาด และทั้งหมดใช้เวลานานเกินจำเป็น
    นี่ไม่ใช่แค่การพอร์ตแบบ 1:1 ธรรมดา แต่ใช้เป็นโอกาสในการทำให้เรียบง่ายลงด้วย จึงต้องเข้าใจอย่างถ่องแท้ว่าระบบเดิมทำงานอย่างไร
    สิ่งที่จริง ๆ แล้วไม่ได้ถูกใช้งานเลย หากระบุไม่ได้ว่าเป็นเช่นนั้น ก็ยังต้องรวมอยู่ในขอบเขตที่ต้องทำความเข้าใจ

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

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

  • ผมไม่เคยเห็นอะไรในงานเขียนของ Kent Beck ที่น่าจะเป็นประโยชน์ต่อ บริษัทชิป
    ในบริษัทชิป คนจำนวนมากต้องทำงานเป็นเวลานาน ลูกค้าจะไม่เห็นอะไรเลยจนกว่าจะเสร็จ และถ้าจะทำเงินได้ก็ต้องขายในระดับหลายล้านชิ้น

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