Mặc dù có một chút khó khăn để có thể phân tích thấu đáo, nhưng tôi đã bị thu hút bởi bài viết The Rise of “Worse is Better” (Sự gia tăng của xu hướng “tồi hơn thì tốt hơn”), bởi vì nó chạm đến một chủ đề mà tôi đã để ý nổi lên trong các bài viết trên blog của mình, đó là: hãy loại bỏ những cái phức tạp, thậm chí khi giải pháp phức tạp trên lý thuyết lại là hướng tiếp cận đúng đắn hơn.

Có 2 người nổi tiếng, một người đến từ trường đại học danh tiếng MIT và người kia đến từ một nơi danh tiếng không kém là Berkeley (nhưng đang làm việc trên hệ điều hành Unix), một lần nọ họ gặp nhau và thảo luận về các vấn đề của hệ điều hành. Người đến từ MIT thông thạo về ITS (hệ điều hành MIT AI Lab) và cũng đã đọc mã nguồn của hệ điều hành Unix. Anh ta cảm thấy thích thú về cách mà Unix giải quyết vấn đề PC loser-ing. Vấn đề PC loser-ing xuất hiện khi mà một chương trình sử dụng triệu gọi đến một thủ tục hệ thống để thực thi một hoạt động có thời gian kéo dài và có trạng thái quan trọng, như là bộ đệm nhập xuất chẳng hạn. Nếu có một đứt quãng xuất hiện trong suốt quá trình hoạt động đó, thì trạng thái của chương trình sử dụng phải được lưu lại. Bởi vì lời triệu gọi thủ tục hệ thống thường là một lệnh đơn, nên máy PC không đủ khả năng để bắt lại trạng thái của tiến trình đó. Thủ tục hệ thống sẽ hoặc là hoàn nguyên hoặc là ép buộc hoạt động tiếp. Giải pháp đúng đắn ở đây là hoàn nguyên và phục hồi lại lệnh mà đã triệu gọi thủ tục hệ thống để hồi phục lại chương trình sử dụng sau khi bị ngắt quãng. Nó được gọi là “PC loser-ing” bởi vì máy PC đó đang trở nên bị ép buộc vào trong “loser mode (mô hình mất mát),” nơi mà “loser (kẻ mất mát)” thường được đặt một cái tên trìu mến là “user (người dùng)” tại MIT.

Gã đến từ MIT không nhìn thấy bất kỳ đoạn code nào quản lý phần này và đã hỏi gã đến từ New Jersey rằng vấn đề đó được quản lý bằng cách nào. Gã New Jersey nói rằng những người quen thuộc với hệ điều hành Unix biết rất rõ vấn đề đó, nhưng giải pháp là họ cho thủ tục hệ thống luôn luôn kết thúc, nhưng đôi khi một mã lỗi sẽ được trả về để báo hiệu rằng thủ tục hệ thống đã thất bại trong việc hoàn thành các hoạt động của nó. Một chương trình sử dụng đúng đắn, sẽ phải kiểm tra mã lỗi trả về và xác định xem liệu có nên thử triệu gọi lại thủ tục hệ thống lần nữa hay không. Gã MIT không thích giải pháp này bởi vì cách làm đó không đúng đắn lắm.

Gã New Jersey nói rằng giải pháp Unix đã đúng bởi vì triết lý thiết kế của Unix là đơn giản hóa và nếu làm theo cách đúng đắn thì quá phức tạp. Bên cạnh đó, các lập trình viên có thể dễ dàng chèn thêm các đoạn kiểm tra và vòng lặp. Gã MIT chỉ ra rằng việc thực thi kiểu đó thì đơn giản nhưng interface của chức năng thì lại phức tạp ra. Gã New Jersey nói rằng có một sự đổi chác đúng đắn đã được lựa chọn trong cái tên Unix, việc thực thi đơn giản thì quan trọng hơn nhiều so với interface đơn giản.

Gã MIT sau đó đã lẩm bẩm rằng “đôi khi cần phải có những người mạnh mẽ mới có được món thịt gà ngon mềm”.

Và đây là câu chốt đáng tiền:

TUY NHIÊN, TÔI TIN RẰNG TỒI-HƠN-THÌ-TỐT-HƠN, THẬM CHÍ TRONG HÌNH THÁI TIÊU CỰC CỦA NÓ, NHỮNG ĐẶC TRƯNG KIỂU NÀY ĐÃ SỐNG SÓT TỐT HƠN LÀ NHỮNG-THỨ-ĐÚNG-ĐẮN, VÀ HƯỚNG TIẾP CẬN CỦA GÃ NEW JERSEY KHI SỬ DỤNG CHO PHẦN MỀM LÀ HƯỚNG TIẾP CẬN TỐT HƠN SO VỚI CÁCH CỦA GÃ MIT.

Nghe có vẻ giống như là một fan hâm mộ Linux vậy, nhưng tôi tin điều này với tất cả bản thân mình. Bạn muốn có những ví dụ không? Hãy nhìn xung quanh bạn mà xem.

• Kiến trúc x86 mà có thể bạn đang đọc trang web này dựa trên nó thường được thừa nhận rộng rãi như là một thứ hoàn toàn vớ vẩn. Và nó đúng là như vậy thật. Nhưng nó là một thứ vớ vẩn đã được mài giũa để có một cạnh sắc không thể tin được. x86-64? Con của chúng ta sẽ có thể vẫn sử dụng nó cũng nên. Trong khi đó, kiến trúc Itanic thì ngày càng chìm sâu hơn vào Biển Bắc sau mỗi tháng.
• Registry của Windows. Bạn có bao giờ để ý rằng mọi thứ trong .NET thường hoàn thành thông qua một số file text đơn giản có đuôi .config không? Điều đó có gợi cho bạn nhớ lại tất cả những file .INI cũ kỹ? Hoặc có lẽ một file cấu hình của Apache? Trong khi Registry về mặt lý thuyết là cao cấp hơn, nhưng nó lại là nguyên nhân của rất nhiều vấn đề hầu như liên quan đến sự phức tạp– chỉ cần mất một vài byte là nó sẽ bị hỏng; và bạn sẽ phải “vẫy tay vẫy tay chào nhau” tới tất cả dữ liệu registry của bạn. Và vâng, dĩ nhiên là bạn phải cài lại hệ điều hành. Nó giống như là kiểu giải pháp “hai bước tiến và một bước lùi” vậy.
• COM thì tự bản thân nó đã nói lên tất cả. Bạn không muốn chỉ việc xây dựng một Web Service hơn sao?
• Java. Bạn đã nghe điệp khúc này lặp đi lặp lại bao nhiêu lần rồi. Java thì quá hàn lâm, quá phức tạp không cần thiết. J2EE ư? Bất cứ thứ gì cùng với chữ “Enterprise” trong tiêu đề, thì nên thay thế bằng từ “Complicated (phức tạp)”. Như tôi đã chỉ ra trước đây, các tổ chức đang trích dẫn rằng cần giảm độ phức tạp và tăng năng suất khi chuyển đổi sang sử dụng .NET.

Bất cứ khi nào có thể, hãy luôn hướng về phía đơn giản. Tại sao lại sử dụng kế thừa khi mà một object đơn giản sẽ làm? Tại sao lại sử dụng kế thừa khi mà bạn có thể sử dụng một interface? Tại sao thậm chí lại đi viết code khi mà bạn có thể mua hoặc đánh cắp (hoặc open-source) nó? Trên tinh tần của Strunk and White, thì hãy tránh xa sự phức tạp, và giống như các từ trên một trang vậy, khi mà bạn không thể loại bỏ thêm từ nào nữa– thì lúc đó bạn đã hoàn thành công việc.

Các giải pháp đơn giản sống sót và thịnh vượng bởi vì chúng hoạt động tốt, và mọi người có thể thực sự hiểu chúng. Đừng cho rằng bất kỳ ai cũng đủ thông minh để quản lý những giải pháp phức tạp đến mức khó tin– lạc quan là một mối nguy hiểm nghề nghiệp đối với các lập trình viên. Chúng ta nên cố gắng xây dựng những giải pháp đơn giản bất cứ khi nào có thể, thậm chí nếu đôi khi chúng ta phải bịt mũi khi làm nó.

Bài viết gốc được viết vào năm 1991; có một bài kéo theo rất hay là Back to the Future: Is Worse (Still) Better?, và cũng có một Wiki về chủ đề này cùng với nhiều link trỏ đến.