On Tue, 31 May 2005 18:31:26 -0000, Robert Bonomi wrote:
In article ,
Dave Hinz wrote:
On Mon, 30 May 2005 14:23:17 -0000, Robert Bonomi
wrote:

*GRIN* I had a reputation of "If you want something done, hunt up Bonomi,
tell him it's 'impossible', and stay out of his hair for a couple of weeks."

Yeah, I used to do that too, until I twigged to the fact that people
were doing it intentionally to me. In college, (mumble) years ago, for
one of the fabrication classes the assignment was to make a 2-sided PCB
for a logic analyzer. "Can't be done single-sided, so don't even try".
Well, it wasn't _that_ tough to do (he forgot that components are also
jumpers), so I did it single-sided. He threatened me with an
incomplete, because he had specified double-sided...

That's when you hand over the layout for the other side, showing the
etched-away surrounds for all the holes *except* one, which is plated-through
from ground on the other side. And explain it's a start towards TEMPEST
protection. grin

Once again, I bow to the superiour deviousness. Deviousity.
Deveveiance. Whatever. Well played, Sir, is what I'm saying here.

Point is, the "It's impossible, you can't do it" is a tactic that people
to use to get people like you and me to work on something. Just so you
know. Not saying it's a problem, because those are usually the fun
projects anyway, but just something to be aware of.

*snort* I'd tumbled to _that_ by about fifth grade. Never got sucked into
anything unless I *wanted* to.

Just checking. Because I used to work with a really dumb smart guy who
still hadn't figured it out by age 30, and the sight of it dawning on
him as I explained what was going on, was _priceless_.

It's like you say, though -- for those who enjoy "problem solving" those are
the 'fun' projects. beats the h*ll out of doing routine support work
any day.

I don't mind the end-users so much now that I don't have to deal with
them, unless there's a "Sherlock Holmes" thing going on.

Then there was the day I made the 'mistake' of suggesting to the boss that
I might be able to improve the performance of our 'critical path' project
scheduling software (which was believed to be the fastest package then
in existence at that work). The boss was doubtful -- *very* doubtful in
fact -- giving me permission to try, but saying "I'm 'Thomas'". I found
out *later* that that program was his pride-and-joy, that he had sweated
blood optimizing it. Well, 4 days later, I'm back to see him. Requesting
an appointment with "Mr. Thomas". Puzzlement, he can't place any client
named "Thomas". then he remembers "Oh??" "Yup!" (with a *BIG* grin.)
And show him a quick-and-dirty that is more than *one*hundred*times* faster
than the production software. Disbelief was rampant, to put it mildly.
It took numerous runs, with radical changes to the data, before he'd believe
that it was calculating the entire solution each time.

Easy to step on someone's toes by making a radical change to something
they've been improving incrementally. Not that that stops me, but it's
understandable. I'm told that at times like that, there's this thing
called "tact" that I should try to use (shrug?) whatever that is.

Boss had a *real* problem with that piece of work. Terribly conflicted.
*SERIOUS* "pride of authorship" in the work he had done on the one side, and
cupidity on the other. On same-size networks, on roughly equivalent CPUs,
competing software would have run-times measured in hours. Our production
product gave you enough time to go have a somewhat leisurely cup of coffee
(i.e. the 10-15 minute range). My 'improved' version reduced the calculation
time to under 10 *seconds*. Not even enough time to stand up. The
'economic advantage' of _that_ was obvious to him.

Lovely, that!

It did get a little funny though -- the performance of the whole package when
I got through 'playing with it' was so high that there was a degree of
disbelief that it could "really" be doing what it claimed. One example;
IBM was building a new chip-fabrication plant on the East Coast. They had
a project-scheduling package that ran on their mid-range systems. the
complexity of the fab plant construction was exceeding the limits of
that software, _and_ taking almost an entire shift (8 hours) to calculate
a set of solutions. The general contractor was _insisting_ that they
user our service; so, eventually, an entire troop of IBM big-wigs came
out to our offices for the 'dog and pony show'.

That's normally a clear setup for a catastrophic setup during a demo.
As I'm sure you know.

We had already input
the data for their project into the system, to for the demonstration.
*I* am the "lucky" guy who gets to do the demo. I'm showing the date-entry
capabilities, review and editing stuff, etc. to establish that it's the
real project data, and then I do the 'generate solution' command.

....and here it comes...

12 seconds later, our computer says the solution is ready; so I'm showing
those who are paying attention that we do have a solution. "now, lets
change some data and re-solve", Doing this for several iterations, I push
the 'critical path' all around the project, leaving no doubt that actual
solutions are being generated. One final set of data edits, to remove
all the changes, and another solution generation, About this point, the
'top dog' pulls his awareness back to the demo -- 'how long till we see
some answers?' he asks. His disbelief, when *his* people insist to him
that it's =already= been done, and not just once, but _half_a_dozen_times_,
was a sight to see.

I _love_ that look.

The fact that he was
doing a binary search of a _disk_file_, and I was doing a linear search
of an array _in_memory_ had a *great* deal to do with my approach being
faster.

Still applies today. Index that database & keep the index in RAM.
Seems blisteringly obvious, but at the time, the field was still full of
surprises. What am I saying - it's still full of surprises...

The boss understood _programming_. I understood *systems*.

Right. The best possible improvement to the wrong solution still gives
you the wrong solution, in the end. In his case the fundamental design
flaw was masked by the improvements he was making to it.

By the time I got _done_ playing, performance was just over 3-orders of
magnitude better then the prior version -- on a 'maximum-size' network,
*and* the maximum-size of the project it could handle was _60%_ larger.
(this is a textbook "order n-squared" problem, so the total performance
differential was about 3.5 orders of magnitude. Not too shabby!

Fun stuff...