Categories
Agile การพัฒนาซอฟท์แวร์

Technical Debt กับการล้มละลายของซอฟท์แวร์

ผมยกให้โพสนี้เป็น Post of the day ของเมื่อวานเลย ผมชอบมาก มันสะท้อนสถานะการจริงได้ดี แสดงผลกระทบจากการที่ Developer ไม่สามารถเข้าไปมีส่วนในการกำหนดระยะเวลาในการพัฒนางานได้ ทำให้เกิดการเผางาน ลูกค้าอาจได้งานเร็วดังใจ แต่มันเหมือนระเบิดเวลาที่พร้อมจะทำให้ทุกอย่างพินาศในอนาคต สุดท้ายโพสนี้ได้นำเสนอวิธีการแก้ปัญหาที่สามารนำไปปรับใช้ได้ตามสถานะการณ์ได้อีกด้วย

ที่มา https://medium.com/the-way-it-should-be/efb39c7b7699

การล้มละลายของซอฟท์แวร์

How to Avoid “Technical Bankruptcy”

The Way It Is

Manager: “เรื่องเชื่อมต่อธนาคาร ABC จะเสร็จวันไหนครับ?”

Junior Developer: “น่าจะศุกร์หน้าค่ะ”

Manager: “ช้าไปอะครับ พี่บอกลูกค้าไปแล้วว่าเราจะจ่ายเงินผ่านธนาคาร ABC ได้วันศุกร์นี้ ถ้าเสร็จไม่ทันมีหวังลูกค้าไม่จ่ายเงินงวดที่เหลือแน่”

Junior Developer: “แต่หนูคิดว่าถ้าจะทำให้ดีมันต้องใช้เวลานิดนึงอะค่ะ เพราะว่า …”

Manager: “พี่ขอนะรอบนี้ ทำอะไรที่มันง่ายๆไปก่อนได้มั้ย พี่ไม่อยากมีปัญหากับลูกค้า รายใหญ่ซะด้วยครับ”

Junior Developer: “อ่อ ค่ะ”

Manager: “ได้นะ เสร็จศุกร์นี้เลยนะ”

Junior Developer: “ค่ะ”

The Way It Should Be

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

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

ถ้าคุณ Manager ไม่รีบร้อนตัดบทไปซะก่อน … บทสนทนาข้างบนจะมีเนื้อหาเพิ่มเติมแบบนี้

  • ทางเลือกที่หนึ่ง: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ตอนนี้ หลังจากนั้น 21 แต้ม (เพื่อการทำ Refactoring ใน Sprint หน้า) แล้วหลังจากนั้น 1 แต้มสำหรับทุกๆการเชื่อมต่อกับธนาคารใหม่ๆ … ทางเลือกนี้จะทำให้เราส่งมอบงานให้ลูกค้าได้ตามเวลาและมีระบบที่ยืดหยุ่นเพียงพอเพื่อรองรับความต้องการในอนาคต
  • ทางเลือกที่สอง: 21 แต้ม (สำหรับระบบเชื่อมต่อธนาคารที่สมบูรณ์) หลังจากนั้น 0 แต้มเลยสำหรับการเชื่อมต่อธนาคารใหม่ๆ … ทางเลือกนี้คือการยอมรับความเสี่ยงที่จะส่งงานล้าช้าแต่เราจะมีระบบที่สมบูรณ์แบบมากในการรองรับความต้องการในอนาคต
  • ทางเลือกที่สาม: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ไม่มีการทำ Refactoring ใดๆ การเชื่อมต่อกับธนาคารอื่นๆในอนาคตอาจจะเป็น 8, 13, 21 แต้ม จนถึงจุดหนึ่งที่โค๊ดมันไปไม่ได้แล้วก็ต้องมีการทำ Refactoring / Rearchitect ครั้งใหญ่ซึ่งตอนนั้นก็คงประมาณ 100+ แต้ม … ทางเลือกนี้เราจะส่งมอบงานได้ตรงเวลาแต่ต้องใช้เวลามากขึ้นเรื่อยๆกับการเชื่อมต่อธนาคารใหม่ๆ

ทางเลือกที่ดีที่สุดคือทางเลือกที่หนึ่งแต่ทางเลือกที่ได้รับความนิยมที่สุดคือทางเลือกที่สามเพราะสิ่งที่คุณ Manager ต้องการคืองานต้องเสร็จศุกร์นี้มันจึงเป็นทางเลือกเดียวที่เค้ามองเห็น … ช่างน่าเศร้าใจยิ่งนัก

เราจะทำอย่างไรเพื่อหลีกเลี่ยงทางเลือกที่สาม?

  1. ถามคุณ Manager ก่อนเลยว่า “พี่คะ พี่เข้าใจคำว่า ‘Technical Debt’ มั้ย?” ถ้าไม่เข้าใจก็อธิบายถึงผลกระทบให้เค้าฟังไป … สาเหตุหนึ่งที่ทำให้เรามีหนี้สินพะรุงพะรังก็เพราะคนที่มีอำนาจไม่เข้าใจคำว่า Technical Debt ไม่เข้าใจของผลกระทบที่จะตามมาของการตัดสินใจแบบลวกๆของเค้า และชอบคิดว่าอะไรๆก็ง่ายไปหมด
  2. จากข้อหนึ่ง … พยายามอย่าให้คุณ Manager มาคุยเรื่องแบบนี้กับ Junior Developer … น้องเค้ายังเด็ก หัวอ่อน ไม่กล้าเถียงผู้ใหญ่ (ฮ่าๆ) และอาจจะมีความเข้าใจและประสบการณ์ในโค๊ดไม่มากพอจะจัดการบทสนทนาเรื่องนี้ได้ดี เราต้องเป็นกำแพงให้ทีม เราต้องมีจุดยืนที่ชัดเจน
  3. ทุกครั้งก่อนที่เราจะก่อหนี้ เราต้องรู้ว่าเราจะใช้หนี้อย่างไรและเมื่อไร การเป็นหนี้ไม่ใช่เรื่องไม่ดีเสมอไปตราบใดที่เราพิจารณาอย่างรอบคอบและมีวินัยที่ดี มองการมี Technical Debt เหมือนเราเข้าครัวทำกับข้าว ช่วงที่หั่นผักหั่นเนื้อเราก็โอเคที่จะปล่อยให้มันมีขยะรกๆอยู่บนเขียงบ้าง แต่หลังจากผัดข้าวเสร็จเราก็เก็บล้างให้ครัวสะอาดเอี่ยมเหมือนเดิม … ประเด็นสำคัญที่สุดคือเราต้องมีวินัย

Technical Debt vs. Cooking

Technical Debt ก็ไม่ต่างจากการเป็นหนี้ทางการเงิน เริ่มต้นมันอาจจะไม่ใช่ภาระอะไรมากแต่ถ้าเราติดนิสัยก่อหนี้ยืมสินไปเรื่อยๆ ถึงวันนึงมันก็จะมาถึงทางตัน ซอฟท์แวร์ของเราก็จะล้มละลาย … อย่าปล่อยให้เป็นแบบนั้นเลยครับ