× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Re(2): The future of computing
  • From: "Chris Rehm" <javadisciple@xxxxxxxxxxxxx>
  • Date: Thu, 12 Jul 2001 11:51:23 -0700

Hi Mike,

----- Original Message -----
From: "Mike Naughton" <mnaughton@juddwire.com>
To: <MIDRANGE-L@midrange.com>
Sent: Thursday, July 12, 2001 9:02 AM
Subject: Re(2): The future of computing


> Chris,
>
> IMHO, you are making a good point & then carrying it too far. If you are

Okay.

> But if you are saying that that it is somehow unprofessionally lazy or
> irresponsible not to familiarize ourselves with every product out there
> before making a recommendation (because that's the only way we can pick
> the "best"), then I think you're being unrealistic. Sure, it would be nice
> if we all did that, but there are an awful lot of products, and it takes
> time and money to learn enough to be useful. Note: I'm not saying we
> shouldn't try -- and keep trying -- to do a better job; just that darned
> few of us will every be able to be as completely thorough as this ideal
> calls for.

Well, that isn't what I was saying. I don't think it a requirement that
everyone become familiar with every product. These days, it probably isn't
even plausible to know the names of all the products in the marketplace.

But if a manager is told that the plan is to deploy Notes enterprise wide
and his only research is to see how much more disk space his AS/400s need
etc. to roll it out, he hasn't really responded to the needs of his company.
I use Notes because it so happens that I know IBM is having a lot of trouble
supporting big Notes users on 400s. It turns out that some very big users
need to deploy on NT instead. I want to point this out so that I can confuse
you into not thinking I am an AS/400 bigot.

> Finally, if you're faulting us for our "willingness . . . to install a
> solution . . . simply because that is the solution [we] are familiar
> with", then I have to ask: are you really recommending that we install
> solutions that we are _not_ familiar with? Going back to my two previous
> points, if we are are indeed acting in good faith, and we don't have the
> resources (mental, physical, financial, temporal) to know all the answers,
> aren't we better off putting in a solution that we know will work rather
> than going with something that
> a-lot-of-people-say-is-better-but-we-don't-personally-know-it?

I am recommending that you be willing to accept that the solution you know
best might not be the best choice. If it isn't, then I think that (as tough
as it is) we need to be able to respond with "I don't think this is the best
choice." Of course, there will often be overriding concerns. For instance,
if you are an AS/400 only shop and the best choice might be NT but you don't
want to add the cost of supporting NT, then that might make the AS/400 still
the best choice in that instance.

But if a lot of people say, "Man, this Linux server I've been using for our
web site is the most stable, rock solid web server I've ever seen." then I
think it is really a requirement that we'd investigate the truth to that
before rolling out 400 based, or NT based, web servers.

> This reminds me of the "best vs 'good enough'" thread of a few months ago
> -- I firmly believe that in the real world, where different priorities
> usually compete for inadequate resources, "good enough" is often precisely
> that, and trying to turn "good enough" into "best" in one area means not
> spending the effort turning "bad" into "good enough" somewhere else.
> Results are usually judged not on one single area, but on the balance of
> various factors (which may be competing).

I kind of got lost in this paragraph. But here is the deal, "best" is
subjective, right? Each situation might have different factors make a choice
good or bad.


> JMHO. For the record, though, I would love to be paid well to do nothing
> but research all possible tools for doing my job (business application
> programming) -- making recommendations, writing programs, or otherwise
> producing billable results only when I felt absolutely sure that I
> thoroughly understood everything I needed to understand before doing so.
> If you hear of such a job, please let me know (privately, please -- I
> wouldn't want to distract anyone else on the list ;-)). In the meantime, I
> expect I'll keep doing what I'm doing now: trying hard to keep up with new
> tools and technologies while producing enough actual results to convince
> my employer I'm worth the expense.

Mike, as a Senior P/A, you may not be often charged with making such
choices. When someone does approach you about deploying a particular
project, supposedly this sort of decision process has already taken place.
But on those occasions when you might be asked to participate in such a
decision, are you willing to speak up if you feel there might be a better
solution?

I would suspect so. I am not trying to say that anyone here is busy lying to
keep their job.

If I may, I'd like to point out an area where this problem causes big
problems in our industry.

An example I am familiar with. In a shop I was in we deployed an OS/2 server
to deal with some issues. No big deal. But the problem came in when the PC
guys volunteered to do every little thing that came down the pipe. For every
request it was, "Oh, we can do that!" Corporate management really like the
idea that every idea was being implemented in a big hurry and the OS/2 stuff
really looked shiny from the outside. But in a short time 80% of our time in
MIS was trying to make the OS/2 server into a host.

If the President wanted a new commission tracking system, some guy with an
SQL front end would volunteer because he could whip up a great report in no
time. But then came the trouble of connecting it to the real data, blah blah
blah.

Over time there was a heck of a train wreck over all this. The OS/2 servers
were yanked and communications issues were pushed to the 400 which increased
the workload there and required upgrade. Almost all production work was
stopped for a while. It was ugly.

Anyway, the problem becomes (IMO) that a shop will not want to open that
door in the first place. A guy should be willing to, and able to, deploy a
solution that matches the problem. Some shops are great about this. I got
some of my first Unix training in a shop that had AS/400s tied to Unix boxes
along with a variety of other gear. Same with Novell.

And honestly, I didn't mean to turn this whole thing into a big lecture
drawn out discussion of a boring worked over topic. But I really don't like
being treated that I'm just an OS bigot because I notice that some things
being marketed aren't as good as other things being marketed. I consider it
my job to investigate those things.

In my old age I've decided I just don't want to be politically correct any
more.

> Mike Naughton
> Senior Programmer/Analyst
> Judd Wire, Inc.
> 124 Turnpike Road
> Turners Falls, MA  01376
> 413-863-4357 x444
> mnaughton@juddwire.com

Chris Rehm
javadisciple@earthlink.net
If you believe that the best technology wins the
marketplace, you haven't been paying attention.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.