begin quoting Christian Seberino as of Fri, Feb 16, 2007 at 11:19:35PM -0800: > > On Fri, February 16, 2007 4:13 pm, Stewart Stremler wrote: > > My experience with process-oriented projects is that they get rigid and > > produce voluminious crap, and non-process-oriented projects either fall > > into chaos, or rise up to the challenge to deliver something worthwhile, > > but probably not repeatable in the sense of "can hand off to a team of > > mediocre programmers and expect anything nearly as good". > > I agree with you and this is curious. It sounds like what you are saying > is that systems engineering can't make up for individual deficiencies if > anything.
It can't absorb as much incompetence as we (seem to) expect it to. I think Andrew's post on this[1] is VERY good. I'm tempted to print it out and thumbtack it to my cube wall. > What is needed if I understand you correctly is great > programmers to be left virtually alone to do their thing. I don't think that's quite right either. I'd conclude something a little less ambitious -- what is needed is good people with complementing skillsets that can get along with each other, and some clear direction as to what the desired outcome is. Management's job is then removing people who drag down the team, and to remind the team what the desired outcome is when they get too far off-track, and to protect them from irrelevent crap from above (generally by saying "no", especially to salesweasels). Programmers *need* feedback, so leaving 'em alone is asking to get something that is almost completely unrelated to what you asked for. Plus, you don't want *all* that knowledge locked up in _one_ person's head -- you need to pull it out and get it down on paper! This is, after all, one of the neat features of being human: I can read someone else's thoughts when they're not in the same room, country, or century. > Sounds a lot > like an open source project doesn't it? Open-source doesn't have deadlines, often externalizes the cost, and does handle incompetence reasonably well by ignoring the contributions from the incompetent participants...and may or may not scratch a particular itch. This is not a good business model when you're paying people, even if we can learn from it. [1] The difference between hardware engineering/production and software engineering/programming. -- I don't context-switch well between coding and non-coding activities. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
