Tar Pit

The Tar Pit is another name for this subject. It serves as an explanation of the distinctions between the phrases “program” and “finished systems programming project.” The chapter lists the four primary categories of programs. The first kind is referred to as a necessary software. A simple program is frequently employed to carry out specific tasks. An example of the second is a programming product. Programming products must undergo the requisite thorough testing for generalization and documentation in order to be deemed efficient and effective. The programming system, which consists of the first two categories, is the third category. Naturally, a programming system is made up of programs and programming products. This chapter entails that programming systems are made up of various systems or programs which function in harmony to result in the desired output. The fourth element of a program is the programming system product; this is often the primary objective of a programming team. This chapter further reveals that programming is an abstract and should always be fun. The abstract creates the problem in the process, but the greatest requirement is the demand for perfection expected so that computers can properly function. The author notes that, as the programming process continues, more problems arise. As such, to complete a project, no single programmer can efficiently work alone. Also revealed in this chapter, most developers enjoy and have fun with the design of a program. However, it becomes a challenge to them during the implementation phase. Programming is more of fun since it engages an individual into creativity and as a result, something surprising is often created to the surprise of ordinary people.

Chapter Two

The second chapter is entitled same as the title of the book “Mythical Man-Month.” The role of the chapter is to present all the challenges that are faced when undertaking software projects. It also extends to give explanations as to why assigning many people towards a project does not guarantee faster completion. As noted from the chapter there are various reasons why projects fail. These include, firstly; the application in bad project estimations. Secondly, that irrespective of efforts made, this does not translate to project progress. Thirdly, due to the lack of the required confidence on the estimates made, the project contractors often lack the necessary assertiveness. Fourthly, projects often fail due to inadequate monitoring of the progress. Lastly, project failure is due to the resulting addition of manpower deep into a project once it has been noticed that things are falling behind. The chapter assumes that the overall cost incurred in a project is a function of the machines and men dedicated to complete the project. This can be attributed to the minimal progress regardless of the additional workforce. When tasks are sufficiently parallel to proper communication, that’s when the men and month expenditures can become equivalent. Communication as an aspect should form part of the project work accomplished. As portrayed in this chapter, communication is a problem since it involves training which is a hurdle since it requires the productive contractors to spend some time training the new programmers joining the project. The rationale behind the option of adding new project developers is that they increase the project cost since they take lots of time in training and they are the ultimate cause of lateness in the completion of a project. The best solution in handling delay is by rescheduling and trimming the project’s tasks.

Works Cited

Brooks, F. (1995). The Mythical Man-Month. Addison-Wesley.