กระทรวงยุติธรรมสหรัฐฯ แถลงคดีของ David Tinley อดีตโปรแกรมเมอร์สัญญาจ้างของบริษัท Siemens Corporation ในสหรัฐฯ ที่เขียนโปรแกรมเป็น spreadsheet สำหรับการจัดการคำสั่งซื้อให้บริษัทเอาไว้ตั้งแต่ปี 2002 และเมื่อส่งมอบงาน ไฟล์จะทำงานไม่ได้เป็นระยะจนบริษัทต้องเรียก Tinley กลับมาซ่อม
Tinley ล็อกไฟล์ห้ามแก้ไขด้วยรหัสผ่าน แต่ในปี 2016 เขาเดินทางไปต่างประเทศและไฟล์ก็หยุดทำงานตามสคริปต์ที่เขากำหนดไว้ ทำให้บริษัทต้องแก้ไขด่วน จึงยอมมอบรหัสผ่านให้โปรแกรมเมอร์ของ Siemens โปรแกรมเมอร์คนนั้นจึงพบโค้ดที่ Tinley วางยาไว้
ทาง Siemens จ่ายค่า "ซ่อม" ไฟล์ spreadsheet นี้รวมเป็นเงินถึง 42,000 ดอลลาร์ ทำให้คดีนี้กลายเป็นคดีอาญาที่อัยการสหรัฐฯ ต้องมาทำคดีเอง ล่าสุด Tinley ยอมรับผิดตามข้อกล่าวหา ผู้พิพากษานัดกำหนดโทษเดือนพฤศจิกายนนี้ โดยโทษสูงสุด คือจำคุก 10 ปี ปรับ 250,000 ดอลลาร์
ที่มา - The Register, Department of Justice
ภาพโดย StockSnap
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- สงคราม GenAI บนคลาวด์ในปี 2024 ไปถึงไหนกันแล้ว | Cloudnone x AWS
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
Comments
ถ้าTinleyทำในยุคนี้แล้วให้Siemensมาสับตะไคร้Tinleyซะ ก็จะไม่เกิดเรื่องเกิดราว
สำหรับ Consultant สาย Enterprise แล้วนี่ ค่าซ่อมน่าจะเป็นน้ำเลี้ยงที่สำคัญมาก
ทำโปรดักท์ดีไปก็อาจจะจนได้
หืม........ทำแบบนี้มันคือการโกงชัดๆ
ทำดีไม่มีจนหรอก งานมันมาจากการบอกต่อก็มี
ทำแย่เกินไปแบบเคสนี้อาจจะได้เข้าคุกเอา
lewcpe.com, @wasonliw
แล้วก็จะไม่มีงานไม่มีเงินไปอีกนาน
ทำแบบในข่าวติดคุกแน่ๆครับ
ในไทยเองหลายที่หาคนทำไม่ได้ บางงานก็ไม่มีคนส่งราคาทั้งๆที่ราคาก็ไม่แย่ รับงานต่อให้รายได้ถึงแสนต่อเดือนโดยไม่อดหลับอดนอนตลอดอาจมีบ้างนิดหน่อยวันสำคัญๆยังเป็นไปได้อยู่ ยังไม่ถึงยุคที่ต้องวางยามั้งถึงมีกินถ้าไม่ใช่เพราะอยากได้เงินแบบไม่ต้องทำงานเพราะตอนนี้แค่บอกว่ารับทุกอันก็ทำไม่ทันแล้ว
ด้วยเงื่อนไขที่ enterprise ให้ ก็สร้าง bug ได้ง่าย ๆ อยู่แล้ว แบบไม่ต้องตั้งใจ
ฮ่าๆๆๆๆๆ ชอบความเห็นแบบตรงๆ ครับ
ทำไมผมรู้สึกตรงกันข้ามนะ แค่คำว่าระบบ Enterprise พอใช้งานไปสักพัก Bug, error, faulty หรือ exploit มันมาหาระบบเอง ได้งานทำแทบทันที
ความล้มเหลว คือจุดเริ่มต้นสู่ความหายนะ มีผลกระทบมากกว่าแค่เสียเงิน เวลา อนาคต และทรัพยากรที่เสียไป - จงอย่าล้มเหลว
หือ ต้องทำอย่างนั้นจริงๆหรอ...
ถ้าอยากหาน้ำเลี้ยงด้วยการทำซัพพอร์ต จะทำแบบนั้นก็ได้อยู่
แต่ ลูกค้าที่เคยทำส่วนใหญ่ชอบจ้าง vendor ที่ทำ support โดยเฉพาะมาทำอยู่แล้ว (ส่วนใหญ่เพราะมันถูกกว่า)
ขืนวางยา เงินก็เข้า บ.support หมด วางมากๆเผลอๆ CR เค้าก็จ้าง บ.Support เนี่ยแหละทำ
เพราะแก้บั๊กจนเก่งไปแล้วโดยปริยาย...
เท่าที่เห็นในไทย
แค่เขียนโปรแกรมแบบ bad habit/bad programming ก็ช่วยได้เยอะละ
เพราะส่งต่อให้คนใหม่ จะเป็นงานหยาบกับคนใหม่พอควร
ประสบการณ์ส่วนตัวคือ รับโค้ดมา ต้องมาแก้แทบตาย+จัดการใหม่ให้โค้ดอ่านง่าย
ก็หวังว่าเวลา maintain จะได้แก้ง่ายๆ
ผลคือ เค้าก็ส่งโค้ดต่อให้คนใหม่ที่ราคาถูกกว่าไปทำต่อ สบายเค้าไปทั้ง2ฝ่าย
ส่วนเราก็ต้องหางานหยาบมาทำต่อไป ...
อันนี้โดนเหมือนกันครับ . . . ชอกช้ำ
แต่คงต้องทำต่อไป อย่างน้อยก็ไม่ให้โดนด่าย้อนหลัง
มันไม่ใช่อย่างงั้นหนะสิ
สิ่งที่เกิดขึ้นคือ
ทีมใหม่ไล่โค้ดและแก้ได้ในเวลาไม่นาน แถมไม่ค่อยมีบัค
ขณะที่ตอนเราทำไล่โค้ดโคตรยาก ทำให้ต้องใช้เวลานานกว่า
แถมมีบัคแปลกจาก bad habit เช่น
สร้างตัวแปรเดียวกัน 2 ที่ ทำให้เกิดบัค อัพเดตค่าที่นึง แล้วอีกที่ยังค่าเดิม ฯลฯ
เลยโดนกาหัวว่า ทำงานช้า ไม่เก่งแถมคิดแพง ... (T_T)
เห็นแต่ละ reply เหมือนจะเข้าใจไปในทางว่า คุณ mr_tawan เห็นด้วยกับการวางยา
แต่ผมเข้าใจว่าคุณ mr_tawan เขาเพียงแค่แสดงความเห็นว่าอาชีพสายนี้ ค่าเรียกตัวกลับไปแก้งานคือรายได้ที่สำคัญ ถ้าหากทำโปรแกรมที่ดีมากจนไม่มีข้อผิดพลาดเลยก็จะขาดรายได้สำคัญไป
ซึ่งในความเป็นจริง โปรแกรมใหญ่ๆแต่ละตัวนี่ เขียนตรวจสอบอย่างดี ก็ยังมีปัญหาตามตัวให้ไปแก้เป็นระยะอยู่แล้ว (><) หรือบางทีก็ต้องการปรับเปลี่ยนอะไรเพิ่มเติม
~ HudchewMan's Station & @HudchewMan~
เห็นด้วย
ปัจจุบัน ดราม่ากว่า 90% เกิดจากการตีความคำพูดอีกฝ่ายให้ดู non-sense มากกว่าพยายามเข้าใจว่าเค้าสื่อถึงอะไร
(ล่าสุดก็เรื่อง coding ไม่ใช้คอม)
ซึ่งไม่รู้ว่าเกิดจาก ทัศนคติอะไรบางอย่างในใจคนฟัง หรือ สกิลการอ่านจับใจความบกพร่อง
พอพยายามสื่อสารใหม่ ให้หวังว่าจะเข้าใจที่เราสื่อได้ ก็กลายเป็นดราม่าซะงั้น...
พอเราเบื่อดราม่าเลยเงียบไป ก็ประกาศชัยชนะอีก เอาเข้าไป...
+128 ครับ การทำโปรแกรมที่ไม่มีข้อผิดพลาดเลยมันเป็นไปได้ยากอยู่แล้วครับ ทำดีแค่ไหนก็มีโอกาสเจอแมลงอยู่ดี ต้องรอยุคที่ใช้ AI มาแก้/สร้างโปรแกรมได้นั่นแหละมั้ง พวกนี้อาจตกงานได้
ไม่ได้คิดว่าเขาเห็นด้วยกันการวางยา
แต่ไม่เห็นด้วยกับส่วนของ แต่ทำโปรดักท์ดีไปก็อาจจนได้ฮะ
ปกติถึงไม่ได้อยากใช้โปรดักท์ใหม่ แต่โลกก็จะบังคับให้คุณต้อง Customize โปรแกรมเรื่อยๆอยู่แล้วอะครับ
เช่นกฏหมายเอยอะไรเอย หรือถ้าเป็นพวก ERP ก็มีพวกภาษีอะไรอีก
ฝั่ง Enterprise ที่โปรดักท์ตัวนึงนั่งกับลูกค้าหลายเดือนกว่าจะขึ้น
ถ้าถึงเวลาต้องทำ CR กับโปรดักท์ที่เราดูเค้าไปเรียก vendor อื่นไม่เรียกใช้เราที่นั่งกับเค้าตั้งหลายเดือน
...ก็ช่วยไม่ได้จริงๆนะครับ
บันทัดแรก ผมเห็นด้วยว่าการทำงานซัพพอร์ตของที่ทำไปเป็นรายได้ที่ดีต่อคนทำ
แต่บันทัดที่2 ผมถือว่าเป็นความคิดที่รับไม่ได้ครับ ในฐานะเดฟ เราต้องทำโปรดักท์ให้ดีที่สุดเท่าที่เราทำได้ครับ ถึงแม้สุดท้ายมันก็ยังมีบักส์ให้ค่อยตามซัพพอร์ทก็เถอะ แต่การพูดแบบนี้เหมือนกับทำๆ ไปเถอะ ถ้า Consult เจ้าไหนมีความคิดแบบนี้ผมจะคงต้องติดแบล๊คลิสไว้ล่ะครับ
The Dream hacker..
คุณลืม /s ครับ
หัวร้อนกันเลย 555
โดนถล่มเละ (ฮา)
ผมไม่ได้บอกว่าให้วางบั๊กนะครับ แค่เอาให้มันผ่าน UAT แบบปริ่ม ๆ แล้วให้เขาซื้อ support จ่ายเงินแก้บั๊ก ที่ชม.ละ $100 แทน อะไรประมาณนี้ :-)
ฮ่าๆๆๆๆ เข้ามาร่วมหัวเราะด้วยครับ
จริง ๆ ข้างบนก็เล่นมุข (ไม่ควรทำนะ)
แต่เห็นบางที่ที่แบบ แค่ปั่นโปรเจคให้ผ่าน UAT ให้ผ่านก็รากเลือดละ แล้วพวก Dev ก็จะบอกว่า "ถ้ามีอะไรก็ให้ Support จัดการละกัน"
แล้ว support ก็ตาบอดคลำช้างกันไป (ค่าแรงแพงด้วย)
โปรแกรมก็เขียนมางงๆ เอกสารก็เละไปจนถึงไม่เสร็จ
ของที่ Standard มีก็ทำ Customize ....
ของที่ควร Customize ก็ Brute force
เอกสารมาเป็นรายโปรเจค
แต่โปรดัทก์ที่ผ่านการอัพเดตมาหลายร้อยโปรเจค เอกสารที่มี ... ว้อยนั่นมันรีลีสเมื่อสิบปีที่แล้วนี่หว่า หน้าตาเปลี่ยนไปตอนไหนฟระ
... คนไม่เคยทำซัพพอร์ตจริงจังไม่มีทางเข้าใจ 555
ใช่ฮะ บางทีโปรแกรมบอกว่าเป็นเทมเพลตใช้ทั้ง บ. แต่ดันมี customize ยิบย่อยเฉพาะบางสาขาแล้วไม่แชร์เอกสารร่วมกัน แต่ละสาขา Customize เรื่องเดียวกันแต่ทำคนละ logic ขึ้นอยู่กับว่าทำปีไหน ใครรับผิดชอบ
คนเละก็ support เรื่องเดียวกัน ปัญหาเดียวกัน แต่เอกสารที่มีในมือใช้ไม่ได้ซะงั้น
โดนถล่มเละ (ฮา)
ผมไม่ได้บอกว่าให้วางบั๊กนะครับ แค่เอาให้มันผ่าน UAT แบบปริ่ม ๆ แล้วให้เขาซื้อ support จ่ายเงินแก้บั๊ก ที่ชม.ละ $100 แทน อะไรประมาณนี้ :-)
โดนถล่มเละ (ฮา)
ผมไม่ได้บอกว่าให้วางบั๊กนะครับ แค่เอาให้มันผ่าน UAT แบบปริ่ม ๆ แล้วให้เขาซื้อ support จ่ายเงินแก้บั๊ก ที่ชม.ละ $100 แทน อะไรประมาณนี้ :-)
Be inspire ...
ที่แสบคือ แอบวางโค้ด timed bomb ให้พังทุกๆ 2-3 ปี ไม่ได้ถี่เกินไป จนคนสงสัย
แต่โป๊ะแตกตรงดันมาพังตอนไม่อยู่ เลยต้องยอมให้รหัสผ่านในการปลด protected sheet ความเลยแตก
ไอเดียดี แต่ไร้จรรยาบรรณไปหน่อย 555
จรรยาบรรณเป็นสิ่งสำคัญมากจริงๆนะ วันนี้มันอาจจะทำเงินให้ได้แต่แลกกับอนาคตมันไม่คุ้มหรอก
เป็นสิบปี นี่ไม่ไดพัฒนาตัวโปรแกรมใหม่เลยหรอเนี่ย ใช้ยาวนานมาก
if it work don't fix
โดยเฉพาะงานระดับ enterprise เขียนเสียบเข้าไปเรื่อยๆ กว่าจะรู้ตัว ก็ทิ้งระบบเก่าไม่ได้แล้ว
ไม่ต่างจากการวาง malware ทิ้งไว้เลย
แต่ปกติถ้า project ขนาดใหญ่ ไม่ต้องตั้งใจวาง bug มันก็จะมี bug โผล่มาโดยไม่คาดคิดเองอยู่แล้วล่ะ แต่ที่เจอส่วนใหญ่คือเรื่อง business requirement ตอนแรกไม่ชัดเจน จนขัดแย้งกันเองมากกว่า(ชนิดแม้แต่ตัวลูกค้าก็คาดไม่ถึงว่าจะมีเคสแบบนี้ หรือตัว regulator เองเพิ่งออกมาล้อมคอกทีหลัง) ก็ต้องมาตามแก้ระบบให้รองรับ solution ใหม่ๆเรื่อยๆ
ปกติอัพเดท os ไปสักพักมันก็อาจจะมี dependencies บางอย่างหรือหลายอย่างเข้ากันไม่ได้
ซึ่งมันเป็นเรื่องที่ไม่มีใครควบคุมได้โดยตรง
จะทำให้อยู่ในเงื่อนไขรับประกันหรือไม่ก็แล้วแต่จะตกลงกันใว้ก่อน คือนั่งเฉยๆยังไงก็มีงานอยู่ดี
แทนที่จะวางยา ไปร่างสัญญาให้มันครอบคลุมดีกว่าไหม
"แทนที่จะวางยา ไปร่างสัญญาให้มันครอบคลุมดีกว่าไหม"
เขาเจอที่อืนถูกกว่า เขาก็ไปครับ
แล้วมีน้อยมากที่จะบากหน้ากลับมาขอความช่วยเหลือ
ถึงมาขอ บางทีก็เละจนเราแก้ไขลำบากคับ
ถ้าโปรแกรมหมอนั่นไม่เจ๋งจริง คงอยู่ได้ไม่ถึงคุกหรอกครับ เพราะเขาจะเดินเข้าๆ ออกๆ แก้ BUG อยู่นั่น
ตอนหลัง Microsoft, Google, Adobe, Autodesk ก็มาแนวนี้หมด
ให้เช่าเป็นรายเดือนรายปีไงครับ มีเงินเลี้ยงตัวได้เท่าที่มีฐานลูกค้า
Windows 7 ที่ผมใช้ มันยังเสถียรมาก
เสถียรจน Microsoft ขอร้องให้เปลี่ยนไปใช้ Windows 10 ที่อัพเดตแล้วเปิดไม่ติด