Khi lập trình viên bị “mù lỗi”: Vì sao sản phẩm tệ nhưng đội ngũ vẫn nghĩ nó tuyệt vời?

Trong ngành công nghệ, có một hiện tượng kỳ lạ mà ít ai dám thừa nhận: nhiều đội ngũ phát triển tin rằng sản phẩm của họ tuyệt vời, trong khi thực tế người dùng đang vật lộn với vô số lỗi và trải nghiệm tồi tệ. Bài viết này phân tích nguyên nhân của “căn bệnh mù lỗi” (bug blindness) và lý giải vì sao việc tự dùng thử sản phẩm (dogfooding) thường không đủ để phát hiện vấn đề, cùng với những giải pháp thiết thực cho các đội ngũ phát triển phần mềm.

Hiện tượng “mù lỗi” (bug blindness) đang trở thành một vấn đề nghiêm trọng trong ngành công nghệ, đặc biệt khi các công cụ lập trình AI khiến việc tạo ra phần mềm chất lượng thấp trở nên dễ dàng hơn bao giờ hết. Tác giả bài viết, một kỹ sư giàu kinh nghiệm, đã chỉ ra rằng hầu hết mọi người đều gặp phải cùng một lỗi nhưng không nhận ra, và điều này dẫn đến những quyết định sai lầm trong phát triển sản phẩm.

Vì sao chúng ta không thấy lỗi của chính mình?

Tác giả bài viết cho biết ông dễ dàng quan sát hàng trăm đến hàng nghìn lỗi mỗi tuần, trong khi hầu hết đồng nghiệp không thấy điều gì bất thường. Điều này không phải vì ông dùng máy tính theo cách khác biệt, mà vì hầu hết mọi người đang gặp cùng một lỗi nhưng không chú ý đến chúng.

“Nếu bạn không phải là lập trình viên, đó có lẽ là cách tốt hơn để nhìn thế giới, nhưng tôi nghĩ việc chữa trị ‘mù lỗi’ rất hữu ích cho các lập trình viên.”

Điều thú vị là tác giả đã áp dụng phương pháp này cho nhiều bạn bè và đồng nghiệp — chỉ cần chỉ ra lỗi cho họ thấy. Sau vài tuần, những người có thiên hướng phù hợp bắt đầu tự nhận ra lỗi.

Ví dụ điển hình: Blackboard và những phần mềm “được yêu thích” một cách kỳ lạ

Một trong những ví dụ ấn tượng nhất là câu chuyện về Blackboard — phần mềm quản lý khóa học từng được sử dụng rộng rãi tại các trường đại học. Dù bị cả sinh viên lẫn giảng viên ghét cay ghét đắng, một nhân viên của Blackboard mà tác giả gặp vẫn tin rằng phần mềm này được người dùng yêu thích.

Wikipedia từng ghi nhận Blackboard trở thành “một trong những công ty bị ghét nhất — thậm chí khinh miệt — trong lĩnh vực giáo dục”. Báo cáo của Fast Company năm 2011 cho thấy 93% người tham gia khảo sát “ghét” công ty này. Vậy mà nhân viên của họ vẫn nghĩ sản phẩm của mình tuyệt vời.

Discourse: Khi gian lận chỉ số hiệu năng là một “giải pháp”

Một ví dụ khác là Discourse — nền tảng diễn đàn mã nguồn mở. Các nhân viên của Discourse tự hào về hiệu năng của sản phẩm, nhưng thực tế họ đã chèn code cố tình làm chậm thời gian tải trang để “ăn gian” chỉ số LCP (Largest Contentful Paint) — một chỉ số quan trọng của Google.

Hành vi này không chỉ vô nghĩa với người dùng mà còn gây hại trực tiếp cho trải nghiệm. Tác giả đặt câu hỏi: “Làm sao một người có thể nhìn vào kết quả tìm kiếm đầy spam và vẫn khẳng định kết quả đó tuyệt vời?”

Thói quen “tự mù” — Khi chúng ta học cách thích nghi với lỗi

Tác giả chia sẻ một câu chuyện cá nhân thú vị: thời còn dùng chuột bi (mechanical mouse), bụi bẩn bám vào bi chuột khiến con trỏ di chuyển loạn xạ. Khi bạn ông dùng thử, anh ta không thể điều khiển chuột nổi, nhưng tác giả lại dùng bình thường. Hóa ra, ông đã vô thức học cách bù trừ chuyển động loạn xạ của chuột bằng những cử động tay cực kỳ phức tạp mà không hề nhận ra.

“Tôi nghĩ rằng một phần lớn của ‘biết dùng máy tính’ và ‘biết dùng phần mềm’ là phát triển một kho tàng các thói quen này mà bạn thực hiện ở mức vô thức.”

Ví dụ, tác giả có thói quen đổi tiêu đề Google Docs sau khi mở tài liệu vài giây, vì nếu gõ ngay, tiêu đề sẽ bị ghi đè. Hay thói quen tắt WiFi trên laptop của Microsoft trước khi đăng nhập để tránh lỗi “không có máy chủ đăng nhập”.

Dogfooding — Giải pháp chỉ hiệu quả một phần

Việc tự dùng thử sản phẩm (dogfooding) là phương pháp phổ biến để phát hiện lỗi, nhưng nó chỉ hiệu quả nếu người dùng thử không vô thức xây dựng các thói quen né tránh lỗi. Lập trình viên thường rất giỏi “né” lỗi — đó là kỹ năng sống còn trước thời đại AI — nên họ dễ dàng không nhận ra vấn đề.

Phản ứng phổ biến của developers khi được góp ý là: “Hả? Dễ mà, chỉ cần làm [một chuỗi thao tác phức tạp mà không người dùng bình thường nào nghĩ ra]” hoặc “Không thấy hướng dẫn ở trang 43 của tài liệu à?”

Làm thế nào để chữa “mù lỗi”?

Tác giả khẳng định có thể chữa được tình trạng này, nhưng chỉ khi người đó thực sự cởi mở. Chỉ cần liên tục chỉ ra lỗi cho họ thấy, sau vài tuần hoặc vài tháng, họ sẽ bắt đầu tự nhận ra vấn đề. Nhiều người sau đó thậm chí còn nói với tác giả rằng họ “thấy lỗi ở khắp mọi nơi”.

Điều này ngày càng quan trọng trong bối cảnh các công cụ lập trình AI (coding agents) giúp tạo ra phần mềm chất lượng thấp dễ dàng hơn bao giờ hết. Tuy nhiên, cũng chính những công cụ này lại giúp cải thiện chất lượng phần mềm — từ hiệu năng đến giảm thiểu lỗi — nếu chúng ta nhận ra rằng chất lượng có thể được cải thiện.

Kết luận

“Mù lỗi” không chỉ là vấn đề cá nhân mà còn là văn hóa của nhiều công ty công nghệ. Khi một đội ngũ tin rằng sản phẩm của họ tuyệt vời trong khi thực tế người dùng đang chật vật, đó là dấu hiệu của sự thiếu kết nối với thực tế. Việc nhận ra và khắc phục tình trạng này không chỉ giúp cải thiện chất lượng sản phẩm mà còn là chìa khóa để xây dựng phần mềm thực sự hữu ích cho người dùng.

“Việc cố tình đánh đổi chất lượng để lấy tốc độ là một chuyện, nhưng khi tôi thấy điều này xảy ra, luôn có một sự ‘mù lỗi’ kỳ lạ khiến mọi người trong dự án đều nghĩ họ đang tung ra thứ gì đó chất lượng rất cao — dù thực tế không phải vậy.”