Programming work is not very much like digging ditches (the work for which project-management techniques were originally designed); it is a lot more like digging holes in very stony ground. Sometimes things go beautifully, sometimes a programmer spends whole days beating his head against the wall on a single point, until finally the light bulb lights up. These are two very different modes of mental operation, commonly known in the industry as Flow and Stuckness.
Flow is the mental state when a programmer understands what he is doing and directly interacting with the process of program writing or debugging. In Flow, hours can go by like minutes, and amazing productivities can be achieved. Error rates drop drastically, and work becomes a kind of highly productive play. Maintaining this state as much as possible is very important to successful programming work.
The difficulty with Flow is that it takes about 15 minutes to enter the state, and an interruption that must be dealt with (phone call, visit, bio-break) will terminate the state. Therefore, if there is one interruption every 15 minutes on average, the amount of Flow-assisted work (which in practice can mean the amount of work, period) drops to zero! It is no accident that programmers still report, as they have for the last 50 years, that the most productive programming times are after hours, because it becomes possible to enter Flow and remain in it hour after hour until the belly or the bladder demand attention.
Stuckness is the reverse of Flow; the state where the programmer simply can't see what's wrong. The point may be and often is completely obvious in hindsight, but discovering what that point is, is literally the same kind of discovery process that scientists use (or mechanics, for that matter): make a hypothesis, test it, attempt a fix, see if it solves the problem, test to make sure a new bug hasn't been introduced. There is also variety of Stuckness that arises during design rather than debugging, a kind of analysis paralysis where it is clear that the current way of doing things is wrong, but no clear vision of the correct way has yet emerged.
Stuckness cannot be overcome by will or planning, only by insight, and the arrival of insight is not predictable. Striving for insight can often be what prevents it from being achieved. The motto "Sleep on it" reflects the perception that blocking the conscious mind can be just the right thing to allow the unconscious mind to operate, often giving the key to the problem as if from nowhere. Distraction is an equally successful approach. During times of stuckness, therefore, interruptions are actually desirable, as they allow this useful distraction.
All these things make completion time estimates for programming projects something akin to a black art. One cannot predict from one day to the next when interruptions will occur, of course, but their effects on the project can vary from very good (intense Stuckness) to very bad (intense Flow disruption).
A relatively successful model for programming management, however, is based on the notion of trouble-ticket tracking. Since projects are not for the most part self-generated but rather arise out of requests from editorial, sales, or customers directly, each of them can be treated as a trouble ticket at whatever scale, and then the question becomes not "Is this project past its highly arbitrary deadline?" but rather "How many projects being starved of the time and attention they need?" Mechanised and human support for this process is extremely helpful and is not usually provided to the extent necessary.
Weinberg, Gerald. The Psychology of Computer Programming.
Brooks, Frederick. The Mythical Man-Month.
DeMarco, Tom, and Tim Lister. Peopleware.