Programming and all its related tasks are cumbersome. What is even more difficult is finding practical time limits to complete these tasks. There are many factors that play into why, but the biggest just may be the programmers themselves. The industry breeds dreamy designers who yearn to create and design the next best thing that promises to change the world. As great as their aspirations may be, there are realistic constraints that impede upon the completion process (known was scheduling).
Frederick Brooks in “The Mythical Man-month” identifies many of the constraints programmers work against, starting with the programmer. The first and a common mistake novice as well as seasoned programmers make is being overly ambitious. Hype from the thoughts of seeing conceptual ideas come to life, clouds the mind of realistic development expectations as it relates to completion time. Ambitions mask the plain sight intricacies of development, rendering the developer with incomplete and inconsistent ideas which become apparent during implementation.
Who would ever think that being overly ambitious could hinder the completion of a project? Just as baffling would be the idea that by adding more personnel to a project would even further the hinderance of a project. As Brooks explains, more man power does not equate to quicker turn-around-time. Thus, there is not a positive correlation between man power and completion time. This is due to the many perplexities that arise when an high magnitude of programmers work cohesively. One perplexity being that it adds the need for high levels of communication among all members of the project. This in itself is a difficult task to manage, especially when trying to maintain design integrity with intruding ideologies from members attempting to place their own “touch” onto their component of the project. So it is here that we find adding more personnel to a project lengthens scheduling time as opposed to shortening it.
The most unaccounted aspect of the scheduling process is testing. Eager to get the project up and running, programmers more than often drastically underestimate the time needed to properly test their project. According to Brooks, many programmers allocate less than one-half the time actually needed for testing. This false scheduling strains other crucial parts of the project such as costs and design quality. Projects generally have budgets and time constraints, and when those time constraints are exceeded, it yields a hasty design, inefficient testing, and can causes a project to eclipse the budget. Naturally one would think to add more time the schedule, but testing usually occurs in the last phase of the project, and at this point the due date is rapidly approaching.
Brooks suggests that employing a smaller skilled group of programmers work more affectively than having an army of programmers. To achieve a proficient level of production, there must be a balanced ratio between functionality, simplicity, and design integrity. As this is a science continually growing, new ideologies will arise in how-to best obtain the balanced ratio. One way may be the surgical approach, where subtasks are divvied onto a supporting cast of developers, allowing a minimum number of programmers to design and implement the core of the project. But until then, it seems best to keep programmer group sizes to a minimum.
