Not Exactly PLC related, but pertinent anyway...

[jcurado]

The best looking guy

Terry’s school bus just remembered me a example of (i)logic I once find in a math book.

“I’m the best looking guy in my bed room. My bedroom is the most beautiful of the house. No house in my street is as beautifully as mine. My street is the most beautiful in Paris. Everybody knows that Paris is the most beautiful town in the world. That makes me the best looking guy in the world”

Of course I must disagree. I am the best looking guy in my house (and the only man living here, by the way), but I don’t live in Paris.

We are a OEM and we have a limited range of equipments. Nobody knows better the way they work than we do. In the other hand, the costumer knows better than us the problems each type of equipment normally run to. I find that this always comes at 3 AM, and the people at plant will call everybody in the phone book unless the machine reacts exactly like they expect to.
This mean that we must work closely with the customer’s engineer to leave everything as is standard in that plant. This includes cable and LED colours, schematic representations of electrical and mechanical items, the way PLC is programmed and even the words used in rung comments.

Don’t what to offend nobody but I often find that people working in the plant for many years can not understand something that is slightly different from that they are used to.

I had crossed with people that ask me to put a PLC that is 5 years out of date, but I normally also learn with the specs they give me.

Our equipments became better each time I read a new customer’s specifications.

Off course, I, like everybody, have my own way of working and want some freedom, or it is not our equipment, is something we to with other people’s knowledge.



João

 

[Rick Densing]

A spec is nice, but nothing can beat regular design reviews. The likelihood of the contractor fully understanding your vision from a document is highly unlikely. This sounds like a complicated process, so it is more true.

ArikBY- I congratulate you on being able to read his post without having your eyes cross. I had to read it three times to understand it fully myself, and English is my native tongue. I'll let Terry explain his euphemism, though.

 

[Terry Woods]

ArikBY said...

Terry
Could you please explain me in plain english what is "Eight O'Clock Widget Shop".

The "Midnight Widget Shop" is derived from "Midnight Auto Parts Store". The phrase "Midnight Auto Parts Store" refers not to a place of business but rather, to a "practice". That "practice" is auto-theft. The "Midnight" part means "in the dark, out of sight, while everyone is sleeping".

I used the phrase "Midnight Widget Store" to suggest the same "practice" on Widgets instead of Autos.

The business at the "Eight O'Clock Widget Shop" is the same type as the business at the "Midnight Widget Shop"... they just have different "business" hours.

So, by virtue of the different operating time, the "Eight O'Clock Widget Shop" can claim that it is not exactly the same as the "Midnight Widget Shop". Since the spec only called for the exclusion of the use of a "Midnight Widget Shop", it can be argued that the use of the "Eight O'Clock Widget Shop" is legitimate.

In the original post, Steve said...
"What I am afraid of is my own inability to write the specification tightly enough without being too tight at the same time..."

The purpose of my post was to point out that a complete and accurate spec not only identifies what "something" is, but also what "something" is not.

When given a spec, a programmer will try to meet all of the requirements. When the job is done, the customer might not be real happy...

Customer: That's not what I asked for!

Programmer: Sure it is. It's right here in the spec.

Customer: Yeah, OK, but I didn't say you could do it this way!

Programmer: You didn't say I couldn't.


Steve wants to write a spec that clearly identifies his expectations and at the same time indicate the extent of the freedom the programmer has to fulfill that expectation.

"A Programmers' gotta know his limits!" Dirty Harry, sorta.

If the limits aren't indicated, how can they be known?

It is generally necessary to explicitly identify all of those parts that describe "what it is"... using as much detail as possible.

If the spec-writer can envision certain limits that the programmer should not exceed, or methods he should not use, or possible mis-interpretations of "what it is", then the spec-writer should indicate those limits and "what it is not".

However, to try to explicitly identify every thing that shouldn't be done is crazy! And probably won't work (excluding the "Midnight-guys" does not necessarily exclude the "Eight O'Clock-guys").

The best that a spec-writer can hope for, in this regard, is a set of carefully generalized limit statements. Which yellow vehicles are to be included? Excluded?

Writing specs can be damned tough! And the worst thing that a spec-writer can do is assume that anyone has the same "vision".


And Rick,

A design review is good only if it is used to correct or modify the spec. In the end, when the machine doesn't work, someone is gonna point at the spec and say, this is what it says!

 

[Rick Densing]

A design review is good only if it is used to correct or modify the spec. In the end, when the machine doesn't work, someone is gonna point at the spec and say, this is what it says!

I should clarify. I was not advocating design reviews in lieu of a spec. The spec is necessary. That avoids the "I did not quote that- it will cost $$$ extra." My point is that the true vision will not be realized without regular two way communication.