|Perl@Work#2 - Graphics at BHP|
|The BHP Way|
|Leaving and Returning|
|Missing Data, Staff|
|The Other Package|
|Silicon Graphics and their IRIX|
|Perl to the Rescue|
|Perl and the Future|
|A Road Untravelled|
In January 1997 I started a 3 month contract at BHP Research Labs, in Melbourne. BHP is now BHP Billington, a huge Australian mining company.
Huge means things like when they owned a mine in New Guinea, it was dumping 100 million tons of overburden into the local river, per year, in order to uncover the ore BHP wanted.
The immediate problem, though, was that a staff member had written a graphics program, to display mining survey data, of which more later. The problem was that his program was incapable of displaying anything. That's right - not a pixel appeared on the screen. Management could tell something was wrong.
Some background: During the original Star Wars period under the American President With Alzheimer's Before His Election (yes, Reagan) they had devised a plan to track Russian submarines. This involved firing a radar signal down from an aeroplane, looking for a large, metal thing under the water.
If the transmitter is a submarine, the radar is fired horizontally, of course, but ideally, this time, the plane would be above the water...
Anyway, the idea is that the signal induces an electric current in the target, which broadcasts a faint signal of its own. The problem is detecting that signal. And the solution is to tow a tiny glider behind the plane, for 2 reasons: To get the receiving equipment away from the metallic bulk of the plane itself, and to minimize the amount of metal in the glider's body.
So, this may or may not have worked in practice, but BHP bought rights to the technology, on the theory they could fire radar into the ground, looking for metallic ore bodies. Clever, huh?
The project manager I worked under, an extremely nice man, was a Chemical Engineer by training, which is to be expected in such an environment, since BHP - like many companies - did not think in terms of a project manager dedicated to software projects, or with specialized training in this field.
This is a common problem, and I often tell young people - when discussing careers - that Australia needs large numbers of competent project leaders with expertise in software work.
Anyway, while I was brought in to add C++ knowledge, the management had, without telling me, also begun investigation of pre-written graphics packages.
So, I'm working away, and soon get simple graphs appearing, which was cause for some small scale celebration.
The code was horrendous however, because the author knew much less that I did about writing programs, and was totally averse to design. All his decisions of how to structure the code, and what to write exactly, were spur-of-the-moment decisions. I kept the project manager informed of this, although his background effectively made it impossible for him to be sure I knew what I was talking about. He did realize, at least, that the staff member was effectively non-functional.
This was still in the days when software was seen, at least at BHP, as something just tacked on to project, to help manage the data.
I should mention that ore bodies lie in the ground in a wide array of configurations, depending on tectonic folding of the land, and so on, so that the ore 'body' might in fact be a comparatively thin sheet, and one which is often wavey and inclined to the surface, and perhaps both.
Further, the radar receiver struggles with the metal in the glider's body, so readings are often missing. And here we're talking about equipment which records quite a few channels simultaneously.
The result, stored on tape, was IIRC up to 40 Gb of data in a single file, larger that the disk drives of the day. So BHP had to buy a extremely expensive disk drive controller which could make 2 drives look to the software as one drive.
Natually, BHP owns mining leases all over the world, and the terrain over which the plane must fly influences the ease with which data is captured. After all, the ores are under no obligation to place themselves under nice, flat, plains.
At the end of the 3 month contract I left, but very little progress had been made. There was no talk of me staying on.
I can't remember how long it was till my next contract, perhaps just Friday to Monday.
That job was with Tattersall's, and one-time gambling monopoly here in Victoria.
We (another guy started at the same time) had no desks, computers or phones, so we had to sit in the broard room, with 1 slightly faulty PC and a phone.
I was told to wait until a desk was free, and to log on using someone else's username, and patch code in his directory. There was of course no source code control in use. They had one installed, but didn't use it.
They were so disorganized I resigned at 11:00 am on the 2nd day.
The manager kindly accepted my resignation, acknowledging it was better not to force me to serve out a month's notice when unhappy.
In the afternoon after leaving, I contacted the personnel agency who found me the original job at BHP, and amazingly started back there the next day.
I didn't expect Tattersall's to pay for my 2 days' time.
So, the interface has to allow channel selection, and has to handle any amount of missing data.
I was not capable of making the given code work, and another very, very clever C++ programmer, Matt Henderson, was brought in to help. He did the fundamental design on a new program, with some help from me, after management accepted that the first program had to be scrapped.
The guy who had written that code was let go (or as they say, given an opportunity to seek work elsewhere), leaving us with no legacy code to cripple progress.
A graphics package was bought, and the code we worked on became what today we'd call a plug-in, which dealt with the specifics of BHP's data.
The support guy for this package lived, and received some training, in Sydney, so it was big day every so often when he'd come to Melbourne to help train us. He had just started using this package when we did, so he struggled, but at least was being given enough training to (just) do the job.
Since SG had a great reputation for graphics, their workstations were the standard among the various branches of BHP, which included South Africa and London and Boston.
In reality, their graphics cards were what carried their reputation, but they also build their own machines, and wrote (perhaps unfortunately) a version of Unix called IRIX.
Then came their great (joke) upgrade from 16- to 32-bit code, which of course was accompanied by months, and in some cases, years of pain, just as it had been for all the other computer companies which went through the same process. I'd been through it before, but SG were always years behind (oh, all right, apart from their snazzy graphic cards).
With the graphs appearing, and management happy, I moved on to writing the code to install everthing.
And for that I choose Perl. The program manager accepted that I was a better judge than he of the choice of language, so my decision was approved of immediately.
By this time we had a CD burner on an SG machine, so I created a giant tgz file (I forget now, probably about 120 Mg), and was happy with test installation results.
BHP did not trust their internal FTP to England, and since the project was deemed to be giving them such a crucial edge over other mining companies, the CD was carried in a briefcase to London.
Installation went perfectly, but I was not told about that until weeks later.
In all, the 3 month contract lasted 2 years and 3 months.
Also, I was able to monitor the Perl newsgroups from work, so became aware of the huge group of programmers using Perl, and gained some insight into the vast number of ways it could be put to use.
Many were the times I saw code which did things I had not dreamed of.
The result was a conviction that Perl was a superb language, probably more flexible than any other, and that this was probably due to having been designed by a linguist rather than a committee.
Ten years later I now pity the people using Java, for example, and despair that such a propaganda job was done with Java that for the (estimated) one million Perl programmers, there are a staggering three million with the Java monkey on their backs.
And yes, I do realize all the big consulting companies choose Java with psychopathic cynicism, precisely because it started out big, slow, and has a syntax which makes Cobol look good.
Sigh - such is life. But at least I did no go down that path.
Home page: http://savage.net.au/index.html
Australian copyright © 2009, Ron Savage. All rights reserved.
All Programs of mine are 'OSI Certified Open Source Software'; you can redistribute them and/or modify them under the terms of The Artistic License, a copy of which is available at: http://www.opensource.org/licenses/index.html
|Top of page|