Khác biệt giữa bản sửa đổi của “The Mythical Man-Month”

Nội dung được xóa Nội dung được thêm vào
Dòng 41:
Khi đánh giá thời gian của một dự án, nên nhớ rằng, để lập trình một sản phẩm (có thể bán cho khách hàng) và hệ điều hành thì sẽ khó gấp ba lần để viết một ứng dụng<ref>[http://www.amazon.com/gp/reader/0201835959/ref=sib_dp_pt# Mythical Man Month] Hình 1.1, Trang 13</ref>. Nên luôn giữ trong đầu về thời gian sẽ phải bỏ ra để giải quyết những vấn đề kỹ thuật, những phản đối với việc quản trị hay những nhiệm vụ không thuộc về kỹ thuật, ví dụ như họp hành.
 
====CommunicationTrao đổi thông tin====
Để tránh những thảm họa, tất cả những cá nhân trong một dự án nên giao tiếp với các thành viên trong nhóm bằng nhiều cách nhất có thể (e-mail, điện thoại, họp, ghi chú v.v...). Thay vì phải giả định điều gì, lập trình viên đó nên hỏi kiến trúc sư của dự án để làm rõ mục đích của một tính năng mà mình sẽ hiện thực, trước khi thực hiện với một giả định mà nó có thể dẫn tới việc hoàn toàn sai.
To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible (e-mail, phone, meetings, memos etc.) Instead of assuming something, the implementer should instead ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect.
 
====The Surgical Team====
Much as a surgical team during surgery is led by one surgeon performing the most critical work himself while directing his team to assist with or overtake less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally 5-10 times as productive as mediocre ones.