Originally posted by Dave Thomas:
Mark:
Great talk. I suspect it opened a lot of people's eyes.
I'd be interested to hear you give it and see where the emphasis lies. One of the things that's imprtant to me is the idea that a good project doesn't really have separate phases: requirements, design, coding, and so on, but is really just a continuum with different emphases at different times. In a way the feedback is defined not by what you do, but by where you get feedback on what you do.
I'd be interested to get your reaction to Pragmatic Programmer some time!
Dave
That's a good point, and one I'd agree with. I didn't really define I too much in my talk, how seperate or combned thsoe phases are. I sspect if anything I did suggest it might have been a little more seperate, and I'll tell you why. This talk is aimed at college kids. QA is a foreign concept, as are most of the other ideas. I think I slightly emphasized them as indepentent simply in order to get them thinking about it. So
testing isn't just, well, I was always compiling and plaing aorund with it when I was working on it. And documentation isn't, yeah, I made some notes as I went along. For groups with some exposure to "real" development, I probably do talk more about how they overlap.
I do mention, however, the concepts of waterfall and iterative work flows, and that the waterfall is very out of favor these days, for most projects. But I think even this concept is a bit advanced, for those who are just hearing that a project consists of more than just a single code-until-it-works phase. :-)
I'm planning on gettig a copy of your book. It looks terrific. The idea seems similar to my talk. My talk was on how things are done in industry, at a high level. You're book seems to be "here are all the industry best practices that you don't learn in school." I suspect it will very quickly get added to my recommended reading list for the talk. :-)
Thanks for your feedback.
--Mark
hershey@vaultus.com