[ad_1]
Fred Brooks qua đời vào tháng trước ở tuổi 91. Nhờ cuốn sách bán chạy nhất về quản lý phát triển phần mềm, The Mythical Man-Month Essays on Software Engineering, ông đã trở thành một huyền thoại về lập trình và quản lý.
Trong nhiều thập kỷ, tôi đã gặp nhiều nhà lãnh đạo công nghệ, nhưng ít người gây ấn tượng thầm lặng như Brooks. Mặc dù tôi đã gặp anh ấy nhiều lần tại các sự kiện, nhưng tôi chỉ nói chuyện với anh ấy một lần khi anh ấy là chủ nhiệm khoa khoa học máy tính của Đại học Bắc Carolina.
Một số nhà lãnh đạo công nghệ, chẳng hạn như Steve Jobs, thể hiện sự xuất chúng của họ như một tân tinh. Những người khác, như Brooks, trầm lặng, hóm hỉnh và không kém phần thông minh theo cách riêng của họ.
Ngay cả khi không có cuốn sách này, Brooks vẫn nổi tiếng trong lịch sử máy tính vì là một trong những người đi đầu trong việc phát triển một hệ điều hành có thể được sử dụng trên nhiều kiến trúc máy tính: OS/360 của IBM.
Khi điều đó xảy ra, trình biên dịch chương trình 360 là ngôn ngữ máy tính đầu tiên của tôi. Cảnh báo công bằng: Ngôn ngữ đầu tiên của không ai phải là IBM 360 Assembler.
Đối với Ngôn ngữ điều khiển công việc 360 (JCL), tôi đã học được cùng lúc chính Brooks gọi nó là “ngôn ngữ lập trình máy tính tồi tệ nhất từng được phát minh bởi bất kỳ ai, ở bất kỳ đâu.” Tôi sẽ chỉ nói rằng có “lý do” khiến tôi chuyển từ máy tính lớn sang máy tính mini Unix.
Tuy nhiên, về mặt cá nhân, Brooks lưu ý: “Quyết định quan trọng nhất mà tôi từng đưa ra là thay đổi dòng máy IBM 360 từ byte 6 bit thành byte 8 bit, do đó cho phép sử dụng các chữ cái viết thường. Sự thay đổi đó lan truyền khắp nơi.”
Vâng đúng vậy. Kiến trúc máy tính 8-bit, 16-bit, 32-bit và 64-bit mà tất cả chúng ta đã lớn lên đều sử dụng đều bắt đầu với Brooks.
Heck, từ “kiến trúc” cho chip và thiết kế máy tính đến từ anh ấy.
Nhưng, điều mà hầu hết chúng ta nhớ là cuốn sách của ông, với những tuyên bố quản lý súc tích. Bây giờ, giá như chúng ta thực sự sử dụng chúng nhiều hơn trong văn phòng của mình!
Hãy bắt đầu với điều nổi tiếng nhất trong số chúng: Định luật Brooks: “Thêm nhân lực vào một dự án phần mềm muộn sẽ khiến nó muộn hơn.”
Nhiều lần, tôi thấy các công ty thổi cái này.
Ngày nay, sai lầm này thường xuyên xảy ra khi nhấn mạnh rằng, ồ, giả sử, tất cả các nhà phát triển đều có mặt tại văn phòng vào chiều thứ Sáu để biện minh cho công việc của họ và làm việc trong giai đoạn nước rút. Đúng vậy, tôi đang nghĩ về Elon Musk và Twitter.
Tuy nhiên, đó không chỉ là Musk. Nếu trong công việc kinh doanh của bạn, bạn luôn kết thúc bằng việc dành hàng đống giờ làm thêm vào cuối bất kỳ dự án nào để thu hồi chúng, thì bạn đang làm sai. Chắc chắn, đôi khi điều đó là cần thiết; nhưng nếu nó trở thành một thói quen, bạn có vấn đề về quản lý.
Một chủ nghĩa Brooks liên quan là “chín phụ nữ không thể sinh con trong một tháng.” Hoặc, chọn lại Musk, bạn cũng không thể đưa chín lập trình viên hệ thống nhúng Tesla vào và tạo một tính năng mạng xã hội mới trong một tháng. Hoặc ba tháng, hoặc chín tháng, cho vấn đề đó.
Một câu hỏi liên quan khác là: “Làm thế nào mà một dự án phần mềm lớn lại bị trễ một năm? Câu trả lời: Mỗi ngày một lần!” Giải pháp là chú ý đáp ứng các mốc quan trọng của từng cá nhân ở mọi cấp độ quản lý.
Brooks cũng ủng hộ ý tưởng về các nhóm phần mềm nhỏ, được quản lý chặt chẽ, có thể tránh được tình trạng phình to tính năng và làm mất thời gian của họ.
Rốt cuộc, Brooks cũng nói, “phần mềm tốt, giống như thức ăn ngon, cần có thời gian để sản xuất.”
Bây giờ một số người sẽ nói rằng nguồn mở đã bác bỏ điều này. Trong bản tuyên ngôn mã nguồn mở Nhà thờ và Chợ, Brooks ủng hộ phong cách “thánh đường”. Ngược lại, các nhà phát triển nguồn mở và Linux được tổ chức lỏng lẻo đã đẩy các bản cập nhật phần mềm ra sớm và thường xuyên.
Nhưng đó thực sự là trường hợp?
Nếu bạn xem xét kỹ hơn cách Linux được phát triển, bạn sẽ thấy nhiều nhà phát triển. Nhưng chúng được quản lý bởi một nhóm bảo trì nhỏ hơn nhiều do Linus Torvalds đứng đầu. Bản thân các bổ sung mã bao gồm nhiều thay đổi nhỏ.
Những thay đổi quan trọng, chẳng hạn như thêm Rust vào Linux hoặc WireGuard VPN, phải mất nhiều năm mới xảy ra.
Tôi nghĩ điều đáng chú ý là vào thời trung cổ, chợ thường được đặt trong khuôn viên nhà thờ.
Brooks cũng cảnh báo chúng ta rằng chúng ta nên cảnh giác với những viên đạn bạc.
“Không có sự phát triển đơn lẻ nào, trong cả công nghệ hay kỹ thuật quản lý, mà bản thân nó hứa hẹn dù chỉ một bậc cải tiến lớn trong vòng một thập kỷ về năng suất, độ tin cậy và sự đơn giản.” Nói tóm lại, nếu ai đó trong nhóm của bạn hứa với bạn cái nhìn sâu sắc, khám phá hoặc phát minh mới nhất của họ sẽ “Thay đổi Thế giới!” đừng tin họ.
Chắc chắn, có những sự phát triển làm thay đổi thế giới.
Gần đây nhất, điện toán đám mây, Docker/container và điện toán cạnh đã xuất hiện trong tâm trí. Nhưng không ai trong số đó xảy ra nhanh như bạn nghĩ.
Tất cả đều mất nhiều năm để trưởng thành và trở nên quan trọng. Ý tôi là, trong khi thành công dường như bất ngờ của Docker có thể khiến bạn ngạc nhiên, thì công nghệ vùng chứa của nó đã có từ năm 2000 và Nhà tù FreeBSD.
Cuối cùng, DevOps, xu hướng phát triển hàng đầu hiện nay, cũng nhờ rất nhiều vào công việc của Brooks.
Anh ấy rất tin tưởng vào việc mọi người giao tiếp trong một dự án. (Nhu cầu giao tiếp hiệu quả khiến cho việc giải quyết các vấn đề về phần mềm bằng cách ném thêm nhiều giờ lao động vào chúng là không thể.)
Đúng là bây giờ chúng ta thường làm điều đó trên Git và với các công cụ CI/CD, nhưng giao tiếp hiện nay, như chúng đã được thực hiện vào đầu những năm 60, vẫn rất quan trọng đối với các dự án kinh doanh và lập trình thành công.
Và thành công chính là mục tiêu của Brooks.
Bản quyền © 2022 IDG Communications, Inc.
[ad_2]
