On Fri, February 16, 2007 4:13 pm, Stewart Stremler wrote: > begin quoting Lan Barnes as of Fri, Feb 16, 2007 at 11:13:12AM -0800: > As a friend of mine says: Hire good people. > > In the case of trying to blend with, say, XP, I'd say that you'd want > your coach to be someone with strong beliefs in the importance of the > benefits of "process", and who would have the ability to spend their > time making sure the path you describe is recorded, without dumping a > load of useless overhead on the whole team. > > (I bring up XP as that's the agile method I've read most about, and > the "task card" model just seems like the obvious place to hook in > to the traceability requirements or a more formal process system.) > > Unfortunately, this often is dismissed as "requiring heroes". :( >
I think this is the crux of the dilemma. We all know that good people can write good code and create good projects. The SEI specifically states that much of the canon of Really Good Stuff was created by CMM 1 level teams. The issue is how to turn the army of developers who are needed to create all the code that is as yet unwritten into "good people." Some try to make them good by prescribing process and some try to make them good by developing agility exercises. I use the word "army" purposefully because the military has the same problem. The Army takes millions of people from every strata of ability, intelligence, and background, and tries to make "good soldiers" out of all of them. Their success rate, considering the task, is stunning. Armies have been doing this for thousands of years, and they know what works best. But it's not perfect. Part of it is done by dumbing down what a "good soldier" is (not that many heroes), and part of it is done by searching for the right blend of process and independence. So it's not like this is a new challenge. But you can't shoot developers (god knows I've wanted to) for cowardice in the face of the algorithm. >> Does anyone have any experience in a shop where these things coexisted >> without abuse? Is there a book, a guru, a discipline that blends these >> impulses? > > 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". > Uh huh. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
