It's the day before the grand opening but we need a firmware update. It'll be fine Before one can organise a piss-up in a brewery, one must first get the brewery started. Something a Register reader found difficult in today's Who, Me? Our tale takes us back to the '80s, the decade of fun. Our brave reader – let's call him "Gareth" – was heading up a team building a state-of-the-art Brewery Process Block. It …
Should really only be applied when.
1. It won’t run without them I.e. a serious bug
2 there is a massive security issue i.e. getting hacked
Otherwise test it properly before starting- but hindsight is wonderful…
Certainly not the night before a demonstration or high profile event.
If you need to do a fix then test it first, years ago I worked for a company building control machinery for factories, and one I remember if the factory got shut down as it made plastic sheeting it would have taken a week to get it back up and running, so that was approached very carefully. The problem was the heaters went off when the stop button was pressed so all the plastic solidified in the machine…
3) Before the system goes live, because you know that getting approval to update the firmware once it is in production is way harder.
You want the firmware as up to date as possible because when you call in for support on anything hardware related one of the first questions from the support engineer will be what firmware you are running. No matter what hardware issue you have, if the SE is able to dig up something in the bugfixes for firmware updates newer than yours that might conceivably impact it he will try to insist that needs to be done before treating it as an actual hardware issue. Even where you get them to table that and look at other things, they will keep coming back to that with greater and greater vigor the more things you rule out.
The closer to the latest firmware you are the less chance he can finger a potential firmware fix as the solution to your problem.
The mistake "Gareth" made was waiting until the day before the grand opening to do this. He should have done it right before they started their QA / acceptance testing, because you want as few (ideally zero) changes to the system from the time you start QA to the time you go live.
When we get the service engineers in to fit replacement parts to the robots, I have to pin one of them against a wall by the throat and tell them not to install updates to the OS/software as I've no wish to play "why the f does'nt this proven programming work any more?" for 4 hrs before finding out the system was updated the day before...
Update when the cell has'nt got 10 000 parts to make for delivery yesterday is the rule....
The Internet was quite common in business in the mid 1980s. I have business card binders (remember them?) from that era, nearly all of the cards contained in 'em have email addresses ... mostly joe@example.com addresses, with a few vestigial bangpaths. All of the latter were either Uni addresses, or research facilities attached to Unis and most of these also have a second @ address.
The article brings up memories from dfecades ago when I was designing system based on 68HC11. One chap in the team was not too impressed with BUFFALO and rewrote his own spiffy monitor. Loved working with it tho, must dig through boxes, must still have some cards left somewhere.
The cycle of UV-erasing was fun especially if you didn't pay attention to slight variations of how long was needed for erasure or what the programming voltage of that specific EPROM needed to be.
> I can remember cooking EPROMs at 200C on a baking tray in an oven for half an hour
Now I know what I was served the other day! I knew it couldn't be pastry, even if it was apparently still warm out of the oven.
(I just hope the machinery they installed the actual coffee cakes in wasn't mission-critical.)
At least it all went well in the end. On a smaller scale, years ago I and a colleague were to install a piece of software written by one of our junior developers on a remote system. Our main task was to inspect and service the hardware, but while we were there we would install this new gui tool as a freebie.
The night before in the office, the developer was doing some unnecessary tweaks to the software, we insisted they change nothing to the version we already had on the 3.5" floppy, ready to pick up early in the morning.
The next day, the hardware service went fine but when we went to install the new software ... it didn't work. Lots of head scratching and calls back to the office failed to fix it, so I and my colleague left, tails slightly between our legs and confident we knew on which junior developer's head our wrath was going to fall.
Back in the office we confronted the developer. "did you change anything?", "No".
"did you change anything?", "No".
"did you change anything?", "No".
"did you change anything?", "No".
"DID YOU CHANGE ANYTHING???", "well, yes, but that shouldn't have made any difference!"
We went back the next day with the working version.
I've always emphasized my desire for the correct answer the first time by an application of a suitably overpowered ShockyStick(TM). It tends to cut down on the repetition when the person being interrogated finds themselves writhing on the floor in an uncontrollable spasm of pain.
"Let me ask one last time. Did. You. Change. Anything?" *SparkZap SparkZap* (Screams for mercy) "Thank you for your prompt & truthful reply. Please remember this lesson for future reduction of unnecessary pain, yes?" (Mewling from the floor) "Very good. Byebye now."
*Happy sigh of torture memories from days of olde*
In my days as a Unisys DBA supporting a CODASYL database the following conversation happened at least once a month.
"The database broken!"
Not as far as I know, it isn't. Why do you think it is?
"Well I know I stored such-and-such a record on the database yesterday, and now it says the record is not on file!"
Did you delete the record?
"Of course not!"
Did someone else do that?"
"No-one would touch my test data!"
Lucky you. What did you change in the program?
"Nothing!"
So if I do an @PRT,S of all the library elements, the dates will all be at least a week old?
"Well, I DID change something in a subroutine, but it wouldn't effect the program!"
Let me guess. You added a few columns to your subroutine's DATA DIVISION.
"er ..."
You have displaced your calc keys by however many characters in your LINKAGE SECTION. You are chopping the front of the calc key off. That is why your record is not found, assuming your "no-one would touch" assertion is valid.
"So ..."
So you need to go fix your program so all the bits match the one bit you changed.
It got so bad at one point that when someone offered me a listing of their botch job and insisted the database was broken I offered a wager, that if I went through their code and found no cause for concern I would give them a crisp ten dollar bill, but for every protential problem I found they would give me one dollar. I pointed out that before they took the bet I could see I was five dollars up on the deal from what I could see on the first two pages.
That and the old "Your record counts say there are 66 thousand records on the database, but I can only find 60" thing. How many times did I have to tell them to re-establish currency when switching from "in set" to "in area" semantics? Well, I quit before an answer to that was available.
Been a nuts 'n' bolts engineer for decades, everyone I have ever worked with aside from the newly qualified, have lived by the code of ' if it ain't broke don't fix it'.
We always used to tell the newbs, 'You are the most qualified here because you have been taught all the latest stuff', hard to enunciate when your tongue is firmly in your cheek.
The newbs believed us and always thought they knew better until they realised they didn't.
... ask me how I manage to purchase heavy equipment for pennies on the dollar. A couple of quick bearing changes, some light welding, seals and the odd valve replaced, all fluids & filters changed, followed by properly adjusting all moving parts, giving it a bath and some appropriate touch-up paint and I can usually flip them for four or five times what I paid, including parts. Sometimes quite a bit more. It's more than enough to pay for my steam engine fetish.
We always used to tell the newbs, 'You are the most qualified here because you have been taught all the latest stuff', hard to enunciate when your tongue is firmly in your cheek.
Which is also why the newbs got to visit the CEO's home on Christmas Day for to setup the new computer for his children.
""if it works, 'enhance' it until it stops.""
Many years ago an old timer explained how a domestic radio was designed.
First of all everything was done according to best design practice for decoupling etc. Then components were selectively removed until it stopped working. Replacing that component established the economic production design.
There was a standard piece of advice if your HF transmitter PA had parasitic oscillations. "Add a parasitic stopper**. Unless you already have one - in which case remove it."
**this was a few turns of wire wound on a resistor body. It was in series with the power feed - close to the PA anode cap.
And good days for releasing life changing, Great Games altering news are over the Xmas period through to the New Year, for before anyone realises it, IT and AI will have realised it and moved on further into other stupendous fields in support of the latter which has morphed and now becomes recognised as the former.
Do you yourself discover that normally to be the case during such times of widespread merriment and jovial celebration, thus to find out the majority are at the mercy of a very select few one has no idea of?
Of course I know a few ones control many. Been doing it myself since 16, I believe.
The news changing game pause may be related to a certain inquiry into who is behind the phone not-so-legal inspection/infection - as he is attached to many others, and considers me a cockroach which never dies ( despite all the attempts to kill such a person ).
Alliances are formalized with rings, work and joy at the sea.
After the removal of the last tooth-microchip of MkUltrAI project, Elon, Bill and Zuck will suffer with lack of new ideas for projects. Take good care of them.
Selling to others the tooth-microchip of MkUltrAI is an international game-changer, isn't it?
With a functioning sample, even better, so tests can be done and all parties will be happy.
I am pretty sure I will be alive due to manly alliances/partnerships/proposals in place. I am a man of my word, unlike others.
I thought so speaking as someone who owned 2.5 of them
A500
A1200
A1200 with 68030 processor card - it was still the same host machine but with a massively faster processor doing the work.
I had to swap to Windows when the software support died after commodore went bust.
This is the rite of passage that nearly every engineer (and many others, including their PHBs) must go through _at least once_ as they learn how to function in the real world. Some people may need more than one lesson.
"Experience is a hard teacher because she gives the test first, the lesson afterward."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
