Technical Debt เป็นหนี้จริงๆ ไหม? คำนวณดอกเบี้ยได้ด้วย

คำถามที่ตอบไม่ได้

Technical Debt คืออะไร? เป็นหนี้จริงๆ ไหม?

เป็นครับ ถ้าไม่ refactor ตอนนี้ อีก 2 ปี cost จะเพิ่ม 3 เท่า

พิสูจน์ได้ไหม? ต้องการตัวเลข ไม่ใช่ความรู้สึก

”…”

คนสาย tech รู้ว่า Technical Debt เป็นปัญหา แต่พออธิบายเป็นตัวเลขกลับทำไม่ได้ บทความนี้จะพิสูจน์ว่า Technical Debt เป็นหนี้จริง และสอนวิธีคำนวณเพื่อ prioritize refactoring อย่างมีหลักการ

Technical Debt คืออะไร?

Ward Cunningham ผู้คิดคำว่า Technical Debt ในปี 1992 อธิบายว่า การเขียน code ที่ไม่ดีเพื่อให้ ship ได้เร็วขึ้น เหมือนกับการกู้เงิน ถ้าไม่จ่ายคืน (refactor) ดอกเบี้ย (maintenance cost) จะพอกพูนจนกลายเป็นภาระหนัก

ประเภทของ Technical Debt

ประเภท	ลักษณะ	ตัวอย่าง
Deliberate (ตั้งใจ)	รู้ว่าไม่ดี แต่ต้องรีบ ship	”เขียน hardcode ไปก่อน แล้วค่อยแก้ทีหลัง”
Accidental (ไม่ตั้งใจ)	ไม่รู้ว่าทำผิด	ใช้ pattern ที่ล้าสมัยโดยไม่รู้ตัว
Bit Rot	Code เก่าที่ไม่ได้ update	Library ที่ไม่ได้ upgrade มา 3 ปี

ทำไมถึงเรียกว่า 'หนี้'?

Ward Cunningham เลือกใช้คำว่า “Debt” เพราะต้องการสื่อสารกับคนที่ไม่ใช่สาย tech ให้เข้าใจว่า การเขียน code ที่ไม่ดีมี “ต้นทุน” ที่ต้องจ่ายในอนาคต เหมือนกับการกู้เงินที่ต้องจ่ายดอกเบี้ย

Technical Debt เป็นหนี้จริงไหม?

ถ้า Technical Debt เป็นหนี้จริง ต้องมีคุณสมบัติเหมือนหนี้ทางการเงิน มาดูกันว่าตรงไหม

คุณสมบัติ	หนี้ทางการเงิน	Technical Debt
Principal (เงินต้น)	เงินที่กู้มา	เวลาที่ประหยัดได้ตอน ship เร็ว
Interest (ดอกเบี้ย)	ค่าธรรมเนียมที่ต้องจ่ายทุกงวด	Maintenance cost ที่เพิ่มขึ้น
Compound (ทบต้น)	ดอกเบี้ยทบดอกเบี้ย	Debt ก่อให้เกิด Debt ใหม่
Default (ผิดนัด)	ถูกยึดทรัพย์	ระบบพังจนต้อง rewrite ใหม่ทั้งหมด

คำนวณ “ดอกเบี้ย” ของ Technical Debt

สมมุติว่ามีระบบ Search API ที่มี Technical Debt สะสมอยู่ ลองคำนวณดูว่า “ดอกเบี้ย” ที่ต้องจ่ายเป็นเท่าไหร่

ข้อมูลเบื้องต้น

รายการ	ปัจจุบัน	หลัง Refactor
เวลาแก้ bug	2 วัน/bug	0.5 วัน/bug
Bug rate	4 bugs/เดือน	4 bugs/เดือน
ค่าแรง Developer	3,000 บาท/วัน	3,000 บาท/วัน

คำนวณ Maintenance Cost

ปัจจุบัน (ไม่ refactor):

• เวลาแก้ bug: 4 bugs × 2 วัน = 8 วัน/เดือน
• Cost: 8 วัน × 3,000 บาท = 24,000 บาท/เดือน

หลัง Refactor:

• เวลาแก้ bug: 4 bugs × 0.5 วัน = 2 วัน/เดือน
• Cost: 2 วัน × 3,000 บาท = 6,000 บาท/เดือน

ดอกเบี้ย Technical Debt:

• ส่วนต่าง: 24,000 - 6,000 = 18,000 บาท/เดือน
• ต่อปี: 18,000 × 12 = 216,000 บาท/ปี

นี่คือ “ดอกเบี้ย” ที่ต้องจ่ายทุกปีถ้าไม่ refactor

Compound Interest: ดอกเบี้ยทบต้น

ปัญหาของ Technical Debt คือมันไม่ได้คงที่ มันพอกพูนเหมือนดอกเบี้ยทบต้น

ทำไม Technical Debt ถึงพอกพูน?

1. Code ซับซ้อนขึ้น ยิ่งมี debt เยอะ ยิ่งเขียน code ใหม่ยาก
2. Bug rate เพิ่มขึ้น Code ที่ซับซ้อนมี bug มากกว่า
3. เวลาแก้ bug นานขึ้น ต้องไล่ code ที่ซับซ้อนนานกว่า
4. Developer ลาออก คนเก่งไม่อยากทำงานกับ codebase ห่วย

ตัวอย่างการพอกพูน

Maintenance Cost ที่เพิ่มขึ้นทุกปี (ถ้าไม่ Refactor)

ปี	Bug Rate	เวลาแก้/bug	เวลารวม/ปี	Cost/ปี
1	4/เดือน	2 วัน	96 วัน	288,000 บาท
2	6/เดือน	3 วัน	216 วัน	648,000 บาท
3	8/เดือน	4 วัน	384 วัน	1,152,000 บาท

NPV: ตัดสินใจว่าควร Refactor ไหม

คำถามที่พบบ่อยคือ “ควร refactor ตอนนี้ หรือรอไปก่อน?” ใช้ NPV (Net Present Value) ช่วยตัดสินใจได้

NPV คืออะไร?

NPV (Net Present Value) คือมูลค่าปัจจุบันของกระแสเงินสดในอนาคต โดยคิดลดด้วย discount rate เพื่อสะท้อนว่าเงินในอนาคตมีค่าน้อยกว่าเงินวันนี้

สูตร: NPV = Σ (Cash Flow / (1 + r)^n)

ถ้า NPV เป็นบวก แปลว่าคุ้มค่าที่จะลงทุน

เปรียบเทียบ 2 ทางเลือก

Option A: Refactor ตอนนี้

• Cost ทันที: 500,000 บาท (2 developers × 2 เดือน)
• Benefit: ประหยัด Maintenance Cost ได้ทุกปี

Option B: ไม่ Refactor

• Cost ทันที: 0 บาท
• Future Cost: Maintenance Cost ที่เพิ่มขึ้นทุกปี

คำนวณ NPV (Discount Rate 10%, 3 ปี)

Option A: Refactor ตอนนี้

ปี	Cash Flow	Present Value
0	-500,000	-500,000
1	+216,000 (ประหยัดได้)	+196,364
2	+216,000	+178,512
3	+216,000	+162,284
NPV		+37,160 บาท

Option B: ไม่ Refactor

ปี	Cash Flow	Present Value
1	-288,000	-261,818
2	-648,000	-535,537
3	-1,152,000	-865,446
NPV		-1,662,801 บาท

เปรียบเทียบ NPV: Refactor vs ไม่ Refactor

Opportunity Cost: สิ่งที่มองไม่เห็น

นอกจาก Maintenance Cost ที่คำนวณได้ ยังมี Opportunity Cost ที่มักถูกมองข้าม

3 Opportunity Cost ที่ซ่อนอยู่

1. Feature Velocity ลดลง

Developer ใช้เวลาแก้ bug แทนที่จะ build feature ใหม่ ถ้าใช้เวลา 8 วัน/เดือนแก้ bug แปลว่าเสียโอกาส build feature ไป 8 วัน

2. Talent Attrition

Developer เก่งๆ ไม่อยากทำงานกับ codebase ที่ห่วย ถ้าคนเก่งลาออก ต้องเสียเวลาและเงินหาคนใหม่

3. Customer Impact

Bug ทำให้ลูกค้าไม่พอใจ อาจนำไปสู่ Churn ซึ่งกระทบ Revenue โดยตรง

Framework สำหรับ Pitch

เมื่อต้องอธิบายให้คนอื่นเข้าใจว่าทำไมต้อง refactor ใช้ template นี้

Template

“Technical Debt ของ [ระบบ] ทำให้เราเสีย [X] บาท/ปี ในรูปแบบ [maintenance cost]

ถ้า refactor ใช้เงิน [Y] บาท จะประหยัดได้ [Z] บาท/ปี

NPV ของการ refactor คือ [NPV] บาท ใน [N] ปี

ROI = [ROI]%“

ตัวอย่าง

“Technical Debt ของ Search API ทำให้เราเสีย 216,000 บาท/ปี ในรูปแบบ bug fixing

ถ้า refactor ใช้เงิน 500,000 บาท จะประหยัดได้ 216,000 บาท/ปี

NPV ของการ refactor คือ +37,160 บาท ใน 3 ปี (discount rate 10%)

ROI = 7.4%”

วิธีคำนวณ ROI

ROI = (NPV / Investment) × 100

= (37,160 / 500,000) × 100

= 7.4%

หมายเหตุ: ROI นี้เป็น conservative estimate เพราะไม่ได้รวม Opportunity Cost และ Compound Effect ในปีที่ 2-3

สรุป

Technical Debt ไม่ใช่แค่ metaphor แต่เป็นหนี้จริงที่คำนวณได้

Key Takeaways

1. Technical Debt มีคุณสมบัติเหมือนหนี้ทางการเงินทุกประการ ทั้ง Principal, Interest, Compound และ Default

2. คำนวณ “ดอกเบี้ย” ได้จาก Maintenance Cost เช่น เวลาแก้ bug × ค่าแรง Developer

3. Technical Debt มี Compound Interest ยิ่งปล่อยนาน ยิ่งแพง ปีที่ 3 อาจจ่ายมากกว่าปีที่ 1 ถึง 4 เท่า

4. ใช้ NPV ตัดสินใจว่าควร refactor ตอนไหน ถ้า NPV เป็นบวก ควรทำเลย

5. อย่าลืม Opportunity Cost Feature Velocity, Talent Attrition, Customer Impact มักใหญ่กว่า Direct Cost