Tuần 5: Good-Enough Software — Khi nào thì "đủ tốt" là đủ?

Mở đầu

Hồi đó giờ mình toàn nghĩ lập trình viên giỏi là phải viết code hoàn hảo. Xử lý mọi edge case, không một dòng code thừa, test phủ 100%. Nghe sang chứ gì? Nhưng mà đọc tới topic này của cuốn The Pragmatic Programmer, mình giật mình nhận ra: theo đuổi sự hoàn hảo đôi khi chính là cái bẫy chậm nhất dẫn tới thất bại.

programmer writing code Ảnh: Lukas Blazek — Pexels

Good-Enough Software

Topic này nói về một khái niệm tưởng dễ mà khó: phần mềm "đủ tốt".

Tác giả không bảo anh em viết code cẩu thả đâu nha. Ý là: mỗi dự án đều có giới hạn về thời gian, ngân sách và tài nguyên. Ém thêm tính năng, trau chuốt thêm giao diện, tối ưu thêm 5% hiệu năng — tất cả đều tốn chi phí. Câu hỏi là: cái giá đó có đáng không?

Cuốn sách đưa ra một câu hỏi hay lắm: phần mềm của bạn sẽ được dùng trong tình huống nào? Một hệ thống điều khiển tên lửa thì không có khái niệm "đủ tốt". Nhưng một landing page MVP cho startup A/B test ý tưởng thì hoàn toàn khác — ship trước, chỉnh sau.

books reading learning Ảnh: Alexandra Krainyukhova — Pexels

Cái hay là tác giả không chỉ nói về lý thuyết. Họ kể chuyện về một hệ thống phone banking bị delay vì team cứ muốn perfect — khách hàng thì đâu cần code đẹp, họ cần nó chạy được, chạy đúng giờ, ổn định. Đó là lúc "tốt" trở thành kẻ thù của "đủ tốt".

Cảm nhận của mình

Mình từng làm một dự án mà khách yêu cầu chỉn chu từng pixel. Cả team mất 3 tháng cho cái web đẹp như tạc tượng. Ra mắt xong, khách bảo: "à, bọn anh đổi hướng kinh doanh rồi." 3 tháng xuống cống. Đọc tới topic này mình chỉ biết ước gì đọc sớm hơn.

Cũng phải nói thêm: đủ tốt ≠ qua loa. Lập trình viên chuyên nghiệp vẫn phải có pride in their work — không đẻ ra code rác rồi đổ tại "à, good enough mà". Quan trọng là biết cái chuẩn nào phù hợp cho hoàn cảnh nào. Code cho production banking khác code cho proof-of-concept demo khách. Biết phân biệt là kỹ năng sống còn.

Lại nhớ câu nói nổi tiếng của Voltaire: "The perfect is the enemy of the good." Cái bẫy của dev trẻ (mình ngày xưa cũng vậy) là cứ nghĩ "chưa xong" khi thực ra nó đã "xong" rồi. Release sớm, lấy feedback, cải tiến dần — đó mới là vòng lặp lành mạnh.

focus concentration Ảnh: Brett Jordan — Pexels

Kết

Good-Enough Software là bài học nhập môn về tư duy pragmatic — đúng như tên cuốn sách. Biết khi nào dừng lại, khi nào ship, khi nào trau chuốt thêm. Không phải từ bỏ chất lượng, mà là biết chất lượng cần thiết cho từng hoàn cảnh.

Tuần sau mình sẽ viết về Topic 6 — Your Knowledge Portfolio — cách quản lý kiến thức như quản lý tài sản đầu tư vậy đó. Hẹn gặp lại mấy bạn! 📚

Đây là bài số 5 trong series "Một giày một kiểu đọc The Pragmatic Programmer" — cảm nhận thật, không màu mè.