Ben Collins-Sussman đã viết về lập trình viên bất an như sau: Bạn sẽ làm gì khi có một ai đó đưa ra một dự án mã nguồn mở với một số lượng khủng các đặc trưng mới mà phải mất nhiều tháng trời để viết ra? Liệu có ai có đủ thời gian để review lại hàng ngàn dòng code đó? Điều gì sẽ xảy ra nếu có một quyết định thiết kế tồi được thực hiện ngay từ rất sớm trong quá trình đó — liệu còn có ý nghĩa gì không khi chỉ ra sai lầm của nó tại thời điểm này? Việc tung ra cộng đồng hàng tấn code thì hiếm khi là điều tốt cho một dự án: nhóm phát triển hoặc sẽ bắt buộc phải loại bỏ nó hoàn toàn, hoặc chấp nhận nó và phải đối mặt với một hộp đen đồ sộ và khó hiểu, cũng như khó thay đổi và bảo trì. Nó khiến cho dự án đó đi theo một hướng mà không có nhiều sự bàn thảo hoặc đồng lòng.

Và cứ như vậy, tôi đã tập hợp được rất nhiều câu chuyện để chỉ ra một thực tế rằng các lập trình viên không muốn viết code trong một môi trường mở. Các lập trình viên không muốn các đồng nghiệp nhìn thấy những sai lầm hoặc thất bại của họ. Họ muốn làm việc một cách bí mật, ở trong một cái hang, và sau đó tung ra phần code “hoàn hảo” tới cộng đồng của mình, cứ như thể là chưa bao giờ có lỗi nào xảy ra vậy.

Tôi không nghĩ đó là sự ngạo mạn mà là do sợ hãi và ngượng ngùng. Đáng lẽ phải xem việc lập trình như một hoạt động có tính xã hội, thì hầu hết các coder dường như lại xem nó như là một đấu trường dành cho những người hùng, và sẽ làm bất cứ điều gì để bảo vệ cái lầm tưởng đó. Họ cũng tốt khi chia sẻ code, nhưng với điều kiện là họ thể hiện bản thân mình như là kẻ không thể mắc sai lầm. Có thể đó chỉ là tính cách tự nhiên của con người.

Ben đang nói về phát triển các dự án mã nguồn mở, nhưng khuôn mẫu này cũng tồn tại trong cả phát triển phần mềm thương mại nữa. Hiện tượng tương tự cũng đã được ghi lại trong cuốn sáchDynamics of Software Development xuất bản vào năm 1995 của tác giả Jim McCarthy. Nó được thể hiện như là Quy tắc #30: Đừng đi vào bóng tối.

Bạn phải quản lý các tác vụ phát triển phức tạp theo cách mà bạn có thể thu được một kết quả rõ ràng qua mỗi một khoảng thời gian ngắn nào đó. Trong nhóm của mình, chúng tôi tranh cãi khá nhiều về cái khoảng thời gian ngắn đó là bao nhiêu thì hợp lý: 5 ngày, 10 ngày, hay 3 tuần? Trong thế giới của chúng tôi, 3 tuần thì đồng nghĩa với việc đang đi vào bóng tối.

Tôi không biết con số nào thì thích hợp cho thế giới của bạn, nhưng chúng tôi muốn các thành viên trong nhóm phải giao kèo với những người khác rằng họ phải đưa ra được kết quả là các thành phần có thể nhìn thấy được mỗi khi kết thúc một khoảng thời gian đã quy định. Khi một ai đó trong nhóm không “giao hàng” đúng hẹn thì chúng tôi biết ngay. Chúng tôi biết rằng vậy là tuần này cả nhóm sẽ bị trễ một ngày so với kế hoạch. Điều đó có giá trị hơn rất nhiều so với việc đến cuối dự án đó mới thấy và la lên, “Trời ơi, chúng ta đã bị trễ tiến độ tới 6 tháng!” Và tại thời điểm đó thì đã quá trễ để ngồi mà buồn bực đếm số thời gian mà bạn đã bị chậm tiến độ.

Quy tắc #30 nói trên được theo sau bởi một quy tắc liên quan khác, đó là Quy tắc #31: Hãy coi chừng thằng cha ngồi lỳ ở trong phòng.

Các chuyên gia phát triển mà thường tự nhốt bản thân họ trong một cái phòng, người mà “đi vào bóng tối” trong một khoảng thời gian khá dài, thì thường là những người góp phần làm cho việc chậm tiến độ của cả nhóm. Không quan trọng là một lập trình viên có thể tài năng đến mức nào, đừng giao một tác vụ lớn và quan trọng cho lập trình viên đó, trừ khi anh ta hoặc cô ta hiểu rõ và gắn kết vào lối phát triển phần mềm mà bạn muốn thực hiện. Lập trình viên tài năng đó phải có khả năng làm việc trong một nhóm, khiến cho công việc của anh ta có thể nhìn thấy được là đang tăng dần lên và mọi người có thể thấy được mức độ trưởng thành của nó. Một số người cho rằng điều này là không thể chấp nhận được, và mặc dù người đó đóng một vai trò nào đó trong thế giới phát triển phần mềm này, thì anh ta cũng không phải là một thành phần của nhóm mà sẽ cống hiến hết mình để có thể hoàn thành một phần mềm tuyệt vời và đúng hẹn.

Điều này thì dễ dàng thực hiện hơn trong một công ty, bởi vì bạn thường có một vài kiểu (về mặt lý thuyết) quản lý dự án phù hợp tại nơi đó, và tất cả mọi người đều làm việc cùng dưới một mái nhà chung. Công việc sẽ hiệu quả và không thể đi vào bóng tối nếu bạn đang áp dụng bất kỳ hình thức nào của phát triển phần mềm theo mô hình Agile. Ví dụ, Ron Jeffries đã mượn cái khái niệm này từ cuốn sách của Jim McCarthy và đã hệ thống hóa nó vào kiến thức của Extreme Programming. Các tác vụ luôn được cắt nhỏ ra sao cho chúng vừa khít vào trong một vòng lặp riêng lẻ, và bạn sẽ chẳng bao giờ cho phép chúng bị tràn ra nhiều vòng lặp. Bạn sẽ luôn có một cái gì đóđể trình ra vào cuối của mỗi vòng lặp. Bạn không thể đi vào bóng tối mà không thoát khỏi dự án đó hoặc thậm chí là thôi việc.

Một dự án mã nguồn mở là một sinh vật hoàn toàn khác. Nó là một tập hợp pha tạp của rất nhiều tình nguyện viên được phân bố ở nhiều nơi. Không có bất kỳ vị quản lý dự án nào ở gần bạn để mà hối thúc bạn chia công việc của mình thành những phần nhỏ để có thể chia sẻ. Rủi ro để bị đi vào bóng tối là rất lớn. Gánh nặng đó bị dồn lên vai những lập trình viên riêng lẻ, không chỉ phải khiến cho công việc của họ trên dự án đó được phát triển đều đặn và cho ra kết quả trông thấy được, mà nó cũng phải làm cho họ vượt qua cảm giác bất an khi chia sẻ code trong quá trình phát triển với những người khác cũng đang làm việc trên dự án đó. Làm sao mà bạn có thể mong chờ các đồng nghiệp coder của bạn nghiêm túc nếu chính bản thân bạn lại không submit code đều đặn? Đó chỉ là một hình thái trong rất nhiều vấn đề của một dự án mã nguồn mở.

Đừng đi vào bóng tối. Đừng trở thành gã cứ nhốt mình ngồi lỳ trong phòng. Giấu giếm code của bạn cho tới khi nó “xong” thì cứ tưởng như an toàn hơn, nhưng thực ra điều đó không đúng. Việc chia sẻ những phần code đang viết của bạn cùng với các đồng nghiệp thì có vẻ đáng sợ, ít nhiều trong thế giới này — nhưng nó cũng mang lại những phản hồi và việc thảo luận sẽ làm cải tiến code của bạn và kéo bạn tiến gần hơn tới đích của dự án mà bạn đang làm việc trên đó. Và liệu đó không phải là mục đích của tất cả chúng ta ư?