A recent discussion on Slashdot brought up the question of whether or not process is killing passion in the best software developers. The original post on which the Slashdot discussion is based made some good points, in particular that process easily runs amok and enslaves those whom it purports to help. The chorus of jeers from the Anonymous Cowards soon joined in to decry all manner of process. Some of it was funny, but much of it just made me sad.
However, with over a dozen years of software engineering under my belt, I can well attest to the blessings of properly-applied process. I'm not afraid to say that I can code circles around 90% of those who call themselves programmers. I spent most of my career coding without source control, much less unit tests or code review. However, I can honestly say that I rest easier with good processes backing me up. One commenter said TDD is a "crutch for insecure or unskilled coders", but I think TDD has been a godsend, enabling me to strike out far more boldly knowing that I actually have some assurance that as I make changes large and small, I know that: a) the things I'm trying not to change are not changing, and b) the impact of the changes I'm making have some semblance of what I intended.
The problem is not process, per se. The problem is the application of process without understanding or flexibility. Life Cycle of a Silver Bullet is a telling parable of process born of experience, process extrapolated, and process gone wrong. It all comes down to whether or not process is allowed to become unmoored from the principles it is instituted to embody. I can't recommend Lean Software Development: An Agile Toolkit enough for its steadfast emphasis on the value of process, but its unwavering commitment to underlying principles.
The problem with process is really a problem of mediocre managers trying to extract superior results from mediocre workers. Workers make mistakes. Managers try to find ways reduce mistakes, and hear about processes that have helped others accomplish just that. Mediocre workers can't recognize when the process is not helpful, much less hurtful, to productivity or quality. Mediocre managers force processes on those who can tell the difference, resulting in frustration in those who do the most and best work.
I am fortunate to work in an environment where the managers recognize the need to trust the "line workers", and are willing to invest to make sure they have only workers that can live up to that trust. And even in such a positive environment, we have discussions regarding which aspects of our processes are proving too onerous and which would save us heartache if they were beefed up. But because we have buy-in to these ideals across the organization, we can actually have these discussions and act on the results, whether they originate from the "top" or the "bottom". If you don't have as much to work with, you could try to find a new situation along these lines. (My company, for example.) But wherever you are, assuming the organization has some sense of responsiveness, you can champion the proper use of process, as a tool, not a slave-driver.