Programmer's High
When a long distance runner has been running long enough that endorphins kick in, said person experiences a feeling of euphoria that, literally, marathon runners have known to become almost "addicted" to. I am wondering if there is not a similar sense that programmers get when they are in such a state of "flow". That is - when progress is coming quickly, providing a positive feedback cycle to the developer. Each sprint of code coloring multiple tests green, nailing down 8 hours of work in two. Each feedback cycle providing a sense of accomplishment normally reserved for, perhaps, gaining a level in World of Warcraft :) (I kid... kinda)
The purpose of the people to whom the developers report - be it an application development manager, a project manager, or someone else, in my view, is to make sure developers stay "in flow" so they can, as frequently as possible, experience "programmer's high". What can drive programmers into this state:
Having a project with purpose
Nobody is going to get into a "programmers high" if the project they are working on, or the organization they are working for, is not compatible with their values. If you feel like you are doing evil (and assuming you are not evil yourself) - you will probably do as little as possible that you can get away with, which certainly wont keep you into the flow.
Now, not every project is going to involve optimizing the supply chain of anti-HIV drugs to poor African children, but it does not need to be that purposeful. Even writing the 99th version of a general ledger application can be purposeful if it tickles that "urge to invent" that resides, or at least should reside, in application developers. Any program that will truly have impactful results that, say, increase opportunities for yourself and your co-workers can be a candidate for "purposeful".
Having a boss and organization who you trust and respect (aka "no bozos")
Related to purpose, if the people or organization you report to make you miserable, you will have little means to get to "endorphins". You can't feel good if your efforts will only help people that, for whatever reason, you think don't deserve the result or won't appreciate the result. The biggest reason people leave their jobs is having a poor relationship with their direct supervisor. Not having a good relationship will make it impossible for your work under that supervisor to reach "programmer's high".
Ability to Avoid Interruption
Having a means to develop without being interrupted is critically important. While this is a common topic in much writing about programming, it bears repeating that yes, you need to allow developers to, if they can't at least have an office, have an environment where they can turn the outside world off for 4 or more hours at a time so bigger problems can be solved.
Great Tools and Techniques
Tools like ReSharper that allow for increased velocity in refactoring, tools like TFS and SVN that make source control less painful, and techniques like TDD that make change less risky - are all ways that help developers stay "in flow".
Smart Coworkers
Related to the no-bozos for your boss rule, having coworkers that collaborate with you rather than fight with you - ideally coworkers that you like and respect. Having to be "the hero" time and again to pick up the slack of others is a quick way to ruin motivation. On the other hand, having coworkers around that are also in flow tends to promote an culture of excellence and mutual support where the people involved can help eachother when they get stuck (ideally, in a forum that doesn't interrupt that second).
Recognition that Programming isn't Typing
While its related to the point above about having a "no-bozo" organization, the kinds of places where a programmer's high can take place tend to be the ones where "programming" isn't considered the act if typing C# code into an editor, but rather, a critical intellectual exercise where the developer creates abstract models that solve business problems. This, of course, requires recognition that software development is a creative exercise where that does not lend itself to draconian, heavyweight processes.
A Good QA Department
Critical to being able to be in the zone is having a complement in the Quality Assurance that knows how to do their job well, and who can constructivley work with software developers. That means, QA people who know how to put in re-creation criteria, who avoid interrupting developers but rather report issues in the correct channels so they can be prioritized, and who do not try to get into an adversarial relationship (one of the worst ideas ever is to hire one firm to do development and another to do QA - especially if the QA firm also sells developers and the QA person is incented to grow the account... just a thought).
That said, this is more likely when QA is seen as it's own valid occupation, such much like the "Editor-In-Chief".
Conclusion
When these things don't happen, you tend to have less productivity, more turnover, more acrimony, project failure, and competitive disadvantage to those organizations that "get it" and can harness the act of "getting developers in the zone". The job of every person who manages software developers is to get their people to "programmer's high" as much as possible.