Experience vs. Tools? (was: Case Tools)

["John D. Mitchell" <johnm-advanced-java@non.net>]

FYI, Dana hit the wrong button and replied just to me rather than the list,
as intended.

>>>>> "Prof" == Prof Dana C Richardson, MS/CIS <drichard1@ivansmith.com> writes:
[...]
> Hi John and Folks: It's good to hear from you again John, and really,
> while I realize what people are saying about product advertising, most of
> the time, I listen in and check out what they are talking about.  Rarely
> does a product not do what they say, only usually, it is not what I
> needed<g>.

:-)

Alas, I'm finding more and more instances of what I think is at best
"aggressive" marketing and at worst, IMHO, outright fraud.  For example,
look at Oracle's "Unbreakable" campaign.  The ads and interviews with Larry
Ellison outright lie about their capabilities and track record.  Hmm... I
wonder if they make the same claims in Britain where the truth in
advertising laws are much stricter than here in the US?


> In terms of JAVA, my sense is that when you get good enough, tools pretty
> much become academic?

Interesting question!  The simple answer is, as usual, it depends. :-)

One of the reasons that tools (in the sense of modelling tools, high-level
debuggers, etc.) tend to be used less by some people as they grow in
experience and expertise is that the person has worked through the learning
process and has internalized more and more of the steps that previously
required working through externally.  This happens even more in
environments where the people are doing more or less the same things over
time (like old COBOL shops :-).

A counter-reason is that *good* (and *great*) tools become more important
over time but less helpful tools get ignored.  To be clear, I think that
the tool between our ears is by far the most important one.  Tools, in the
larger sense, are more critical so that we can get more leverage out of our
limited time and energies.  For some, concrete tools like IDEs,
computer-based modeling systems, etc. give them a boost.  For others, the
learning and using of those (oftem complex) tools just get in the way.  I'm
*not* saying that one is necessarily better than the other -- people just
need to play with enough stuff to learn what works for them.

One of the insidious downsides of our business is that people are
constantly looking for that mythical silver bullet and there are plenty of
people who are willing to sell you that belief.  This recurring (never
ending? :-) neurosis often leads to a more or less mindless rush to [insert
current fad here] without much, if any, thought about how the "new thing"
takes people away from what was working before.  The abrogation of
responsibility is, IMHO, one of the saddest things about our industry.

All of that said, I am a "tool" guy.  Perhaps I'm just "lazy" but I don't
want to keep doing the same, mechanical tasks over and over again when I
can automate them away.  I think there are way too many "tool luddites"
who, knee-jerkingly, won't ever really play with new tools, processes, etc.
They've learned their tricks already and just want to be left alone,
unchanging, indefinitely.

To try to bring this all back together, let me conclude with the fact that
I think the need is to create a balance between the various facts -- a
hybrid, if you will.  Train and use the tool between your ears for what it
excels at and complement that with computational and data tools that do
what they do best at (and learn what stuff should be done by which "tool"
:-).

Take care,
	John