Analysis Of The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month (Brooks, 1995) is a collection of lessons the author learned during his experience working on a large software project. One of the very first errors he suggests is considering a program as a programming software product, without realizing that a programming software product is nine times more expensive than a simple program. Brooks (1995) then addresses the common failure to deliver software projects on time. The reasons he gives to explain this problem are manifold. Mainly, it is due to excessive optimism in the estimation and poorly allocated time for planning and testing—with too much time scheduled to code, and not enough to plan and test the software. There are two other errors that are arguably even more captivating. One being that an estimation in man-months cannot be simply multiplied or divided by the men or the months, but rather a more complex analysis must be carried out to understand whether the work can be partitioned among the software engineers and how much communication is needed between the engineers. Specifically, when a task cannot be partitioned, then …show more content…
For example, requirements, design, and implementation cannot be seen or touched, either (Wang, 2007). This presents quite a few problems for software project managers. Usually, a project manager in any engineering field would regularly check the product, as it is being built, to ensure that it responds to all requirements and specifications and that the planned schedule is being followed. However, a software project manager cannot see the product as it is being developed, making it difficult to estimate whether or not the project is proceeding at the right pace, what specific activities have already been conducted, and how long it will take to complete the project (Cohn,
The Mythical Man-Month (Brooks, 1995) is a collection of lessons the author learned during his experience working on a large software project. One of the very first errors he suggests is considering a program as a programming software product, without realizing that a programming software product is nine times more expensive than a simple program. Brooks (1995) then addresses the common failure to deliver software projects on time. The reasons he gives to explain this problem are manifold. Mainly, it is due to excessive optimism in the estimation and poorly allocated time for planning and testing—with too much time scheduled to code, and not enough to plan and test the software. There are two other errors that are arguably even more captivating. One being that an estimation in man-months cannot be simply multiplied or divided by the men or the months, but rather a more complex analysis must be carried out to understand whether the work can be partitioned among the software engineers and how much communication is needed between the engineers. Specifically, when a task cannot be partitioned, then …show more content…
For example, requirements, design, and implementation cannot be seen or touched, either (Wang, 2007). This presents quite a few problems for software project managers. Usually, a project manager in any engineering field would regularly check the product, as it is being built, to ensure that it responds to all requirements and specifications and that the planned schedule is being followed. However, a software project manager cannot see the product as it is being developed, making it difficult to estimate whether or not the project is proceeding at the right pace, what specific activities have already been conducted, and how long it will take to complete the project (Cohn,