 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/7/2012 7:46, scott wrote:
> nothing is just designed by trial and error.
The handset of classic telephones like this
http://i891.photobucket.com/albums/ac112/stur5380/Misc%20pics/IMG_0982.jpg
spent 14 months in design research, with hundreds of test subjects.
The arrangement of buttons on a touch-tone phone was one of something like
15 or 18 possible patterns, with people trying out how fast they could dial
numbers and how long they could remember what number they dialed.
Even trivial things like "count to ten" thus take months of research.
--
Darren New, San Diego CA, USA (PST)
"They're the 1-800-#-GORILA of the telecom business."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/2012 9:30, Orchid Win7 v1 wrote:
> OK. But does any other company on the planet do that?
Every single other company on the planet does this, or they're not yet
making any money and hence are a bad bet for you to be applying to. It's
fundamental planning. It's what you're *supposed* to be learning to do when
you get an MBA degree.
> I've seen a guy splice fiber. He cut the two ends, put them in a machine,
> and pressed a button. It used a digital microscope to align the ends in
> three dimensions, and then weld them together. Freaky as hell.
Yep, then it tests it and tells him if it worked. And to find the break, you
plug a different machine in, it flashes a laser down the wire, figures out
how long it takes to return after bouncing off the break, and then tells you
where to go to fix it.
Now, how much technical skill do you think it took to design those machines,
and how much technical skill do you think it took to do that work before
those machines were common?
--
Darren New, San Diego CA, USA (PST)
"They're the 1-800-#-GORILA of the telecom business."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 08 Sep 2012 20:54:17 +0100, Orchid Win7 v1 wrote:
> Did I mention that I used Dell for the absolute minimum amount of stuff?
> They certainly aren't be favourite company. :-P
You had mentioned that once or twice, I believe. I don't believe I
claimed they were your favourite company, just the one that happened to
meet your narrow expectations.
> And yes, if you go to just about any website to purchase stuff, they
> give you a list of technical specifications. But that's not "marketing
> copy", is it?
It sure is. You think it gets accurately written on its own?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And yes, if you go to just about any website to purchase stuff, they
>> give you a list of technical specifications. But that's not "marketing
>> copy", is it?
>
> It sure is. You think it gets accurately written on its own?
From what I've seen, it gets /inaccurately/ copied and pasted from the
manufacturer's own website. :-P
I don't think of a table of figures as "copy". I think of something
written in English.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 09 Sep 2012 10:29:49 +0100, Orchid Win7 v1 wrote:
>>> And yes, if you go to just about any website to purchase stuff, they
>>> give you a list of technical specifications. But that's not "marketing
>>> copy", is it?
>>
>> It sure is. You think it gets accurately written on its own?
>
> From what I've seen, it gets /inaccurately/ copied and pasted from the
> manufacturer's own website. :-P
And who does the work for the manufacturer's website? Is it just magic?
> I don't think of a table of figures as "copy". I think of something
> written in English.
It certainly counts as documentation that gets created by someone, and it
takes time to pull the info together.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There's a lot more to security than designing the cyphers. And yes,
> Bellcore had, for example, a 250 person department doing just that sort
> of stuff. Ever hear of the NSA? Is it MI6 where you are, or some other
> part?
http://www.gchq.gov.uk
http://en.wikipedia.org/wiki/Government_Communications_Headquarters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I take it you don't subscript to "test-driven software development" as a
> methodology either? ;-)
Sure, do tests, but properly design the stuff first (including the
tests). You shouldn't use testing as a substitute for good design.
> I can imagine a lot of design work goes into a brand new product. But if
> you're making a dishwasher, you're not making a brand new product.
> You're making a product which is nearly identical to several hundred
> thousand existing products, but with one or two trivial differences.
> Most of the research has already been done. You just need to
> double-check that your new design doesn't contain any unexpected flaws.
If you just did that most shops wouldn't even stock your new product
because the water and power usage would be far above your competitors.
You think the latest machines are more efficient and better at cleaning
by magic?
You could use the same argument for car engines, just take the previous
one, add a couple of trivial differences and test it. But again nobody
would buy your new car because all your competitors would have spent the
last 5 years designing a far more efficient engine (even if it looks the
same from the outside).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> nothing is just designed by trial and error.
>
> The handset of classic telephones like this
> http://i891.photobucket.com/albums/ac112/stur5380/Misc%20pics/IMG_0982.jpg
> spent 14 months in design research, with hundreds of test subjects.
>
> The arrangement of buttons on a touch-tone phone was one of something
> like 15 or 18 possible patterns, with people trying out how fast they
> could dial numbers and how long they could remember what number they
> dialed.
>
> Even trivial things like "count to ten" thus take months of research.
Sure when complex human interaction is involved it's often difficult to
avoid testing, but even so there is still lots of work going on to try
and understand and predict human behaviour exactly to avoid having to do
such tests.
My point was it's cheaper to avoid real physical testing, especially
when expensive or lengthy tests are needed. If there is a feasible way
to avoid it (like by spending more time in design or simulation) it's
usually better.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/09/2012 09:51 AM, scott wrote:
>> I take it you don't subscript to "test-driven software development" as a
>> methodology either? ;-)
>
> Sure, do tests, but properly design the stuff first (including the
> tests). You shouldn't use testing as a substitute for good design.
Amen.
> You think the latest machines are more efficient and better at cleaning
> by magic?
No. I think they aren't any more efficient at all.
> You could use the same argument for car engines, just take the previous
> one, add a couple of trivial differences and test it. But again nobody
> would buy your new car because all your competitors would have spent the
> last 5 years designing a far more efficient engine (even if it looks the
> same from the outside).
Surely trying to tune an engine to get a few percent more efficiency out
of it is vastly easier than INVENTING the internal combustion engine in
the first place...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You think the latest machines are more efficient and better at cleaning
>> by magic?
>
> No. I think they aren't any more efficient at all.
Why do you think that?
A quick google found this:
http://www.fsec.ucf.edu/en/publications/pdf/FSEC-CR-1772-08.pdf
"For instance, in 1993, the energy per cycle for
dishwashers averaged about 2.6 kWh/cycle along with a hot water use of
about 10 gallons (38
liters). By 2004, with new energy standards (DOE, 2003) the numbers had
fallen to about 1.8
kWh/cycle with typical water use of about 6 gallons (23 liters)."
How do you think they managed to do that and still clean the dishes?
They certainly didn't just adjust the amount of water used.
> Surely trying to tune an engine to get a few percent more efficiency out
> of it is vastly easier than INVENTING the internal combustion engine in
> the first place...
Actually no. You try taking a device that has been under mass production
for decades and the subject of continuous research. If you could get a
few % more efficiency then you'd be able to ask for a very high salary
from a lot of companies instantly :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
