My experience has been that well thought out and planned projects go much faster and are far more robust then the "let's get on with it" approach.

One of my first, real world examples of this was the year after I graduated college while working with the guy who introduced me to the empeg. We had a large application that had to interface with other applications via UDP on a network, so we wrote a class to wrap this functionality up and make it easy to integrate into all of our applications. So we wrote it, the thing grew, and we had no end of trouble with it. Finally, out of sheer frustration he and I sat in the main conference room for a week and completely redesigned the thing. We didn’t code or even touch a computer. In fact, our boss came in and griped at us to “get on with it”. At the end of the week, all we had for our efforts were a bunch of diagrams of every aspect of this class and what it needed to do.

Then I started coding, and it took me about two weeks. No questions, no issues, and it worked the FIRST TIME (or really close to it anyway). We inserted this class into all of our code and didn’t touch it for the rest of the project. It was faster, more robust, and easier to work with. And get this: the total development time including our design was 3 weeks! Originally I think it took me 2 months to code the thing.

To be fair, we probably had a better idea of what we needed the second time around, but even at that we could have planned and executed more quickly than we originally did. So my lesson was learned, and I’ve operated the same ever since. And the results, I almost always start of slower than people expected but I ALWAYS surpass time estimates, even while spending entirely too much time reading posts on this bbs! I am a HUGE fan of process in software development, as long as it’s done right and adds to effeciency.

Of course, you can take this whole thing overboard, and that’s what I think a lot of people do. We did NOT accomplish a great design by having meetings. We did NOT accomplish a great design by spending time filing out meaningless reports that aren’t used for anything important.

I DO think meetings with clients and users are important, because those relationships are key. They have to know you’re being successful for it to matter, and you have to make sure that your task is hitting the right objectives. BUT, I do not think this is the task of engineers. A good project manager should be able to shield as many of his people as possible from this kind of overhead and engender trust so that when a meeting IS necessary for the team, they know it will be efficient and not a waste of their time.

Of course, ask me what I think in 6 months and we’ll see. This is about my fourth task to “manage”, but it’s the first on which I won’t actually be working. We’ll just have to wait and see if I join the “dark side” or not!