Technical Debt หรือ หนี้เชิงเทคนิคนั้นมีที่มาหลายอย่างทั้ง
- การปล่อยระบบออกสู่ตลาดเร็วเกินไป ส่งผลให้คุณภาพลดลง
- ค่าใช้จ่ายที่มีอยู่อย่างจำกัด
- เรื่องของการออกแบบและตัดสินใจ ซึ่งล้วนมี tradeoff เสมอ
- เราไม่ได้อะไรมาแบบฟรี ๆ ต้องมีสิ่งแลกเปลี่ยนเสมอ
ส่งผลให้ยากต่อการดูแลรักษาต่อไป
จากบทความเรื่อง Technical Debt and Tradeoffs in Engineering
แบ่งชนิดของ Technical Debt ออกเป็นดังนี้
- Knowledge Debt
- Technology Debt
- Code Debt
- Architecture Debt
- Testing Debt
ได้อธิบายอย่างน่าสนใจว่า
Software development process นั้นเป็นกระบวนการที่ไม่มีที่สิ้นสุด
จะวนทำซ้ำไปเรื่อย ๆ
ดังนั้นเรื่องของการรับฟัง feedback ทั้งจากผู้ใช้งาน ทั้งจากคนสร้าง
เพื่อนำมาปรับปรุงจึงเป็นสิ่งที่สำคัญมาก ๆ
ยกตัวอย่างเช่น
สิ่งที่เราสร้างขึ้นมา
มันทำให้เราช้าลงหรือเร็วขึ้น
สิ่งที่เราคิดว่า จะเข้ามาแก้ไขปัญหา มันกลับสร้างปัญหาหรือไม่
ความรู้ที่เรามี มันเพียงพอต่อสิ่งที่เราทำหรือไม่
การทดสอบหรือ validate ระบบงานมันช้า หรือ ทำซ้ำไม่ได้หรือไม่
หรือเรื่อง technology ที่เราเลือกใช้งาน มันทำให้เราช้าหรือไม่
ดังนั้น เราต้องยอมรับก่อนว่า เรามีปัญหา
จากนั้นมาดูว่าปัญหาคืออะไร และ จะปรับแก้อย่างไร
ลงมือแก้ไข วัดผล และวนซ้ำไป
เป็นเรื่องปกติของการพัฒนา software ที่จะต้องมี technical debt
แต่เราได้กลับมาดูแลหรือจ่ายหนี้เหล่านั้นคืนอยู่อย่างเป็นประจำหรือไม่
หรือทำการสร้างหนี้ไปเรื่อยจนถึงวันหนึ่งมันกลับมาทำร้ายเราเอง
โดยที่ไม่มีแม้โอกาสจะแก้ตัว
เพราะว่าปัญหามันใหญ่โตเกินที่จะควบคุมไปแล้ว