We have a saying that eventually in the software release process, you'll decide that QA found that particular bug after you shipped. Even if you haven't shipped.
We have another saying that "shipping" is an outstanding feature for a software product to offer.
Dang, Kevin. You're almost reading my mind lately.
As the Graybeard, I tell the younger engineers (my padewan learners) basically that quote. Engineering is fun and we always want to wring out that last dB of perofmrance, but the reality is that we're in business. If we don't turn the crank on the production line we don't ship radios and we don't make customers happy. Not to mention that selling the product pays our salaries.
The art is figuring out when it's time to let go (shoot the engineer and ship the radio).
I was a process engineer - the one that made my little part of the factory work. The idea there is that we should be able to do the same thing again and again and again forever without any changes in output, even as we constantly change inputs (i.e., scientifically cut corners) to reduce cost, increase throughput, and implement new technologies.
My favorite people were maintenance guys, who would tell me I could make a change to our production protocols, it would just ruin their existence because they'd have to clean up the mess after the factory cratered.
A lot of times, the chief draftsman needs to put the breaks on their checkers too. Otherwise details will be redrawn for days and weeks. Especially when dealing with an experienced draftsman whose drawings are near perfect. Changes made just for changings sake ruins the lead time for a project.
Kevin, my brother Mort, a Journeyman mold maker and chief figure it outer when an engineer designed mold does not work the way it should, says engineers should only drive trains.
Oh, yes, but being somewhat of an engineer myself, sometimes, I wanna just step back and say "Okay, smartass! YOU make it work!"
When I was a copier/fax/computer tech a common joke was that the engineers can tell you how it's supposed to work, but it takes a technician to tell you how it's going to work. Personally I think it's because engineers keep trying to make things foolproof, even when they know they quality of fools is an upward trending curve.
1. Scientists in Bond movies
:
:
(bunch of other stuff)
:
:
(more stuff)
:
:
2. Fornicators, druggies, chicks with big hooters in teenage slasher movies
:
:
(more stuff)
:
:
3. Guys with red shirts on Star Trek
Yes, of course you kill the people who know how things work. It's been a fundamental rule since the Pharoahs built the pyramids.
No, no, no. It seems to have gotten condensed over time, and lost some important bits.
"There comes a time in the history of every project when it becomes necessary to take it away from the R&D group, give it to the Manufacturing Engineering department for a fresh start, who will take it through a pilot run, and then be given the door for embarrassing the Real Engineers(TM), who will then monitor production.
Personally I strongly suspect engineering departments the world over would be turning out some amazing things.... if only the sales and accounting departments weren't allowed any say in what they do.
How about we just begin production and assign the engineers new projects....cuz I shoot back...
Note:
All avatars and any images or other media embedded in comments were hosted on the JS-Kit website and have been lost;
references to haloscan comments have been partially automatically remapped, but accuracy is not guaranteed and corrections are solicited.
If you notice any problems with this page or wish to have your home page link updated, please contact John Hardin <jhardin@impsec.org>
JS-Kit/Echo comments for article at http://smallestminority.blogspot.com/2010/03/quote-of-day-engineering-edition.html (16 comments)
Tentative mapping of comments to original article, corrections solicited.
Happens elsewhere too. Sooner or later you have to freeze the specification and start swinging hammers (or collecting data, or whatevs).
Oh, yes, but being somewhat of an engineer myself, sometimes, I wanna just step back and say "Okay, smartass! YOU make it work!"
MC
There's a Challenger in the making.
We have a saying that eventually in the software release process, you'll decide that QA found that particular bug after you shipped. Even if you haven't shipped.
We have another saying that "shipping" is an outstanding feature for a software product to offer.
Dang, Kevin. You're almost reading my mind lately.
As the Graybeard, I tell the younger engineers (my padewan learners) basically that quote. Engineering is fun and we always want to wring out that last dB of perofmrance, but the reality is that we're in business. If we don't turn the crank on the production line we don't ship radios and we don't make customers happy. Not to mention that selling the product pays our salaries.
The art is figuring out when it's time to let go (shoot the engineer and ship the radio).
Bob
I was a process engineer - the one that made my little part of the factory work. The idea there is that we should be able to do the same thing again and again and again forever without any changes in output, even as we constantly change inputs (i.e., scientifically cut corners) to reduce cost, increase throughput, and implement new technologies.
My favorite people were maintenance guys, who would tell me I could make a change to our production protocols, it would just ruin their existence because they'd have to clean up the mess after the factory cratered.
A lot of times, the chief draftsman needs to put the breaks on their checkers too. Otherwise details will be redrawn for days and weeks. Especially when dealing with an experienced draftsman whose drawings are near perfect. Changes made just for changings sake ruins the lead time for a project.
Kevin, my brother Mort, a Journeyman mold maker and chief figure it outer when an engineer designed mold does not work the way it should, says engineers should only drive trains.
Oh, yes, but being somewhat of an engineer myself, sometimes, I wanna just step back and say "Okay, smartass! YOU make it work!"
When I was a copier/fax/computer tech a common joke was that the engineers can tell you how it's supposed to work, but it takes a technician to tell you how it's going to work. Personally I think it's because engineers keep trying to make things foolproof, even when they know they quality of fools is an upward trending curve.
Yup, They Keep Making Better Fools!
"The art is figuring out when it's time to let go ..."
Otherwise, you get DOS.
Short life expectancy in movies:
1. Scientists in Bond movies
:
:
(bunch of other stuff)
:
:
(more stuff)
:
:
2. Fornicators, druggies, chicks with big hooters in teenage slasher movies
:
:
(more stuff)
:
:
3. Guys with red shirts on Star Trek
Yes, of course you kill the people who know how things work. It's been a fundamental rule since the Pharoahs built the pyramids.
It just makes sense.
(And that's an engineer talking.)
Yeah... but first the engineers shoot the scientists...
No, no, no. It seems to have gotten condensed over time, and lost some important bits.
"There comes a time in the history of every project when it becomes necessary to take it away from the R&D group, give it to the Manufacturing Engineering department for a fresh start, who will take it through a pilot run, and then be given the door for embarrassing the Real Engineers(TM), who will then monitor production.
Personally I strongly suspect engineering departments the world over would be turning out some amazing things.... if only the sales and accounting departments weren't allowed any say in what they do.
How about we just begin production and assign the engineers new projects....cuz I shoot back...
Note: All avatars and any images or other media embedded in comments were hosted on the JS-Kit website and have been lost; references to haloscan comments have been partially automatically remapped, but accuracy is not guaranteed and corrections are solicited.
If you notice any problems with this page or wish to have your home page link updated, please contact John Hardin <jhardin@impsec.org>