In some situations, the critical path method tends to be longer than expected but rarely shorter than expected. This process can be explained by the nature of the critical path methods themselves. The critical path methods help managers and programmers to find the best possible way for project completion. Programmers try to understand both the overall structure of the systems on which they work and the details they need in order to work on particular problems within those systems.
For each programmer, the balance between overview and detail is different, as is the balance between analytic (top-down) and synthetic (bottom-up) approaches. In many cases, it is impossible to calculate the duration of thinking and creative processes, problem-solving and decision making. For many, system knowledge is in the details, and in some cases, all knowledge is derived from inferring the relationships between small pieces of the overall system. Other people find it more important to grasp the whole picture before going into details.
Also, some but not all programmers think in terms of design, the idea that there is or should be a controlling form, idea, or style underlying an entire system, and that grasping the underlying design is important in understanding the system. This way of thinking is clearly tied to programming methodology. It is not automatic, however, that programmers will apply this approach to preexisting systems, and in fact, some do not. Whether and how well one can apply the notion of design to a system, moreover, is a function of the system itself, not just of the programmer’s learning style.