ในปัจจุบันคำว่า Technical debt หรือ หนี้ทางเทคนิค เยอะมากขึ้น
และเป็นคำที่มักจะทำให้เกิดความเข้าใจผิดอย่างมาก
และมันก่อให้เกิดอันตรายอย่างมาก ตามมาด้วยเช่นกัน
ดังนั้น มาทำความเข้าใจกันอีกสักรอบนะ
ตัวอย่างเช่น
ถ้ารถยนต์ของคุณเกิดอาการรวนๆ มีเสียงแปลกๆ ขึ้นมา
คุณก็จะนำรถไปเข้าศูนย์ซ่อม
ซึ่งช่างซ่อมอาจจะบอกว่า มี xxx มันเสีย จำเป็นจะต้องเปลี่ยน xxx ใหม่นะ
แต่ต้องรออะไหล่ของ xxx ก่อนนะ เพราะว่า ต้องสั่งมาจากต่างประเทศ
ดังนั้นคุณจะต้องจอดรถทิ้งไว้ที่นี่ สัก 1 อาทิตย์นะครับ
คุณก็อาจจะบอกช่างไปว่า ไม่ได้นะ !!
เพราะว่าสุดสัปดาห์มีแผนจะไปเที่ยวกับครอบครัวนะสิ
แล้วคุณอาจจะถามช่างว่า สามารถทำอะไรบางอย่างได้ไหม
เพื่อให้รถมันทำงานได้ก่อน
และทางช่างอาจจะบอกว่า ได้นะ แค่ทำอะไรไปนิดหน่อย 1 2 3 4 …
แต่คุณต้องขับรถด้วยความระมัดระวัง ห้ามใช้ความเร็วสูงนะ
หลังจากนั้นคุณต้องกลับเข้ามาซ่อมด้วยนะ
เมื่อซ่อมเสร็จคุณก็จ่ายเงินไปนิดหน่อย แล้วก็ขับรถกลับบ้าน
เมื่ออ่านเรื่องราวที่ผ่านมา จะพบว่า มันก็เป็นปกติ ซึ่งก็ต้องเป็นอย่างนี้อยู่แล้วนะ !!!
แต่เรามาลองแยกหน้าที่ของแต่ละคนในเรื่องจากข้างต้นดูกันหน่อยดีไหม ?
คนแรกคือ ช่างซ่อมรถยนต์
เปรียบเสมือน developer/programmer/expert
แน่นอนว่าช่างซ่อมอาจจะเคยเห็นหรือไม่เคยเห็นรถคันนี้มาก่อนเลย
ดังนั้น ช่างซ่อมจะไม่ค่อยสนใจตัวเลือกของคุณมากนักหรอก
แต่ทางช่างซ่อมรถจะไม่ค่อยรู้สึกหรือมีความสัมพันธ์กับรถที่เข้ามาซ่อม
ซึ่งต่างจาก programmer มากๆ ที่ต้องให้ความสนใจกับ code อย่างมาก
คนที่สองคือ คุณซึ่งเป็นเจ้าของรถยนต์
เปรียบเสมือน business หรือ stakeholder ทั้งหลาย
ซึ่งถ้าคุณขาดความรับผิดชอบแล้ว
คุณจะสนใจแต่สิ่งที่กระทบต่อคุณเท่านั้น นั่นก็คือ
- กระทบกับรถของคุณ
- กระทบการเงินของคุณ
- กระทบกับเวลาของคุณ
ซึ่งนั่นคือ ปัญหา !!
เนื่องจาก programmer จะได้รับผลกระทบจากการตัดสินใจของทางฝั่ง business เสมอ
นั่นหมายความว่า ช่างซ่อมจะต้องซ่อมรถในตอนนี้ และ หลังจากนี้ เสมอ
เมื่อเกิดปัญหาขึ้นมา ก็น่าจะถึงการละเล่นอย่างหนึ่ง
คือการโยนขี้ไปมา หรือเปล่านะ !!
เมื่อกลับมามองในการพัฒนา software แล้วจะพบว่า
ความเข้าใจที่ผิดๆ ที่เกิดขึ้น มันส่งผลให้ programmer
เป็นตัวหลักที่ได้รับผลกระทบจากคำว่า Technical debt
แต่ต่อจากนั้นอีกไม่นาน ทาง business ก็จะได้รับผลกระทบจาก Technical debt เช่นเดียวกัน
ตัวอย่างเช่น
- งานพัฒนาช้าลง นั่นคือ time-to-market
- อย่าหวังถึงสิ่งที่เรียกว่า innovation กันเลย
- ที่น่ากลัวก็คือ อัตราของ turnover สูงมากๆ
โดยก่อนจะเกิดปัญหาเหล่านี้ขึ้นมา
ทาง programmer มักจะต้องทำการแก้ไข bug และแก้ไข bug ที่มันคลุมเครือไปเรื่อยๆ
ยังไม่พอนะ ทาง manager หรือ หัวหน้า ก็คอยตาม
และมักจะบอกว่า ให้ทำเร็วๆ หน่อย ทำเร็วกว่านี้ได้ไหม
และมักจะตามมาด้วยการทำ OT ไงล่ะ เพื่อพยายามทำงานนั้นให้มันเสร็จๆ ไป
และแน่นอนว่า programmer ก็ย่อมเกิดอาการล้า ท้อใจ …
ซึ่งนั่นคือสิ่งที่ทาง business ได้ทำลาย real business ของตัวเองแล้ว
นั่นก็คือ ทีมพัฒนา นั่นเอง
และถ้าเมื่อไรทีมพัฒนาหมดแรง และ ยอมแพ้
นั่นหมายถึง business ของคุณต้องหยุด หรือ ช้าลงไปกว่าเดิมอีกหรือเปล่านะ !!
ดังนั้นถ้าทาง programmer และ ทีมพัฒนา
ยังต้องถือครองกับสิ่งที่เรียกว่า Technical debt
แต่เพียงฝ่ายเดียวแล้ว มันจะอันตรายอย่างมาก
ดังนั้นส่วนอื่นๆ ต้องรับผิดชอบ และ ลงมือแก้ไขมันด้วยนะครับ
คุณ Ward Cunningham
เขียนไว้ท้ายบทความเรื่อง Technical Debt ไว้ว่า
A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.
I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.
คำแปล
หลายคนอธิบายคำว่า Technical debt ไว้อย่างมากมาย และ มันทำให้สับสนมาก
ซึ่งเขาคิดว่า
แนวคิดที่ programmer มักทำก็คือ การเขียน code แย่ๆ เพื่อทำให้งานมันเสร็จ
แล้วค่อยกลับมาแก้ไข นั่นเป็นแนวคิดหลักที่ก่อให้เกิด Technical debt
ดังนั้น เขาจึงไม่ยอมเขียน code ที่แย่ๆ ออกมา
แต่ชอบเขียน cpde เพื่อสะท้อนความเข้าใจของเราที่มีต่อปัญหา
ว่าเราเข้าใจมันมากน้อยเพียงใด
คุณล่ะเขียน code แบบไหนกันอยู่ ?
