A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Knight turned the machine off and on.

The machine worked.

Oh Jake you sweet, summer child...

Your inexperience with Windows is showing here. Power-cycling with no understanding of what is going wrong is how 90% of the issues I have with my computer are fixed!

Although I am reminded of all the times that stuff starts magically working as soon as the relevant expert is watching from over somebody's shoulder.

Happy memories of when I did desktop support & would shlep across site or to a different site only to hear a variation of:

Me: "Can you show me the problem please?"

User: "I open this & select here & then click this button and then... Oh, it's working now"

The big problem there is usually that previously they were either opening the wrong thing, selecting the wrong thing or not selecting anything, clicking the wrong button or all of the above.

Users are idiots. (And I can say that confidently because most of the time, I'm a (L)user)

In my experience these 'issues' are normally down to 10 problems.

P.I.C.N.I.C errors

1 D 10 T problems.

In about 1% of cases, I actually had to fix something instead of provide implicit instructions on how to use something properly.... for the 50th time to the same dept.

I've probably recounted the tale previously of a 486 based HP SCO Unix box I managed for a while. I was on holiday but had taken the company "mobile" (a car phone attached to a blooming great battery pack) just in case. Half way through I got a call, the backup tape wasn't ejecting, what should they do?

I balanced the risks and decided the best thing was to wait until my return a few days later and I'd sort it.

That apparently wasn't good enough, they summoned an engineer, against my instructions and without telling me, from the parent company's PC support people. He travelled the 150 miles or so from the South Coast, turned the box off without any thought of a controlled shutdown, manually ejected the tape then turned the box back on. When it wouldn't boot again he ran away after saying, "Oh shit!" or words to that effect.

It took a few days to completely wipe the file system, reinstall and reconfigure Unix then restore the last good backup tape which by then was over a week old. Had it been my own fault I'd have pulled an overnighter and got it back within 24 hours but as it was down to senior management I wasn't going to rush (you can always find an excuse to go home* such as running a disk check that will take several hours).

*A DEC engineer once used a thunderstorm as his reason for not continuing to fix a fault, I didn't argue as I wanted to go home too.

Arnie reminds me of one or two PC engineers I've had the misfortune to encounter in the past. They can't be bargained with. They can't be reasoned with. They don't feel pity, or remorse, or fear. And they absolutely will not stop... ever, until the server is dead...

A DEC engineer once used a thunderstorm as his reason for not continuing to fix a fault

Well trying to fix faults when there is a thunderstorm lurking about can be pretty shocking.

Love the description of a thunderstorm lurking, as if they hang about on street corners like Teenagers or something..:)

>Love the description of a thunderstorm lurking, as if they hang about on street corners like Teenagers or something..:)

This last weekend they certainly seemed to. We had at least 3 including one really spectacular one on Saturday night.

Ah, too bad. Seems the "blame meeting" converged rapidly onto him ...

Probably correctly from my reading of it?

Maybe a bit harsh.

No, not really.

Doing anything to a box you know nothing of, especially in a server room, is a big no-no.

No way of knowing if the manager came back, or brought his nephew in again.

I was expecting a network problem for Arnie because it hadn't been terminated properly...

Let's see: unexpected hardware, unfamiliar software, not the system you installed ...

Use the pink paint, deploy the SEP field and GTFO as rapidly as possible.

Unfortunately, they didn't apply BistroMath to settle the account.

Ah yes, the joy of software that runs as an application on a server. Frequently we'd have to support customers who had installed updates (go them!) but failed to complete the process by logging the server back on to the required account. As regulated customers the lack of records could prove expensive..

Someone told me that they worked on a project where the development was done in one country and the testing was done in a different country. Due to the executive announcing the customer date before development was quarter done, it was pretty chaotic and corners were cut.

The installation team followed the process of getting a clean machine and trying to install the product. It always failed. They executive blew his top and sent his top expert to "SHOW THE INSTALLATION TEAM HOW TO DO IT". The guy got off the plane, went directly to the lab and tried to install it. It didn't install. He spoke to the development team - they hadn't installed it either - they just replaced the binaries every day and were careful not to turn the machine off. I think no one had actually been given the job of writing the installation process, people just used some scrappy notes.

In the development team, because the project was running late, they were asked to resize the work. Now they knew what they were working on, instead of some chart-ware design, they resized it properly - and said it had gone up from 3 months work to 9 months work. The executive blew his top as this was not the answer he wanted to hear. He wanted them to resize it again! but someone told him - every time they resize it - it costs 2 weeks work. Do you really want to ask them?

Yes, because obviously if it didn't give the proper result the first time, Shirly it will the next time, right ?

Ah, manglement. They deserve every meme they get.

It's not about results, it's about power.

(And money. Money is power.)

I was working on an installation in Germany of a product from the US of Texas.

We could not get it to correctly configure for our environment. I edited, tweaked, wiped, reinstalled.

Customer was getting angry at delays, Vendor was showing how it worked on their Dev environment and blaming me.

We had a marathon session where I reinstalled and configured from scratch with their team remotely watching.

They agreed I had done everything right.

3 days week later they rebuild their code, issued a patch release and it worked.

Many drinks later with a friend in the EU branch I found out why - they'd HARDCODED the path to the config file in their dev environment.

development team - they hadn't installed it either - they just replaced the binaries every day and were careful not to turn the machine off.

Oh yes, we've all been there.

That's why our QA engineer always started a new test run of a new version by installing the product exactly as the documentation said, no matter how well she knew the product by then. The result was often bug reports filled against product and/or docs, but we rarely had issues from customers.

At two or three companies I managed to get a process for installing a development environment for new developers.

It started with a printed sheet of paper. The paper said “follow the instructions on this paper. If they don’t work, then ask for help, and change the instructions so they work”. That was needed because what’s on a brand new machine would change over time.

And one part of the instructions was where to find the instructions as an editable document so the new guy could update them.

I was sent to a remote site to install some new software many years ago. The senior engineer had mentioned (with a grin) that although he had never been to the site, the younger lads in IT were always popping in there to fix 'printer problems'. The printer seemed absolutely fine, but oddly enough the young lady who worked there was absolutely stunning.