PDA

View Full Version : Many things are easier to break than to fix. [Craig Arko]


NovaScotian
02-28-2008, 11:25 AM
In another thread, a comment by Craig Arko was quoted: Many things are easier to break than to fix. (http://forums.macosxhints.com/showpost.php?p=438664&postcount=9). As I stared at that simple statement, I realized how relevant it is to this group; profound, even. :), because many of us are professional problem solvers.

Having run an engineering consultancy for many years, I can state unequivocally that much of my work as an outside expert was centered on fixing what the inside experts had broken while trying to fix a problem, and then solving the problem they hadn't known was causing the symptoms. The key in doing this successfully, of course, is recognizing the problem instead of focussing on the symptoms.

I'll give a strange example in the hope of stirring others to do the same in what could be an interesting thread. Many years ago, I was called in by a company that built high-speed printing press splicers. A splicer is a device at the infeed end of a press that joins the leading end of a new roll of feed stock to the trailing end of an expiring roll and chops off the expiring tail. The press can then continue to run at top speed with an uninterrupted feed of whatever it's printing on because starting and stopping a press gets it all out of whack. The splice itself is marked with a fluorescent dye so it can be removed from the output at the other end of the press.

The client was having problems with the cutter that chopped off the tail of the expiring web. They had a new design that didn't work properly. The idea was a cylinder with a slot (closed by "lips") down the full length of its shell so that an extension of a free piston inside the cylinder could stick out through the lips. The extension carried a pair of razor blades facing in both directions. When the cylinder was pressurized, the blade flashed across the web and parted it.

It didn't work, because the paper either tore out ahead of the blade or bunched up ahead of it (the way paper sometimes does when you're pushing scissors through a sheet without working the blades) depending on the pressure they applied to the cylinder. Question: how can we control the pressure to get a smooth cut?

Answer: you never can -- the method will never work so abandon it. How did I know? Paper tears at the speed of sound in the sheet. The transverse speed of sound in a running web is a strong function of a lot of unknowns. If the knife runs below the speed of sound in the web, the slit will tear ahead of it. If the knife runs above the speed of sound in the web, there will be a "shock wave" -- the bunching up of paper that couldn't get out of the way, that didn't "know" the knife was coming.

Saved the company a lot of money beating a dead horse, and got steady work from them on several other jobs.

Any other takers?

Gnarlodious
02-28-2008, 12:35 PM
Interesting post. I'm not going to talk about computers, because I work with them all day long. But this example applies to all dynamic systems.

You see it happen a lot in cars. People tend to ignore small breakdowns, which soon expand to large problems. By that time, the malfunction has infected related components. Thinking about components results in entropic interactions in the entire system. In many cases, the dynamics are the malfunction and not even the components.

For some reason it is hard for people to recognize a dynamic malfunction. Engineers are used to it, but not civilians. This is probably because western society is based on the "worship of graven images", to put it in biblical terms. In other words, we are materially oriented people.

Objects, not behavior, are what we experience as real. This is one reason some people see technology as evil, ruining the peaceful existence of agrarian society. This perception places a real-world limit on the adoption of technology, and explains such anti-technology movements such as Luddism and Sentimentalism.

aehurst
02-28-2008, 02:28 PM
Going to the core of the problem is always the hard part, and most will simply stop analysis at the obvious symptom.

I worked for a CEO type who prided himself in the "Art of Pinging." Question after question until he had gotten what he wanted. One example.

An accident at the job site.... At the next staff meeting, CEO asks why did that happen? Response - Worker Jones activated the wrong switch. Why did he activate the wrong switch? Just dumb.

That, of course, was the wrong answer. Then the pinging would start. Was Jones properly trained on the right procedure? How do you know he was trained? Was this in the lesson plan you trained him with? Was it actually taught that day? Was Jones in class that day? Was it a test question? Did Jones get that question right? How many people taking that test got that question right? Has anyone ever actually watched Jones do this procedure correctly?

What about Jones' personal life? Does he have a drinking problem? Money problems? What did he do during the 24 hours before the accident? How much sleep did he have the night before? Are his kids okay?

From there it would go to -- Does our QC look at that procedure? Has QC stopped others from making that mistake? Is this a one time training thing, or do we go back and reenforce the skill? Has this happened before, but with a less catastrophic effect and if so did we take the initiative to keep others from doing it, too?

More often than not, the accident cause ended up falling at the feet of management. And, that was only the beginning. From there, it went to how are we going to prevent this particular accident from ever happening again? Are there similar accidents waiting to happen because we didn't foresee the possibility?

After watching him go through this drill a few times, if finally dawned on me what he was doing. He was training management to look at all the factors before opening their mouths.... to dig deeper before making a call. It was a most painful experience for the managers. Smart man.

Craig R. Arko
02-28-2008, 05:09 PM
In the interests of full disclosure, the quote was inspired by Spock's statement about Project Genesis in Wrath of Khan:

"As a matter of Cosmic History, it has always been easier to destroy than to create."

Something of a pastiche of the Second Law of Thermodynamics.


By the way it's Arko with a 'K'. :D

NovaScotian
02-28-2008, 05:25 PM
Apologies, Craig -- Arco could and should have been checked, not guessed. :rolleyes: Unfortunately, I can't fix it. :o

I like aeh's story too, because it fits far more situations than just an accident. It is all too easy for most busy folks to stop at the first plausible explanation rather than exploring all of the possibilities. It's a weakness of many, many designs that the designers stopped when they found a solution that worked instead of asking a host of questions about how they might do better. The ability to pursue problems to the best possible end is probably Steve J's greatest strength.

yellow
02-28-2008, 05:32 PM
Any other takers?

I fixed a screen door once.
:D

He was training management to look at all the factors before opening their mouths.... to dig deeper before making a call.

It's amazing how applicable this is at all levels of life, and how few people are willing or able to do it.



(BTW, I fixed the spelling in the thread title/first post)

fish3k1
02-28-2008, 06:07 PM
Going to the core of the problem is always the hard part, and most will simply stop analysis at the obvious symptom.

I worked for a CEO type who prided himself in the "Art of Pinging." Question after question until he had gotten what he wanted. One example.

An accident at the job site.... At the next staff meeting, CEO asks why did that happen? Response - Worker Jones activated the wrong switch. Why did he activate the wrong switch? Just dumb.

That, of course, was the wrong answer. Then the pinging would start. Was Jones properly trained on the right procedure? How do you know he was trained? Was this in the lesson plan you trained him with? Was it actually taught that day? Was Jones in class that day? Was it a test question? Did Jones get that question right? How many people taking that test got that question right? Has anyone ever actually watched Jones do this procedure correctly?

What about Jones' personal life? Does he have a drinking problem? Money problems? What did he do during the 24 hours before the accident? How much sleep did he have the night before? Are his kids okay?

From there it would go to -- Does our QC look at that procedure? Has QC stopped others from making that mistake? Is this a one time training thing, or do we go back and reenforce the skill? Has this happened before, but with a less catastrophic effect and if so did we take the initiative to keep others from doing it, too?

More often than not, the accident cause ended up falling at the feet of management. And, that was only the beginning. From there, it went to how are we going to prevent this particular accident from ever happening again? Are there similar accidents waiting to happen because we didn't foresee the possibility?

After watching him go through this drill a few times, if finally dawned on me what he was doing. He was training management to look at all the factors before opening their mouths.... to dig deeper before making a call. It was a most painful experience for the managers. Smart man.


This guy should start a management training program - I mean, this is the sort of simple thing ALL management should be doing.

schneb
02-28-2008, 06:16 PM
"As a matter of Cosmic History, it has always been easier to destroy than to create."
Which, coincidentally, is why "Wrath of Khan" was a much better movie than "Star Trek the Motion Picture".

I had the chance to ask FX guru, Peter Ellenshaw, why the first movie was such a bone and the second movie so much better. He said, "That's easy, the first movie was 10% director, 90% committee made. The second was 60% director, 40% committee made."

blubbernaut
02-28-2008, 06:50 PM
The ability to pursue problems to the best possible end is probably Steve J's greatest strength.

I found a recent example of this http://brockerhoff.net/bb/viewtopic.php?p=2417#2417
(Via daringfireball). A good, but brief, exploration of the possible engineering reasons behind things like no ethernet port and no removable battery in the Macbook Air. An example of "OK, let's think this choice right through to it's logical conclusion before we say 'but we need it'"

Jay Carr
02-28-2008, 10:25 PM
That's a very interesting article. I wonder what happens when you say to yourself. "We need it to be 3 lbs, we need it to use a miniscule amount of power" and "We need to have a removable battery and two USB ports." If you read the article, you can see that these two statements are in direct conflict with each other.

Some people would try and find a synthesis, others will completely overcome and others won't even try. I might suggest that one of the reasons for the diversity in responses is that some people look down the slope for their snowball and say "ack, it's going to hit something, let's push the ball in another direction", while others say "oh, there are objects in the way, but I think we can move them with a little work." I think the will to overcome difficulties has to be factored into this equation as well.

(As a side note, if you look in a direction down the slope and see a cliff, a la NovaScotians original example, there's nothing wrong with looking in another direction.)