Không ai thực sự biết sản phẩm phần mềm vận hành như thế nào [Bài dịch]

1. Tính mờ đục của các hệ thống công nghệ lớn

• Ngay cả các công ty công nghệ lớn cũng vận hành chính hệ thống của mình trong một trạng thái như "sương mù chiến tranh (fog of war)".
• Ngay cả với những câu hỏi cơ bản như "Người dùng loại Y có thể dùng tính năng X không?", "Chính xác điều gì xảy ra khi thực hiện hành động Z?", hay "Hiện có bao nhiêu gói cước?", cũng chỉ có một số rất ít người trong tổ chức có thể trả lời.
• Trong trường hợp nghiêm trọng, còn phải chỉ định hẳn một người chuyên điều tra; lẽ ra chỉ cần xem tài liệu công khai là phải có câu trả lời, nhưng thực tế lại không như vậy.

2. Nguồn gốc của sự phức tạp: Wicked Features

• Phần mềm lớn trở nên cực kỳ phức tạp vì có self-hosting, dùng thử miễn phí, kiểm soát theo tổ chức/chính sách, bản địa hóa đa ngôn ngữ, các tính năng tuân thủ quy định... Những yếu tố này ảnh hưởng đến mọi tính năng mới.
• Ví dụ: khi thêm kiểm soát chính sách, mỗi tính năng mới đều phải áp dụng theo; khi bản địa hóa, phần dịch thuật cũng phải đi kèm.
• Việc xác định "khách hàng enterprise self-hosting ở khu vực EU có được truy cập một tính năng cụ thể hay không" chỉ có thể kiểm tra bằng cách trực tiếp lần theo code hoặc thử nghiệm. Nếu lược bỏ các tính năng như vậy thì sẽ đánh đổi một khoản doanh thu khổng lồ, và đây cũng là khác biệt giữa công ty lớn và công ty nhỏ.

3. Giới hạn của tài liệu hóa

• Về lý thuyết, khi có tính năng mới thì có thể tài liệu hóa các tương tác liên quan, nhưng tốc độ thay đổi của hệ thống nhanh hơn tài liệu.
• Trong một môi trường động chứ không phải hệ thống tĩnh, người viết tài liệu phải luôn đi trước thay đổi, và điều đó gần như bất khả thi.
• Vấn đề còn lớn hơn ở chỗ: nhiều hành vi xuất hiện không phải từ chủ đích tường minh mà từ sự tương tác giữa các thiết lập mặc định – việc tài liệu hóa gần như tương đương với tự mình khám phá hệ thống thực tế.

4. Cốt lõi của câu trả lời: codebase và kỹ sư

• Câu trả lời chính xác chỉ có thể có được bằng cách trực tiếp nhìn vào codebase, và đây là nền tảng quyền lực của kỹ sư.
• Chức năng cốt lõi của đội ngũ kỹ thuật là khả năng trả lời các câu hỏi về phần mềm.
• Điều này tận dụng tri thức ngầm (tacit knowledge) tồn tại trong đầu những người hiểu một phần code cụ thể.
• Khi tái cơ cấu đội ngũ, việc thất thoát tri thức khiến phải thực hiện những "ca phẫu thuật thăm dò" (ép sửa code/kiểm tra, v.v.).
• Viết code thì dễ, nhưng đưa ra câu trả lời đáng tin cậy lại khó vì vấn đề nằm ở mức độ tự tin (rủi ro trả lời sai, cần tóm lược và nén thông tin).

5. Kết luận: một năng lực quý giá

• Người không làm kỹ thuật thường tin rằng phần mềm đã được kỹ sư hiểu hoàn toàn, nhưng không ai thật sự hiểu trọn vẹn các hệ thống lớn.
• Ngay cả câu hỏi cơ bản cũng cần được điều tra lặp đi lặp lại, và khi hệ thống thay đổi thì lại phát sinh sắc thái và ngoại lệ. Khả năng đưa ra câu trả lời chính xác là cực kỳ có giá trị.