Xconf SG 2019: Economics of Software Quality — Martin Fowler
Spoiler Alert: ใครมีบัตร Xconf Bangkok แล้วข้ามไปก่อนเลย เนื้อหานี้มาจาก Xconf Sigapore
Keynote ของงานนี้เป็นใครไปไม่ได้ Martin Fowler ศาสดาแห่งการ Refactoring (รู้จักเค้าให้มากขึ้น) ที่มาพูดถึง Software Development in the 21st Century ซึ่งมักเป็นหัวข้อที่เค้าใช้มาแต่งแต่ปี 2013
แทนที่ Martin จะพูดหัวข้อเดียวที่น่าเบื่อๆ เค้าแบ่งย่อยเป็น 2 หัวข้อที่น่าเบื่อ (น้อยลง) โดยหัวข้อที่หยิบยกมา 1 จาก 2 หัวข้อ คือ Economics of Software Quality ซึ่ง Martin เคยเกริ่นถึงเรื่องนี้จาก Refactoring: Second Edition — A Conversation with Martin Fowler ในความใจที่ว่าเราไม่ควรที่จะ Refactoring เพื่อประโยชน์ในเชิง Technical เพียงอย่างเดียว ควรมองในเชิงมุมมองของ Business ด้วย
You are not alone: Martin ถามผู้ฟังในห้อง ว่าใครเจอเจอเหตุการณ์ที่ว่า “เราต้องลดความพยายามในการพัฒนาคุณภาพลง เพื่อที่จะพัฒนาฟีเจอร์ใหม่ได้มากขึ้น” แน่นอนว่า หลายๆคนก็เจอเหตุการณ์แบบนี้มาแล้วแทบทั้งสิ้น จากประสบการณ์ที่เคยเจอมาทั้งแบบเผางานไปก่อน แต่ต้องกลับมาแก้เล็กๆ น้อยๆ หรือแทบจะต้องรื้อใหม่ และแบบที่งานคุณภาพดีมาก แต่กลับไม่มีคนใช้
การที่คุณใส่ใจกับคุณภาพของซอฟแวร์ และมีการออกแบบที่ดี เพื่อรองรับการต่อยอดนั้น จะช่วยให้การส่งมอบซอฟแวร์ได้รวดเร็ว และมีคุณค่ามากขึ้น ซึ่งจะส่งผลดีต่อ Business เช่นเดียวกัน (ส่งมอบคุณค่าให้ลูกค้าได้รวดเร็วยิ่งขึ้น,ไวกว่าคู่แข่ง, ได้ feedback เร็วกว่า) ไม่ใช่แค่ Technical เพียงอย่างเดียว แต่อย่างไรก็ตามสิ่งเหล่านี้ไม่ใช่สิ่งที่ได้มาฟรีๆ มันต้องลงทุนและใช้เวลา กว่าจะถึงจุดที่คุ้มทุน โดยที่จุดที่คุ้มทุน หรือจุด Payoff นี้ ก็มันยากที่จะวัดและบ่งบอกให้แม่นยำ จากประสบการณ์ที่ผมเคยเจอมานั้น ให้ลองพิจารณาคุณค่าที่ผู้ใช้จะได้รับ หากปรับปรุงคุณภาพแล้วส่งผลต่อผู้ใช้ก็ควรจะปรับ แต่ถ้าหากไม่ส่งผลต่อผู้ใช้ บางครั้งเราก็จำเป็นที่จะต้องยอมให้ Technical Debt เกิดขึ้น เพื่อประโยชน์เชิง Business เช่น นำเวลาไปพัฒนาฟีเจอร์อื่นเพื่อเพิ่มคุณค่าให้แก่ผู้ใช้แทน
โดยที่ Martin ได้แบ่งการเกิด Technical Debt ออกเป็น 4 quadrant คือ
- ไม่ใส่ใจ และตั้งใจให้เกิด — เนื่องจากไม่มีเวลาเพียงพอ
- ใส่ใจ และตั้งใจ — อยากได้ของที่เร็ว แล้วค่อยจ่ายหนี้ที่หลัง
- ไม่ใส่ใจ และไม่ตั้งใจ — ไม่รู้ว่ามันเป็น Technical Debt
- ใส่ใจ และไม่ตั้งใจ — รู้แล้วว่ามี Technical Debt และรู้ถึงหนทางแก้ไข
Technical Debt ที่เป็นประโยชน์จะเกิดขึ้นก็ต่อเมื่อเรารับรู้ และใส่ใจกับคุณภาพของซอฟแวร์มากเพียงพอ และเข้าใจคุณค่าทาง Business อย่างชัดเจน
ครั้งต่อไปหากคุณจะ Refactoring หรือ ปรับเปลี่ยน Design ลองมองมุมเชิง Business ดูหน่อยไหม สิ่งที่คุณกำลังจะทำ มันส่งผลต่อ Business มากน้อยแค่ไหน
More:
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
https://martinfowler.com/bliki/TechnicalDebt.html
https://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html
https://martinfowler.com/bliki/TradableQualityHypothesis.html
