- ด้วย อายุงานที่สั้นและการปรับโครงสร้างองค์กรบ่อยครั้ง ในบริษัทเทคโนโลยีขนาดใหญ่ ทำให้วิศวกรจำนวนมากต้องทำงานบนโค้ดเบสที่ตนไม่คุ้นเคย
- ความจริงคือการเปลี่ยนแปลงโค้ดส่วนใหญ่ถูกทำโดย วิศวกรระดับ ‘มือใหม่’ ที่เข้าทำงานไม่ถึง 6 เดือน
- มีวิศวกร ‘old hand’ ที่มีประสบการณ์บางส่วนช่วยประคองคุณภาพไว้ แต่พวกเขาก็มีข้อจำกัดจากภาระงานล้นมือและความรับผิดชอบที่ไม่เป็นทางการ
- บริษัทให้ความสำคัญกับ ความคล่องตัวในการโยกย้ายคนและการมองเห็นภาพรวมภายในองค์กร (legibility) มากกว่าความเชี่ยวชาญ และนั่นคือราคาที่ต้องจ่ายจากการลดคุณภาพโดยเจตนา
- สุดท้ายแล้ว โดยไม่เกี่ยวกับความสามารถเฉพาะตัวของวิศวกร ปัญหาเชิงโครงสร้างที่ต้องทำงานบนระบบที่ไม่คุ้นเคยโดยยึดส่งงานเร็วเป็นหลัก คือสาเหตุรากของโค้ดแย่
โครงสร้างที่ทำให้เกิดโค้ดแย่ในบริษัทใหญ่
- บริษัทเทคโนโลยีขนาดใหญ่จ้างวิศวกรเก่ง ๆ ด้วยเงินเดือนสูง แต่ อายุงานมักอยู่เพียง 1–2 ปี
- ค่าตอบแทนในรูปหุ้น (share grant) จะ vest ครบหลัง 4 ปี ทำให้หลังจากนั้นรายได้อาจลดลงครึ่งหนึ่ง
- แม้บางแห่งจะมี refresh รายปี แต่ก็ไม่ได้การันตี จึงทำให้วิศวกรเลือกย้ายงาน
- หากนับรวมการย้ายภายในด้วย ก็ แทบไม่ค่อยมีใครอยู่กับโค้ดเบสเดียวเกิน 3 ปี
- การปรับโครงสร้างองค์กร (re-org) เกิดขึ้นทุกปี หรือบ่อยกว่านั้น
- ขณะที่โค้ดเบสมักถูกใช้งานต่อเนื่องเกิน 10 ปี ทำให้ วิศวกรส่วนใหญ่ยังอยู่ในช่วง ‘กำลังเรียนรู้’ ระบบใหม่
- ผลก็คือการเปลี่ยนแปลงโค้ดจำนวนมากถูกทำโดย คนที่เพิ่งเข้ามาไม่ถึง 6 เดือน
บทบาทและข้อจำกัดของ ‘old hand’
- วิศวกรบางคนอยู่กับระบบเดิมนานพอจนมี ความเชี่ยวชาญเชิงลึก
- คนกลุ่มนี้สามารถตรวจพบปัญหาได้ตั้งแต่ต้นผ่านการรีวิวโค้ด
- แต่โครงสร้างแบบนี้ เป็นเรื่องไม่เป็นทางการและไม่ได้ถูกทำให้เป็นระบบ
- บริษัทไม่ได้สนใจรักษาความเชี่ยวชาญระยะยาวมากนัก และมักย้ายคนที่ชำนาญไปทีมอื่น
- คนที่มีประสบการณ์สูงจึง เผชิญภาระงานหนักอยู่เสมอ
- ไม่มีเวลาพอตรวจทุกการเปลี่ยนแปลงด้วยตัวเอง
- หากผลงานของงานตัวเองลดลง ก็อาจเสี่ยงถูกมองในแง่ลบเสียด้วยซ้ำ
ความเป็นจริงของวิศวกรที่ทำงานได้ดีโดยเฉลี่ย
- วิศวกรที่ทำงานได้ดีโดยเฉลี่ยในบริษัทใหญ่ มักมีลักษณะดังนี้
- มีความสามารถพอจะผ่านเกณฑ์การจ้างงาน แต่ ยังไม่คุ้นกับโค้ดเบสหรือภาษาใหม่
- ต้องทำงานให้ทัน เส้นตายที่ทับซ้อนกันของหลายโปรเจกต์ ไปพร้อมกัน
- ผลลัพธ์คือเกิดโครงสร้างที่ทุกคนต้องทำดีที่สุดภายใต้ สภาพแวดล้อมที่ให้ความสำคัญกับกำหนดการมากกว่าคุณภาพ
- ตัวอย่าง: วิศวกรมือใหม่แก้บั๊กในโค้ดที่ไม่คุ้นแบบเฉพาะหน้า แล้ววิศวกรที่ชำนาญตรวจแบบคร่าว ๆ ก่อนปล่อยใช้งาน
- จากนั้นหลายปีต่อมา เมื่อมีคนกลับมาเจอโค้ดนี้อีก ก็จะเกิดคำถามว่า “ทำไมถึงเขียนโค้ดแบบนี้”
ทำไมบริษัทจึงคงโครงสร้างแบบนี้ไว้
- บริษัทใหญ่ให้ความสำคัญกับ การมองเห็นภาพรวมภายในองค์กร (legibility) มากกว่าผลิตภาพ
- พวกเขาต้องการโครงสร้างที่รู้ได้ว่าใครกำลังทำอะไร และสามารถโยกย้ายคนได้ทุกเมื่อ
- นี่คือ การเลือกโดยเจตนาที่แลกความเชี่ยวชาญและคุณภาพโค้ดทิ้งไป
- ยอมรับการสูญเสียความชำนาญ เพื่อแลกกับความยืดหยุ่นในการย้ายคนอย่างรวดเร็วเมื่อเกิดปัญหา
- โดยเฉพาะในช่วงที่ การ pivot ไปสู่ด้านใหม่อย่าง AI กลายเป็นเรื่องสำคัญ กลยุทธ์นี้ยิ่งเป็นประโยชน์ต่อบริษัท
- แต่ในสภาพแวดล้อมแบบนี้ ก็หลีกเลี่ยงไม่ได้ที่จะมี วิศวกรจำนวนมากต้องรีบทำงานบนระบบที่ตนไม่คุ้นเคย
ข้อจำกัดของวิศวกรรายบุคคลและวิศวกรรมแบบ ‘pure/impure’
- วิศวกรแต่ละคนไม่มีอำนาจพอจะเปลี่ยนโครงสร้างนี้ได้
- ณ ปี 2025 ศูนย์กลางอำนาจได้ย้ายจากวิศวกรไปอยู่ที่ผู้บริหารแล้ว
- สิ่งที่แต่ละคนทำได้ดีที่สุดคือกลายเป็น ‘old hand’ ในบางพื้นที่เพื่อรักษาคุณภาพขั้นต่ำเอาไว้
- แต่การเข้าไปแบกรับมากเกินไป ก็อาจเสี่ยงถูกประเมินว่า ผลงานไม่ถึงเกณฑ์ (PIP)
- บทความนี้เสนอความต่างระหว่าง วิศวกรรมแบบ ‘pure’ และ ‘impure’
- วิศวกรรมแบบ pure: เน้นโปรเจกต์เทคนิคที่เป็นอิสระ (เช่น การพัฒนาภาษาโปรแกรม)
- วิศวกรรมแบบ impure: สภาพแวดล้อมจริงที่ต้องทำงานบนระบบที่ไม่คุ้นเคยโดยยึดตามกำหนดการ
- วิศวกรในบริษัทใหญ่ส่วนมากอยู่ในโลกของ วิศวกรรมแบบ impure และในบริบทนี้ โค้ดแย่เป็นผลพลอยได้ที่หลีกเลี่ยงไม่ได้
- หากระบบยังทำงานได้ดีพอ โปรเจกต์ก็จะถูกนับว่าประสบความสำเร็จ
บทสรุป: ‘โค้ดเบสที่ไม่คุ้นเคย’ ในฐานะสาเหตุเชิงโครงสร้าง
- บริษัทใหญ่มีอำนาจโยกย้ายวิศวกรได้อย่างอิสระ และนี่คือ การตัดสินใจขององค์กรที่ยอมแลกกับการสูญเสียความเชี่ยวชาญ
- ความรับผิดชอบต่อโค้ดแย่ไม่ได้อยู่ที่ปัจเจกบุคคล แต่เป็น โครงสร้างองค์กรและวิธีบริหารคน
- ต่อให้เพิ่มความสามารถของวิศวกรทุกคนเป็นสองเท่า ความผิดพลาดจากการทำงานบนโค้ดเบสที่ไม่คุ้นเคยก็ยังคงเกิดขึ้น
- สาเหตุรากแท้จริงคือ “โครงสร้างที่ทำให้วิศวกรส่วนใหญ่ ต้องทำงานส่วนใหญ่บนโค้ดที่ตนไม่คุ้นเคย”
- การชี้ให้เห็นตัวอย่างโค้ดแย่อาจช่วยให้ปรับปรุงได้ แต่ สิ่งที่ควรถูกวิจารณ์ไม่ใช่วิศวกร หากเป็นระบบ
5 ความคิดเห็น
จากประสบการณ์ของผม ถ้าพื้นฐาน CS โดยเฉพาะ PLT แน่น สุดท้ายไม่ว่าอยู่ในสภาพแวดล้อมแบบไหนก็จะเขียนโค้ดที่ดีกว่าได้ค่อนข้างสม่ำเสมอ
ต่อให้ไม่ได้มีความรู้ลึกมาก แค่เข้าใจหลักการพื้นฐานที่สุด หากมีเวลาเพียงพอและเป็นโค้ดที่คุ้นเคย คุณภาพโค้ดก็จะออกมาดีในแบบของมันเอง ถ้ารีแฟกเตอร์สัก n รอบ ต่อให้ AI เขียนก็ยังพอดูดีขึ้นมาได้
แต่ก็มีคนไม่น้อยที่ต่อให้จับซอร์สเดิมอยู่นานแค่ไหน อ้างว่าประสบการณ์ 20 ปี แต่ทำได้แค่ปั่นสปาเกตตีโค้ด และไม่รู้ด้วยซ้ำว่าทำไมถึงไม่ควรทำแบบนั้น
ตราบใดที่เราไม่สามารถมีทั้งสภาพแวดล้อมที่สมบูรณ์แบบ เวลาไม่จำกัด และงบประมาณไม่สิ้นสุดได้ ผมรู้สึกว่าเนื้อหาแบบนี้ค่อนข้างกลวงและไม่ได้มีความหมายมากนัก ไม่ว่ายุคไหนหรือสายงานไหน มันก็เป็นแบบเดียวกันไม่ใช่หรือ?
การเขียนโค้ดที่ดีกว่าได้ภายใต้ระบบเดียวกันนั้น ชัดเจนว่าเป็นความสามารถของวิศวกรจริง ๆ
ก็คงดีถ้าระบบถูกออกแบบมาให้มีเผื่อและยืดหยุ่น เพื่อที่จะส่งมอบคุณภาพที่ดีได้ และเมื่อเทียบกับยุคที่วิศวกรรมองค์กรและวิธีการพัฒนายังไม่ก้าวหน้าเท่าตอนนี้ โดยเฉลี่ยแล้วก็น่าจะเป็นแบบนั้นจริง
แต่ในสายตาผม มันฟังดูเหมือนคนที่มีอัตตาในฐานะวิศวกรพองโต แต่ขาดความรับผิดชอบในฐานะสมาชิกคนหนึ่งขององค์กร กำลังแก้ตัวว่านี่ไม่ใช่ความผิดของตัวเอง แต่เป็นความผิดของผู้บริหารทั้งหมด
วิศวกรสถาปัตย์ นักออกแบบอุตสาหกรรม และแอนิเมเตอร์ ไม่มีเดดไลน์ และถูกประเมินจากแค่ความคิดสร้างสรรค์กับคุณภาพ ไม่ใช่ผลิตภาพ ส่วนมีแค่โปรแกรมเมอร์เท่านั้นหรือที่มีเดดไลน์?
มีแต่เรื่องไร้สาระทั้งนั้น..เรื่องโค้ดแย่หรือโค้ดดีนี่ พวกจูเนียร์ชอบพูดกัน แต่สิ่งที่สำคัญกว่าคือ มีหรือไม่มีซีเนียร์ที่ออกแบบซอฟต์แวร์ให้เหมาะกับอุตสาหกรรมนั้นได้ดี..
บทความที่โพสต์กันที่นี่ โดยมากอาจอยู่ในสภาพแวดล้อมที่ค่อนข้างต่างจากมุมมองหรือประสบการณ์บางส่วนของตลาด SI ในประเทศที่ถึงขั้นมักเพิกเฉยต่อ OCP เสียด้วยซ้ำ
อย่างไรก็ตาม Linus Torvalds ก็ไม่ใช่มือใหม่อยู่ดี...
ความเห็นจาก Hacker News
ฉันอ่านบทความของคนนี้มาหลายรอบแล้ว และทุกครั้งก็จะเหลือ ความรู้สึกขัดใจ บางอย่างอยู่เสมอ
ตอนนี้คิดว่าน่าจะรู้แล้วว่าทำไม ตัวบทวิเคราะห์นั้นมีเหตุผลในตัวเองก็จริง แต่เหมือนมี ลัทธิสิ้นหวัง บางอย่างรองรับอยู่ข้างใต้
เขาน่าจะเป็นคนที่เคยเป็นนักอุดมคติ แต่ผ่านประสบการณ์แย่ ๆ จนพยายามอธิบายว่า ‘การเชื่อในอะไรสักอย่างนั้นเปล่าประโยชน์’
เลยทำให้เกิดคำถามขึ้นมาว่า — ทำไมบริษัทใหญ่ต้องทำแบบนี้ ทำไมโค้ดแย่ ๆ ถึงทรมานวิศวกร ความรู้สึกนั้นผิดจริงหรือ หรือเป็นเพราะโครงสร้างเศรษฐกิจที่เราอยู่กันแน่ หรือว่าการยอมจำนนต่อแรงขนาดมหาศาลคือความเป็นผู้ใหญ่กันแน่
ก็เพราะฉันต้อง รับผิดชอบต่อผลลัพธ์ ของมัน
กำหนดการเลื่อนเพราะต้องมาแก้โค้ดเละเทะที่คนอื่นเขียนไว้ แล้วสุดท้ายผลประเมินปลายปีก็แย่ลงเพราะเรื่องนั้น
ฉันถูกถามว่า “ทำไมถึงใช้เวลานานขนาดนี้” แต่ก็เพราะต้องคุ้ยกองขยะเพื่อหาต้นตอของปัญหา
พยายามอธิบายเรื่องแบบนี้ให้ฝ่ายบริหารเข้าใจมาหลายปีแล้ว แต่สุดท้ายมันก็เหมือน งานของซิซีฟัส
เหมือนสถาปนิกที่อึดอัดเมื่อเห็นอาคารที่ทำอย่างลวก ๆ หรือผู้กำกับภาพยนตร์ที่ทุกข์ใจกับหนังที่หละหลวม วิศวกรที่ดีจะมุ่งหาความสมบูรณ์ของงาน
ผมคิดว่าความเป็นผู้ใหญ่ไม่ใช่การยอมจำนนต่อความไร้อำนาจ แต่คือการสู้เท่าที่จะสู้ได้
ที่น่าสนใจก็คือ แม้จะเรียกผู้เขียนว่าพวกสิ้นหวัง แต่ความคิดที่ว่า ‘โลกนี้ควบคุมอะไรไม่ได้’ นั้นตัวมันเองก็เป็นแนวคิดแบบสิ้นหวังอยู่แล้ว
เมื่อก่อนฉันก็คิดว่าโค้ดที่ไม่สมบูรณ์แบบคือโค้ดแย่ แต่หลังผ่านมาหลายบริษัท มุมมองก็เปลี่ยนไป
ตอนนี้มองว่าถ้ามันตอบโจทย์ธุรกิจและผ่านเส้นคุณภาพขั้นต่ำได้ก็ถือว่าใช้ได้
ท้ายที่สุดแล้ว โค้ดส่วนใหญ่ก็มักมีจุดให้ปรับปรุงอยู่เสมอ
มันพูดถึง ความจริงอันเย็นชาของสายงาน Staff+ engineering ได้ตรงมากจนรู้สึกเชื่อมโยง
ข้อความที่ว่า “จงทำในสิ่งที่บริษัทต้องการ แม้มันจะไม่ถูกต้องก็ตาม” ฟังดูประชดประชัน แต่ผมก็คิดว่ามันยังดีกว่าถูกบดขยี้ไปกับเฟืองของบริษัท
เขาแค่ไม่เชื่อใน อุดมคติของคุณ เท่านั้นเอง ซึ่งไม่ได้แปลว่าเขาเป็นพวกสิ้นหวังเสมอไป
ผมคิดว่าปัญหาไม่ใช่เรื่องอายุงาน แต่เป็นเรื่องของ แรงจูงใจ
มันทำให้นึกถึงประโยคในหนัง Office Space ที่ว่า “ถ้าทำงานหนักแล้วไม่ได้อะไรตอบแทน ก็ย่อมไม่มีแรงจูงใจ”
แต่ฝ่ายบริหารให้ความสำคัญกับ ผลลัพธ์ มากกว่าโค้ดที่ดี
เพราะพวกเขาไม่สามารถประเมินคุณค่าของงานบำรุงรักษาได้ งานแบบนั้นเลยไม่ได้รับการยอมรับ
สุดท้ายคนที่ปล่อยโค้ดลวก ๆ ขึ้นโปรดักชันกลับได้เลื่อนตำแหน่ง
ฉันเคยใส่ใจทั้งทีมและโค้ด ทำงานอย่างละเอียดรอบคอบ แต่สุดท้ายกลับถูกประเมินด้วยตัวชี้วัดง่าย ๆ อย่าง จำนวน PR
ความยากของโค้ดหรือการมีส่วนร่วมกับทีมถูกมองข้าม และมีแค่ “ตัวเลขที่มองเห็นได้” เท่านั้นที่สำคัญ
สุดท้ายแม้แต่หัวหน้าที่ประเมินฉันก็ถูกเลิกจ้างในอีกไม่กี่เดือนต่อมา
น่าขันตรงที่ ถ้าฉันไม่ใส่ใจอะไรเลย ก็คงไม่ต้องเจ็บกับเรื่องพวกนี้
บริษัทใหญ่ปฏิบัติต่อวิศวกรเหมือนเป็น ทรัพยากรที่เปลี่ยนแทนกันได้
นี่ไม่ใช่แค่เรื่องประสิทธิภาพ แต่เป็น กลยุทธ์เพื่อเอียงดุลอำนาจไปทางฝ่ายบริหาร
จุดประสงค์คือไม่ให้โปรเจกต์สำคัญต้องพึ่งพากลุ่มวิศวกรเฉพาะเจาะจง
พวกเขาต้องการให้แรงงานทุกคนแทนกันได้หมด
ตรงกันข้าม หลายแห่งกลับพยายาม รั้งวิศวกรเก่ง ๆ เอาไว้ มากกว่า
หมายความว่าวัฒนธรรมแบบนี้ไม่ได้เป็นปัญหาของผู้บริหารฝ่ายเดียว
เรามักเห็นกรณีที่ไวยากรณ์และโครงสร้างของโค้ดดูตามตำราเป๊ะ แต่ แนวทางพื้นฐานกลับผิดตั้งแต่ต้น
การรีวิวโค้ดมักสนใจแค่ไวยากรณ์ แต่ไม่คุยเรื่องปัญหาทางธุรกิจหรือความซับซ้อน
ระยะสั้นอาจดูไม่มีปัญหา แต่ระยะยาว หนี้ทางเทคนิค จะระเบิดออกมา
ผลก็คือ PR ต้องค้างกันเป็นวัน ๆ เพราะถกเถียงเรื่องคุณภาพโค้ดเล็ก ๆ น้อย ๆ
ทุกคนหมกมุ่นอยู่กับ ความสะอาดของโค้ดที่ผิวเผิน
การดูความสมเหตุสมผลเชิงตรรกะหรือมองภาพใหญ่นั้นยากกว่า และบ่อยครั้งผู้รีวิวก็ไม่รู้บริบทด้วย
ถ้าองค์กรทั้งองค์กรไม่มีพื้นที่พอจะรับฟังฟีดแบ็กแบบนี้ สุดท้ายก็จะต้องพึ่ง ‘ระบบที่พอถูไถให้ใช้ได้’
การออกแบบระดับใหญ่ควรถูกทบทวนก่อนถึงขั้นรีวิวโค้ด
พูดอีกแบบคือ เรากำลังทำให้ต้นทุนระยะยาวเป็นระบบอัตโนมัติ
บริษัทใหญ่ไม่ได้สนใจตัวโค้ดเอง
โค้ดเป็นแค่ ตัวกลาง ที่ทำให้บริษัทขับเคลื่อนได้
สุดท้ายสิ่งสำคัญไม่ใช่โค้ด แต่คือ กระบวนการ
หัวใจสำคัญคือเมื่อระบบพังลงมาแล้ว มีขั้นตอนสำหรับกู้คืนมันได้หรือไม่
ทุกอุตสาหกรรมเมื่อขยายใหญ่ขึ้นก็ต้องทำ การประนีประนอม คล้าย ๆ กัน
คุณภาพแบบ ‘ดีพอใช้’ ทำกำไรได้มากกว่าความสมบูรณ์แบบ
ก็เหมือนความต่างระหว่างเก้าอี้ IKEA กับเก้าอี้ Herman Miller ที่ต่างกันเพราะข้อจำกัดคนละแบบ
ทักษะที่แท้จริงคือ ความสามารถในการรู้ว่าควรประนีประนอมตรงไหน
โครงสร้างของบริษัทใหญ่บีบให้วิศวกรต้องยอมประนีประนอมแบบนี้
วิศวกรอาวุโสที่ดีจะไม่เขียนโค้ดแย่ตั้งแต่แรก
ปัญหาคือ แรงกดดันให้เร่งสร้างผลงานระยะสั้น กับ พื้นฐานที่ไม่แน่นพอ
การข้ามขั้นตอนรีวิวหรือไม่คิดเรื่องสถาปัตยกรรมให้รอบด้านต่างหากคือสาเหตุที่แท้จริง
อย่างที่อธิบายในคอมเมนต์นี้ ถ้าคุณต้องทำงานอยู่บนกองโค้ดแฮ็กสะสมเป็นล้านบรรทัด ต่อให้พยายามแค่ไหนก็ทำให้สะอาดไม่ได้
สุดท้ายมันก็เหมือน พยายามยกสปาเกตตีขึ้นมาทั้งกอง
วิศวกรอาวุโสมักต้องเผชิญ ภาวะกลืนไม่เข้าคายไม่ออก ระหว่าง ‘ทำให้ถูกต้อง’ กับ ‘ทำให้เสร็จเร็ว’ อยู่เสมอ
ไม่มีทางเข้าใจ codebase ที่ซับซ้อนได้ในชั่วข้ามคืน และถ้าองค์กรไม่ให้ความสำคัญกับ การสั่งสมความรู้ คุณภาพก็จะยิ่งแย่ลง
สำหรับพนักงานใหม่ การมอบหมายงานเอกสารหรือการเก็บระเบียบโค้ดให้ทำ จะช่วยให้เขาเรียนรู้โครงสร้างของระบบได้ดี
ถึงจะมีโค้ดแฮ็กเก่าเยอะแค่ไหน ก็แตะต้องไม่ได้เพราะทำให้พังไม่ได้
ไม่ว่าการออกแบบจะยอดเยี่ยมแค่ไหน ถ้าฐานรากเป็นทราย มันก็พังอยู่ดี
ข้อสรุปของผู้เขียนที่ว่า ‘ความอ่านง่ายมาก่อนคุณภาพ’ ถ้าเอาตามนั้นก็แปลว่าทุกโปรเจกต์ในบริษัทใหญ่ควรต้องมี เครื่องมือ static analysis และ auto formatter เป็นอย่างน้อย
แต่ในความเป็นจริงกลับไม่ใช่แบบนั้น
การนำเครื่องมือพวกนี้มาใช้เป็นการตัดสินใจของ ผู้จัดการที่ไม่ใช่สายเทคนิค และพวกเขาไม่ชอบต้นทุนระยะสั้น
สุดท้ายแล้ว กำหนดการออกของทุกอย่าง ก็มีอำนาจเหนือสิ่งอื่นใด
ตอนเคยไปทำคอนซัลต์ให้บริษัทยักษ์ใหญ่ด้านการผลิตแห่งหนึ่ง ผมเจอ แพตเทิร์นการทำ object modeling แปลก ๆ อยู่ทั่วทั้งโค้ด
พอตามรอยหาสาเหตุก็พบว่า ทีมพัฒนาเข้าใจแนวคิดที่ผู้ออกแบบตั้งใจไว้ (blueprint–mold–product) ผิดไปหมด
ผมเสนอให้แก้ แต่คำตอบที่ได้กลับมาคือ “มันสายไปแล้ว”
ผลคือโมเดลที่ผิดนี้ถูกใช้ต่อเนื่องเกิน 10 ปี และก่อ หนี้ทางเทคนิคมหาศาล
สถิติ อายุงานสั้น ในบริษัทใหญ่ชวนให้เข้าใจผิดได้
มันอาจเป็นแค่ผลจากการเพิ่มจำนวนพนักงานอย่างรวดเร็ว จนทำให้ค่ามัธยฐานดูสั้นลงเท่านั้น
ถ้าจะดูให้แม่นจริงควรดูจากคนที่ลาออกเป็นหลัก
เพราะในอดีตจำนวนโปรแกรมเมอร์มีน้อยกว่ามากเฉย ๆ