begin quoting Lan Barnes as of Tue, Dec 12, 2006 at 05:59:13AM -0800:
>
[snip]
> It's a little more than he-said-she-said. Advocates of a methodology can
> always say they're the distillation of the best of what has come before,
> but they really shouldn't redifine what came before, especially to shine a
> favorable light on themselves.
Indeed.
> Now it is quite true that SEI says that organizations do not vault from
> one level to another, but rather adopt (and lag behind) bits and pieces of
> the next step up, hold on to bad prcatices from the step below.
>
> But the "vertical slice" is just a little too pat for this little black duck.
It seems an appropriate metaphor in response to the whole "levels"
thing. It's not as if organizations "level up", as in a game; or
that all problems lend themselves to the same approach, or that there's
really any way to get good, high-quality, robust programs from a bunch
of incompetents.
> Here's why. IMHO the developer-centric fads ^H^H^H^H ... umm,
> innovations? ... usually suffer from developers wanting to do the parts
> they think are fun and skip the parts they don't enjoy. I know that's what
> I want to do.
And CMMI is document-centric, and thus suffers from the problem of all
-centric "innovations". Design is fun, code is hard, it's much easier
to tell the damn programmers exactly what to do and to content oneself
with powerpoint and word and document tracking and review meetings and
requirements tracking....
> Analysis is a bore. Comments (unless they're clever and snarky) are too
> much typing. I spit on your meeting -- I want to _code_!
Analysis is a bore for some people. There are lots of people who can't
really code very well, but who can talk and pump out MSWord documents
and MSPowerPoint presentations, generate meetings, reviews, and
process... and they *love* Analysis. They get all sorts of artifacts
that indicate they're doing a lot of work, but it's really of very
little value.
You want some, but we get back to that "moderation" thing. And I agree
that some folks don't want any -- they want to jump straight into code,
which I agree is bad (and XP doesn't allow for that either, despite
claims otherwise).
And as for comments, well, great comments are hard, and good comments
require effort; but writing a bunch of crappy comments and dropping in
a bunch of templates merely improve the metric (comments::code) without
adding value doesn't help.
(I'm often considered a comment nazi -- but I also strip out useless
comments whenever I see 'em. Comments should _add_ value, or they
shouldn't be there: rewrite 'em or rip 'em out.)
> Now I think RAD (which is about as far as I've evolved) is great, and I
> use some of its principles when I can. But properly done, it has as much
> analysis and documentation as, well, waterfall. OK, maybe not _that_ bad,
> but you get my point, I hope.
I'm trying. :)
> So I break out in a rash when I hear gushing (not from this list,
> necessarily, but from people I work with) about the latest Cub Scout
> methodology, because in 6 months when the auditors from the FDA come in,
> I'm one of the guys who'll have to clean up the mess.
I don't react well to gushing myself. Everything as a tradeoff, and no
one thing is best everywhere.
Currently, I'm hearing gushing (not from this list) about CMMI. I'm
not reacting well to the kneejerk "well, if we had a process, we
wouldn't have that problem" response to every issue. I'm working
with code for which there is a ton of "CMM" documentation and very
little useful detail.
> So when the XP guys rapsodize about how they can go twice as fast and have
> half the defects and they don't need to leave behind no stinkin'
> deliverables, I get a knot in my stomach and wonder what makes them so
> different from all the other bags of magic beans I've seen before.
>
> Is that so bad of me?
No, but...
I think you're listening to guys who claim to be advocating XP, but who
haven't bothered to read any of the XP books. XP leaves behind a lot of
artifacts -- story cards, task cards, test suites, etc. -- and, presumably,
working code. These make for nice deliverables (with a little polish,
perhaps).
I'd rather have those than a gazillion documents that are impossible to
read, code laden with useless comments ('cuz I already know what ++ does),
and a stovepipe application that eschews the simple solution at every
turn.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
