Comments interspersed as noted by "RC:" and "JS:"
Rich AT EnglishLogicKernel DOT com
John F. Sowa wrote:
Sent: Saturday, January 16, 2010 10:16 AM
RC> Basically, companies don't do research on the stockholders'
JS: 3. They were successful in all three ways: they built
as an engineering project; they established
precise limits on
background radiation as an applied research
project; and as a
bonus, they made an unexpected scientific
won a Nobel Prize.
Tel spent telephone users' money (taxpayer money, not stockholder money) - the
money they had paid to the feds for supporting that monopoly in the first
place, for poor telephone service that should have been far advanced to what it
finally exploded into after deregulation.
RC: After Bell Tel was broken up and the monopoly stopped:
JS: 3. For the short term, telephone costs dropped by orders of
magnitude. But the Bell Labs' kind of
research dried up
-- at least in the US.
Those cutbacks partially justify Rich's comment.
But the result
of all of them is that the US now imports the kind of high
that they had always exported.
RC: Showing that the taxpayers supported a
sloppy monopoly that found ways to spend taxpayer money for their own research
purposes with absolutely no payout to the taxpayer-phone subscriber. Of
course the stockholders were overjoyed; they profited from the taxpayers' money
and the excessive phone call prices while they were busy doing
"research" in ways that didn't make it back to the taxpayer or the US economy.
JS: In summary, I'd replace Matthew's statement "There are at
kinds of thing here which you are trying to insist are only two"
with the following points:
1. There is a continuum between blue sky research, applied
and engineering. Sharp distinctions can
be misleading, especially
when they are made, after the fact, based on what
2. However, researchers do need guidance from management about
areas to explore and how much funding should
be alloted to each.
RC: management is only acting in concert
with stockholder interests when they set budgets, strategies and tactics for
3. The *best* guidance comes from enlightened managers who have
strong background in the technical fields, the
and the kind of R & D environment that
RC: I have only known two or three
managers in the last four decades, out of perhaps hundreds I have worked with,
who I think fit that description. One problem is that management is an
art, not an "enlightened" science. Very few managers can spend
the time and energy it takes to get their management work done, much less
staying technically up to date. With what time is left, they get advice
from their technical folk on staff. They don't make technology decisions
themselves if they are really managers. They mostly make budgeting,
scheduling and marketing decisions. The half life of a technical degree
is about five years. Those of us technologists who keep up to date have
to spend a lot of time reading new material, learning new problem areas, and so
on. We don't have time to manage people and still do the technical work
properly and professionally.
4. The *worst* kind of guidance comes from a frozen set of rules
based on what worked in the past and applied
bosses who have been promoted beyond their
level of competence.
(In military terms, this is equivalent to
fighting a new war
with the strategy and tactics developed for
the last war.)
RC: Agreed, but that is the only source
(past history) which has any validation at all for the company. You can PREDICT
what will happen due to changes in the market since the last war, but you won't
be any more ACCURATE at it than the generals who try to fight the last war, the
managers who use the documented history to debate with other managers what the
best strategy is, or the technologists who use the same solution they used last
time even when the situation is different.
RC: To put it another way, IMHO, rule
based systems are simply too simplistic to solve real world problems. They
constitute one component for reconfiguring the parts that change often. But
they need MORE than just the rule bases to get even barely satisfactory
results. That's why almost no enterprise system is done ENTIRELY in SQL. Instead,
the SQL queries are generated by software that handles the true complexity of
the application and maps it into storage structures which are appropriate for