Software Development กับ Loser’s Game
เรื่องนี้อ่านมาจาก Medium เรื่อง Software Development is a loser’s game ของ The Hosk ครับ
ก่อนอื่นต้องพูดถึงคำว่า Loser’s Game ก่อน คำๆ นี้มากจาก บทความของ Charles Ellis ชื่อเดียวกันนี้ โดยเขาได้กล่าวไว้เกี่ยวกับเรื่องความแตกต่างของนักกีฬาเทนนิสที่เป็นมือสมัครเล่นและมืออาชีพ ทั้งคู่มีวิธีการเล่นในคนละเกมส์กัน
โดยนักเทนนิสมืออาชีพจะเล่นในลักษณะของ Winner’s Game ซึ่งผู้เล่นจะชนะด้วยการสร้างแต้มขึ้นมา
ขณะที่มือสมัครเล่น จะได้แต้มจากการทำเสียของผู้เล่นสมัครเล่นอีกฝ่ายหนึ่ง
ดังนั้นในการเอาชนะคู่แข่งของทั้งสองเกมส์นี้จะมีความแตกต่างกันคือ:
- Winner’s Game เอาชนะจากแต้มที่ทำได้มากกว่าคู่แข่ง
- Loser’s Game เอาชนะจากการทำผิดพลาดน้อยกว่าคู่แข่ง
อุปมากลับมาที่งานของ Software Development
ซึ่งจากประสบการณ์พัฒนาซอฟท์แวร์ของผู้เขียน ก็กล่าวว่า ในกลุ่มของนักพัฒนาซอฟท์แวร์ก็ประกอบด้วยนักพัฒนามือสมัครเล่น และมืออาชีพเช่นเดียวกัน
โดยมีสัดส่วนมืออาชีพ 20 % ขณะที่มือสมัครเล่น 80 %
โดยเขาจะแยกความแตกต่างระหว่างมืออาชีพกับมือสมัครเล่นไว้ว่า มือสมัครเล่นจะไม่ชอบสิ่งเหล่านี้:
- Standard
- Unit Testing
- Design Pattern /SOLID Principle
- Leaning & setting Devops and Application Lifecycle Management
- Fixing the build
- Code reviews
- Code Analysis/ Solution Checking
ทำไมถึงเป็นอย่างนั้น
เพราะเขาประเมินสิ่งที่ต้องเขียนต่ำเกินจริง และคิดว่าตัวเองมีความสามารถสูงเกินจริง เขาคิดว่าการเขียนโค้ดเป็นอะไรที่ง่าย เขียนแป็บเดียวก็ใช้ได้แล้ว
ถ้าเราต้องไปอยู่ในกลุ่มของ Dev มือสมัครเล่น วิธีการของเราที่ควรจะทำก็คือ วิธีของ Loser’s Game นั่นเอง กล่าวคือ การโฟกัสในวิธีที่จะทำให้คนเหล่านั้นพลาดให้น้อยที่สุด
และวิธีที่จะเขียนโค้ดได้เร็วที่สุดคือ การโฟกัสไปที่คุณภาพและการลดบั๊ก ไม่ใช่เขียนโค้ดให้เร็วขึ้น
ซึ่งผลของบั๊กหรือปัญหาที่เกินขึ้นโดยเฉพาะกับทีมหรืองานที่ใหญ่ จะทำให้งานช้าลง และสูญเสียโฟกัสในการทำงาน เพราะต้องมาจัดการเรื่องอื่น
และบั๊กที่เจอเยอะๆ จะทำให้ทีมสูญเสียโมเมนตั้ม ทำให้ผู้ใช้เสียความมั่นใจ และมีความเสี่ยงในการ go live
ดังนั้นเป้าหมายในการพัฒนาซอฟท์แวร์ ไม่ใช่การเขียนโค้ดที่ใช้งานได้ แต่เป็นการที่เราต้องใช้เวลาในการหลีกเลี่ยงการได้มาซึ่งโค้ดซึ่งมีคุณภาพต่ำ และบั๊กต่างๆ
นี่คือสิ่งที่ต้องระวังสำหรับนักพัฒนามือสมัครเล่น เพราะเขาจะคิดว่าเขียนเร็วๆ ก็เพียงพอ ซึ่งพอไปถึงระดับนึง ก็จะพบว่า โค้ดมันโตและซับซ้อนมากขึ้นอย่างรวดเร็ว และจะอ่านและแก้ไขได้ยากขึ้นเรื่อยๆ ดังนั้นวิธีนี้จะเหมาะสำหรับการพัฒนาที่ใช้คนไม่เยอะ หรือโปรเจคที่มีขนาดเล็กๆ เท่าน้ัน
สำหรับเรื่องของค่าเสียโอกาสในการเจอบั๊ก เป็นที่ทราบกันว่า ยิ่งเวลาที่เราเจอบั๊กในโค้ดนั้นๆ อยู่ห่างจากเวลาที่เราเขียนโค้ดนั้นมากๆ มันจะใช้เวลาในการแก้ไขมากขึ้นด้วยเช่นเดียวกัน เช่น บั๊กที่เจอในช่วง Production เราอาจจะไม่สามารถดูปัญหาได้โดยตรง ต้องใช้ระบบพิเศษ กว่าจะเจอ แก้ไขโค้ด ก็ต้องรอรอบ ให้ผ่านเทสต่างๆ ซึ่งใช้เวลากว่าจะถึง Production Stage อีกครั้ง ซึ่งในช่วงที่มีปัญหา อาจจะทำให้เกิดการเสียโอกาสต่างๆ ได้
ขณะเดียวกัน ถ้าเราสามารถเจอได้ใน Unit test ซึ่งเป็น Test ที่อยู่ใกล้ Developer มากที่สุด เราจะสามารถแก้ไขมันได้รวดเร็วกว่ามาก
ดังนั้นเราต้องประเมินทีมของเราว่า ทีมของเรานั้นประกอบไปด้วยนักพัฒนาแบบใดบ้าง
ถ้าเราพบว่าในทีมส่วนใหญ่เป็นมือสมัครเล่น สิ่งที่ควรทำคือ เน้นกระบวนการที่จะไม่ให้เกิดบั๊กมากกว่า การเชื่อว่าทุกคนเป็นคนที่เขียนโค้ดได้ดีแล้วปล่อยเขาไปจัดการงานของตัวเองให้เรียบร้อย
ความสำเร็จของการพัฒนาซอฟท์แวร์ไม่ใช่การเขียนโค้ดที่ทำงานถูกเลยในครั้งแรก แต่เป็นความพยายามที่จะหลีกเลี่ยงความผิดพลาดต่างๆ ที่จะเข้ามามากมายในระหว่างการเดินทางไปสู่ผลงานที่ต้องส่งมอบ
ใครสนใจต้นเรื่องลองอ่านได้ที่นี่ครับ