"Có thể làm được (2003)"

Câu chuyện phát triển hệ điều hành Multics

• André Bensoussan, người phát triển hệ điều hành Multics, phụ trách các thay đổi chính của hệ thống tệp.
• Trình quản lý VTOC là một hệ con đảm nhiệm việc di chuyển thông tin tệp giữa đĩa và bộ nhớ, quản lý vùng đệm bộ nhớ dùng chung và quản lý không gian thông tin trên đĩa.
• André phụ trách thiết kế, triển khai và kiểm thử trình quản lý VTOC, đồng thời thực hiện công việc thiết kế bằng cách vẽ rất nhiều sơ đồ.

Quá trình phát triển và thành công

• Tom Van Vleck, điều phối viên của dự án, từng lo ngại về tiến độ, nhưng đã yên tâm khi André bắt đầu viết mã.
• André viết mã bằng bút chì thay vì dùng terminal máy tính, từ chối cả việc được hỗ trợ gõ máy và tự mình thực hiện toàn bộ công việc.
• Cuối cùng, ông nhập đoạn mã gọn gàng đã viết bằng bút chì vào terminal để biên dịch, sửa một vài lỗi gõ, rồi biên dịch thành công.
• Khi được tích hợp vào hệ thống để kiểm thử, trình quản lý VTOC đã hoạt động hoàn hảo ngay từ đầu.

Bí quyết thành công của André

• André đã viết một chương trình hoàn hảo chỉ với công cụ duy nhất là bút chì.
• Lỗi duy nhất được phát hiện trong trình quản lý VTOC là do sai sót của Tom Van Vleck, người đã hướng dẫn sai thứ tự gọi thủ tục xử lý lỗi.
• Cách làm việc của André đã được giới thiệu như một câu chuyện về kỹ nghệ phần mềm trong số tháng 4 năm 1994 của IEEE Computer và được cập nhật vào tháng 11 năm 2003.

Ý kiến của GN⁺

• Câu chuyện phát triển hệ điều hành Multics của André Bensoussan cho thấy thiết kế kỹ lưỡng và sự tập trung có thể tạo ra thành quả hoàn hảo như thế nào.
• Khi phương pháp truyền thống chỉ dùng bút chì và giấy được đặt cạnh các công cụ phát triển phần mềm hiện đại, phức tạp, câu chuyện này nhấn mạnh tầm quan trọng của cách tiếp cận trung thành với nền tảng cơ bản.
• Đây là một ví dụ tốt nhắc lại tầm quan trọng của công việc chuẩn bị kỹ lưỡng và kiểm thử trong lĩnh vực kỹ nghệ phần mềm, đồng thời mang lại bài học quan trọng cho giáo dục kỹ thuật.

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  • Yêu cầu rõ ràng: Lý do phần mềm có ít lỗi và chạy nhanh là vì có các yêu cầu được định nghĩa rõ ràng. Phần mềm hiện nay thường mơ hồ về việc cần phải xây dựng gì, và liên tục thay đổi do cách làm "Agile". Nếu cung cấp cho lập trình viên API rõ ràng và các tiêu chí được xác định tốt, thì phần lớn đều có thể viết mã hiệu quả.

• Tóm tắt bình luận thứ hai:

  • Năng lực của lập trình viên Liên Xô: Từ trải nghiệm làm việc cùng những người đào thoát khỏi Liên Xô, lý do các lập trình viên Liên Xô xuất sắc là vì khả năng tiếp cận máy tính rất hạn chế. Họ phải lập trình bằng giấy và bút chì, nên có xu hướng cố gắng làm cho mọi thứ chạy đúng ngay từ đầu.

• Tóm tắt bình luận thứ ba:

  • Tầm quan trọng của không gian làm việc cá nhân: Trích dẫn một bình luận của tài khoản jrd259 trong một thread Hacker News trước đây, nhấn mạnh tầm quan trọng của một chiếc bàn lớn và không gian làm việc riêng tư không có thông báo làm phiền.

• Tóm tắt bình luận thứ tư:

  • Trải nghiệm lập trình trên giấy: Khi còn nhỏ, người viết đã soạn một chương trình Turbo Pascal bằng máy đánh chữ tại nhà ông nội mà không có máy tính, rồi sau đó chạy nó trên PC. Ngoài ra còn chia sẻ trải nghiệm chép ra giấy hàm cộng nhị phân của ngôn ngữ lập trình kỳ lạ tự tạo tên là Ziim để tìm và sửa lỗi. Điều này nhấn mạnh rằng khi hạn chế những cách làm "dễ", ta có thể viết mã được suy nghĩ kỹ hơn.

• Tóm tắt bình luận thứ năm:

  • Lập trình trong quá khứ: Vào cuối thời kỳ "big iron", lập trình viên gần như không khác mấy nhân viên nhập liệu. Chương trình được viết trên giấy, và thời gian tính toán thì đắt đỏ, quý giá. Khi phát sinh lỗi, không thể sửa cho đến khi đặt lịch được lượt chạy CPU tiếp theo. Điều này khuyến khích cách tiếp cận cẩn trọng. Còn hiện nay, việc phát triển phần mềm diễn ra lặp đi lặp lại với debug trong IDE.

• Tóm tắt bình luận thứ sáu:

  • Mã do André Bensoussan viết: Cung cấp một liên kết đến đoạn mã do André Bensoussan viết.

• Tóm tắt bình luận thứ bảy:

  • Quy mô phần mềm thời đó: Phần mềm khi ấy nhỏ hơn rất nhiều so với hiện nay; đa số dự án có quy mô tính bằng megabyte, nhưng vẫn quá lớn để có thể "mang theo" chỉ trong một tệp duy nhất.

• Tóm tắt bình luận thứ tám:

  • Bài tập lập trình ở trường: Theo trải nghiệm của một người bạn, ở trường học họ phải nộp bài tập lập trình trên giấy và nhận kết quả sau một tuần. "Thời gian biên dịch" kéo dài một tuần là một trải nghiệm giáo dục khiến người ta phải kiểm tra lại công việc của mình kỹ hơn.

• Tóm tắt bình luận thứ chín:

  • Không có Agile/Scrum: Để trả lời cho việc André đã có thể làm công việc như vậy bằng cách nào, lý do là vì khi đó phương pháp phát triển Agile/Scrum còn chưa ra đời.

• Tóm tắt bình luận thứ mười:

  • Trải nghiệm viết code trên giấy: Năm 14 tuổi, trong lớp học lập trình ở trung học, người viết đã làm phần lớn bài code trên giấy. Là một đứa trẻ nghèo ở một đất nước nghèo, họ không có PC ở nhà, còn bản sao ZX Spectrum trong phòng máy của trường thì không chạy được Turbo Pascal mà họ đang dùng.