Software pundits often spend time debating whether process is good or individual empowerment (in other words, commitment-oriented development) might be better. This is a false dichotomy. Process is good, and so is individual empowerment. The two can exist side by side. Process-oriented organizations can ask for an extreme commitment on specific projects. Commitment-oriented organizations can use software engineering practices skillfully.
The difference between these two approaches really comes down to differences of style and personality. I have worked on several projects of each style, and have liked different things about each style. Some developers enjoy working methodically on an 8 to 5 schedule, which is more common in process-oriented companies. Other developers enjoy the focus and excitement that comes with making a 24 x 7 commitment to a project. Commitment-oriented projects are more exciting on average, but a process-oriented project can be just as exciting when it has a well-defined and inspiring mission. Process-oriented organizations seem to degenerate into their pathological look-alikes less often than commitment-oriented organizations do, but either style can work well if it is skillfully planned and executed by capable people.
The fact that both process-oriented and commitment-oriented projects have pathological look-alikes has muddied the debate. Some projects conducted in each style succeed, and some fail. That allows a process advocate to point to the process successes and the commitment failures and claim that process is the key to success. It allows the commitment advocate to do the same thing.
The issue that has fallen by the wayside while we've been debating process vs. commitment is so blatant that, like Edgar Allan Poe's purloined letter, it may simply have been so obvious that we have overlooked it. We should not be debating process vs. commitment; we should be debating competence vs. incompetence. The real difference is not which style is chosen, but what education, training, and understanding is brought to bear on the project. Rather than debating process vs. commitment, we should be looking for ways to raise the average level of developer and manager competence. That will improve our chances of success regardless of which development style we choose.