Process vs. Development— a case of misplaced causality?

A note about this post: a few months back, we hired a replacement for the person who'd sort of become our de facto project manager. The new guy is a very friendly and competant fellow, just out of undergrad with lots of great ideas. Since I'm leaving the company in a few weeks, he asked me to write him some sort of feedback on how he's been doing. My immediate answer, of course, was that he was doing great, but he still wanted a more detailed response. 99% of what I wrote is irrelevant here (not to mention the fact that it's nobody's business but his), but there were a few paragraphs that it seemed might be interesting to others. I've made a few small edits, but please consider the rest of this to be an excerpt.

The only thing to watch out for— and this is nothing specific about you per se, but about the sort of job you happen to have picked up— try and ensure that nobody comes to think of the processes we employ to manage our development as a replacement for the development itself. I guess what I mean is that it's easy to get caught up with lots of forms, documents, and procedures, and then to forget what we're really trying to do— write software effectively and relatively painlessly. There is a very fine line between having well-designed procedures that help us coordinate our work, and having cumbersome and gratuitous "TPS Reports" that just get in the way. I don't think we're in any danger of crossing that line at the moment, but it is a constant threat, especially when one's systems work well. This may sound counter-intuitive, but bear with me here:

I think that there is frequently a problem of misplaced causality. Consider the following real-life, "ripped-from-the-headlines" scenario:

1. Development is in chaos, because nobody has time or procedures to organize their work and therefore can't get anything done;


2. Procedures to organize and schedule work are put in place, so devs can get back to work;


3. The product is improved.

One might look at the chain of events and decide that it was the procedures and schedules that improved the product, and therefore "more procedures → better product", especially if one didn't know much about writing software. The developers, however, would probably say that the improvement in the product came about because they were finally able to concentrate and do their job, since they were no longer constantly fending off millions of unorganized bug reports, feature requests, and conflicting demands. Who's right? Well, I'm inclined to say that the devs clearly have the right interpretation of events, but I'm definitely biased here. In my mind, this is a classic example of confusing correlation with causality.

So, basically, the best thing you can do is try and find the sweet spot where our development is organized and coordinated, but we're not having to spend more time every day dealing with the procedural overhead of our development process than actually writing code.