begin quoting Lan Barnes as of Tue, Dec 12, 2006 at 09:43:22AM -0800: > > On Tue, December 12, 2006 9:23 am, Stewart Stremler wrote: > > begin quoting Lan Barnes as of Tue, Dec 12, 2006 at 05:59:13AM -0800: > > -snip of the whole enchilada- > > I either have to agree with you or drive over there, strip to the waist, > and wrestle you into submission. > > Knowing my limitations, I agree.
Heh. I got a trick shoulder and no wind. I'd be easy for you. > Pray let me insert one teeny tiny thing about CMM. The CMM is emphirical. > It's a bunch of observations saying "when we observe organizations doing > these things, they have this kind of success." Alas, correlation does not necessarily correspond to causation. Good people can do a good job given just about any sort of methodolgy. The success isn't necessarily a result of the methodology, it might well be in spite of it. > I used to think it was pretty dingy until I got dragged into improving > stuff at a couple of places. Now I see it as an excellent road map ... a > template. Hm. I see it as a one-size-fits-all straitjacket. I'm wondering if we're approaching the same point from opposite sides. I don't advocate code-first-design-later, or no-comment-code, or any number of other things some of the more undisciplined idi^Wprogrammers advocate; after all, I want to consider source code to be like literature. I don't *like* puzzling out extremly clever tricks in someone else's code, just as I don't like puzzling out extremely boring documents written by someone who's only solved the problem in their head. > And BTW, it's not document-centric. It's process centric. I grant you, the > process is supposed to be "written" and followed, but that's fair because > people can't remember jack, and besides, personnel churns. Indeed. Writing Things Down Is Good. Turning a two-page HOWTO into a fifteen-page "artifact" destroys much of the value; sure, it *looks* professional, but it's less usable. :-/ And that's what I see every time the process-weenies get involved. (Well, almost every time. There was one guy who I thought was going to pull it off, but he left for other pastures. But if it takes a hero to make it happen right, how do you find a hero?) > But the process itself can be anything. "If development wants a build from > SCM, they put a flag in the flower pot and move it to the front of the > balcony" Which, really, is where I start to have problems. Doing things in a difficult, obnoxious, tedious, error-prone, but *documented* way isn't much of an improvement over something simple, easy, obvious, and automated way. Which isn't to say I'm against documentation. Or having standard ways of doing standard things. > (I wonder who'll spot that reference). (Not I -- all I can think of is the flowers thinking 'oh, no, not again') > I personally eschew formal documentation for all but the most formal of > processes. Instead I lean toward electronic communication that follows > process, and even better, fills a _real_ data base with transactions for > real-time status visibility and development of management metrics. A dedicated person to handle tracking the various features with minimal impact on those doing the work (except to guide them away from stupid or non-productive courses of action) is a wonderful thing. Taking up 70% of the day with meetings, reviews, filling in documents, responding to documents, preparing for reviews, creating documents, putting new documents into the appropriately documented location, and then moving other documents to other locations.... > Frankly, I don't ever want to have to count emails again to see how many > builds were requested/done in a given time period. But that's me. I'm afraid I don't see the value in such a metric.... unless the builds are extremly expensive and time-consuming. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
