“Technical Debt” ถ้าแปลตรงตัวก็คือ “หนี้ทางเทคนิค” โดยถูกใช้ครั้งแรกจากลุง Ward Cunningham ในขณะที่ลุงทำ Software ทางด้านการเงิน ชื่อ WyCash แล้วลุงต้องการสื่อสารให้เจ้านายที่รู้เรื่องทางด้านการเงินเข้าใจว่า ถ้าไม่แก้ปัญหาทางด้านเทคนิคหรือไม่ทำมันให้ดี แล้วปล่อยมันทิ้งไว้ ก็อุปมาเหมือนเป็นหนี้สะสมไปเรื่อยๆ แถมยังต้องชดใช้ดอกเบี้ยในอนาคตด้วยอีกนะ!

ลุง Ward Cunningham ผู้ใช้คำว่า “Technical Debt” คนแรก
แกเป็น 1 ใน 17 ที่แถลงการ Agile Manifesto, เป็นหนึ่งในผู้คิด Design Pattern และ Extreme Programming

ดังนั้นถ้าถามว่า “หนี้ทางเทคนิค” (Technical Debt) คืออะไร คือเป็นคำอุปมาที่เทียบกับ “หนี้ทางการเงิน” (Monetary Debt) นั่นเอง

ลองเทียบตัวอย่างง่ายๆ ถ้า ด้านซ้ายคือเรื่องทางเทคนิค และ ด้านขวาเรื่องการเงิน

• การไม่ออกแบบหรือละเลยคุณภาพของงาน = การกู้เงิน
• การ Refactoring Code = การคืนเงินต้น
• การพัฒนางานได้ช้าลง ด้วยความซับซ้อนที่มากขึ้น = การจ่ายดอกเบี้ยที่จะมีมากขึ้นเรื่อยๆ

ดูแล้ว “Technical Debt” จะเป็นสิ่งที่ไม่ดีต่างๆ ในด้านเทคนิค ทั้งนี้เกิดได้จากหลายปัจจัย เช่น การออกแบบระบบที่ไม่ดี การเขียนโค้ดที่ไม่ดี เป็นต้น

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

“Debt” เกิดได้ทุกที่ ไม่เฉพาะ “Technical” เท่านั้น

เมื่อเริ่มทำโปรเจ็ค สิ่งที่เรียกว่า “Debt” หรือ “หนี้” ก็จะเริ่มเกิดขึ้นทันที เหมือนที่ลุง Ward Cunningham ได้บอกไว้เมื่อปี 1992 ว่า

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

การส่งมอบโค้ดออกไปครั้งแรกก็เปรียบเหมือนการเริ่มสร้างหนี้แล้ว ..

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

• Architecture Debt (หนี้ทางสถาปัตยกรรม) – การใช้สถาปัตยกรรมที่ไม่มีคุณภาพ หรือไม่เหมาะสมกับตัวงาน
• Design Debt (หนี้ทางการออกแบบ) – การละเลยที่จะทำตามหลักการ การออกแบบซอร์ฟแวร์ต่างๆ
• Code Debt (หนี้ทางโค้ด) – โค้ดที่เขียนไม่ดี ซับซ้อน อ่านยากง
• Test Automation Debt (หนี้ทางการทดสอบอัตโนมัติ) – ไม่ทำ Automate Test เพื่อรองรับการส่งมอบงานให้ไว
• Maintenance Debt (หนี้ทางด้านบำรุงรักษา) – มีการปรับปรุงซอร์ฟแวร์ล่าช้า
• Defect Debt (หนี้ทาง Defect) – รู้ว่ามีข้อบกพร่องของซอร์ฟแวร์ตรงไหน แต่ไม่แก้ไข
• Documentation Debt (หนี้ทางเอกสาร) – ลืมทำเอกสาร ทำแล้วไม่พอใช้ ทำไม่เสร็จ
• People Debt (หนี้ทางบุคคล) – คนที่มาชะลอหรือขัดขวางการพัฒนาของงาน

Reference: Southern Methodist University

จะรู้ได้อย่างไรว่าเรากำลังเป็น “หนี้ทางเทคนิค” (Technical Debt)

ถ้าอยากลองสังเกตว่าทีมหรือในบริษัทของเรา มีอาการเป็นหนี้ทางเทคนิคหรือไม่ ลองดูได้ เช่น

• Productivity ลดลง, ขาดแรงจูงใจ
• ใช้เวลาทดสอบระบบเยอะขึ้นเรื่อยๆ (เพราะเป็น manual test นี่นะ)
• ส่งมอบงานได้ช้า
• มีโค้ดซ้ำกันหลายๆ จุด
• ไม่รู้ว่าซอร์ฟแวร์ทำงานอย่างไร
• มี Code Coverage ต่ำ
• มีบั๊กเพิ่มขึ้นเรื่อยๆ
• คนทำงานจะเครียดและกดดัน เมื่อใกล้ถึงเวลาส่งมอบงาน
• คนกลัวที่จะแก้ไขโค้ด
• ทำการ Hack ระบบตัวเอง เพราะออกแบบผิดพลาด และไม่อยากแก้ไข
• เลือกใช้เทคโนโลยีไม่เหมาะสมกับงาน
• โค้ดอ่านไม่รู้เรื่อง
• ความเร็วในการทำงานของคนหรือทีมลดลง
• ใช้ Library หรือเทคโนโลยีเก่า

หากเจอตามข้อต่างๆเหล่านี้ ต้องลองหาทางปรับปรุงดูครับ เพื่อไม่ให้เกิดหนี้สะสม และดอกเบี้ยในอนาคต

สาเหตุของการทำให้เกิด “หนี้ทางเทคนิค” (Technical Debt)

หนี้ต่างๆ เกิดขึ้นได้จากหลายสาเหตุ ตั้งแต่เริ่มโปรเจ็ค ขณะทำ หรือแม้แต่โปรเจ็คจบแล้ว และต้องดูแลต่อ เช่น

• การขาดกระบวนการทำงาน ต่างคนต่างทำ
• ไม่วางแผนการทำงานก่อน
• แรงกดดันทางธุรกิจ
• ไม่เข้าใจและขาดเครื่องมือสำหรับ Test
• ไม่ทำ Refactoring Code หรือทิ้งแย่ๆไว้นานๆ
• ไม่ทำตามมาตรฐาน
• ขาดเอกสารที่เหมาะสม เช่น คู่มือใช้งาน, สเป็กระบบ ฯลฯ
• ขาดความร่วมมือการทำงาน
• ทีมไม่มีความเข้าใจในสิ่งที่จะทำ
• ทีมขาดความรู้ในเทคโนโลยีที่จะใช้
• ทีมไม่มีความรู้สึกเป็นเจ้าข้าวเจ้าของ

ผลกระทบ เมื่อเกิด “หนี้ทางเทคนิค” (Technical Debt)

หรือจะเรียกว่ามันเป็น “ดอกเบี้ย” (Interest) ก็ได้ เพราะแม้ว่าจะชดใช้เงินต้นคืนไปบ้างแล้ว เช่น Refactoring Code ทำตาม Standard หรืออื่นๆ แต่ยังคงมีผลกระทบทางอ้อมอยู่ ไม่ว่าจะเป็นเรื่องของ คน, เงิน, เวลา, ความเสี่ยงต่อธุรกิจ, ความเสี่ยงต่อความปลอดภัยของระบบ, ขวัญกำลังใจของคนตกลงเรื่อยๆ, ลูกค้าไม่พอใจ เป็นต้น

Reference: Southern Methodist University

แล้วจะลด “หนี้ทางเทคนิค” (Technical Debt) ได้อย่างไร

วิธีการลดหนี้ หรือป้องกันหนี้ทางเทคนิค สามารถทำได้หลายวิธี

อย่าก่อหนี้

• ไปหาความรู้และนำ engineering practice ต่างๆ มาใช้ เช่น
  • Clean Code
  • Pair programming
  • นำ Test-Drivent Development (TDD) มาใช้
  • ทำ Unit Testing และ Code Coverage
  • Refactoring Code สม่ำเสมอ
• การจัดการกระบวนการทำงาน เช่น
  • มี Review Code
  • วางแผนก่อนทำงานร่วมกัน
  • ออกแบบสถาปัตยกรรมก่อนทำงาน
  • เลือกใช้ Technology ให้เหมาะสม

แล้วถ้าเป็นหนี้ จะทำอย่างไร?

• หาจุดที่แย่ (หนี้) ให้เจอซะก่อน เช่น ใช้ซอร์ฟแวร์ SonarQube ตรวจสอบคุณภาพโค้ด
• หาความรู้และนำ Engineering Practice ต่างๆ มาใช้
• ให้เวลากับมัน ค่อยๆ ปรับปรุงโค้ดแย่ๆ (ลดหนี้) ไปเรื่อยๆ
• ถ้าเจอโค้ดแย่ๆ ให้ปรับปรุงทันที
• จัดลำดับการปรับปรุงโค้ด ว่าอะไรสำคัญ ต้องทำก่อน-หลัง
• ทำ Automate Testing

สรุป

หลังจากรู้จัก Technical Debt กันแล้ว รู้ว่ามันเป็นผลเสียมากกว่าผลดี ดังนั้น ทางเลือกก็มีแค่ 2 ทาง คือ จะยอมใช้เวลาเพื่อทำของให้มันดี หรือ จะรีบร้อนแล้วได้ของไม่ดีกลับไป ข้อนี้เป็นหน้าที่ของทีม ที่จะต้องทำและป้องกันอย่าให้เกิด และจะต้องไปขายไอเดียให้กับผู้หลักผู้ใหญ่ต่อไป ว่าทำไม เราไม่ควรเป็นหนี้…

Reference

• Ward Cunningham – https://en.wikipedia.org/wiki/Ward_Cunningham
• http://wiki.c2.com/?ComplexityAsDebt
• https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
• https://en.wikipedia.org/wiki/Technical_debt
• http://slideplayer.com/slide/9275126/
• https://www.slideshare.net/slideshare4tushar/technical-debt-info-graphic
• http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-the-danger
• http://www.somkiat.cc/technical-debt/
• header image – https://www.illinoispolicy.org/chicagos-63-billion-debt-burden/