The nature of programming is not, generally, one continuous task, nor is it a task that always works well with defined breaks. Like many creative tasks, it is a job that tends to work well in bursts. If a programmer is going along great guns, the last thing you want him or her to do - and likely the last thing they want to do - is stop and leave.

Additionally, programming tends to have bits of downtime worked into it. For instance, waiting on long tests (particularly when testing or debugging large data sets), waiting on feedback from QA, waiting on completion of a code module your next task depends on. Often, but not always, programmers can find other useful things to fill in this time, but sometimes the next task requires a longer period of intense concentration than the available time, relies on the current one, or is otherwise inappropriate to work on at that time. Also, it isn't necessarily advantageous to remove focus from the current task even if work needs to wait on something. This means that at times, programming provides enforced breaks. It makes sense to encourage programmers to use that time for their own purposes rather than remain at work in order to fit a set work schedule. The alternative is to have programmers sitting at their desks trying to fill time. This simply forces them to get in the habit of not maximizing their productivity while at work. Also, most programmers are likely to consider this a waste of their time and react badly.

Programming is a type of problem solving. Some difficult problems can be solved by the application of hard work. But other problems can only be solved with a creative solution. Creative solutions often require inspiration. Often inspiration comes when you take your focus off the problem and do something completely different. A workplace that requires a set schedule can make it difficult to do this – or at least make a programmer wait until after work to do so.

Many programmers like to work intensely whenever the urge – or a solution – hit them. When set schedules are required, this can result in programmers putting in lots of overtime to accommodate both the set schedule and their work done when they were most efficient. This can lead to burnout, which always makes people inefficient.

Because of these factors, expecting programmers to work 9-5 or other set schedules can be inefficient. It often makes more sense to require programmers to attend team meetings and encourage them to work with other programmers in their team but allow them to work whatever hours are most effective for them. There is another option - Extreme Programming. Extreme Programming, or XP, changes the process of programming to a sustainable daily pace, which fits in well with set schedules. In fact, XP encourages set schedules and leaving at the end of the day rather than working all night. XP is too broad of a topic to cover here, but the fact that it requires major methodology changes to support set schedules serves to illustrate why set schedules and conventional programming methodologies aren't necessarily a good match.