Sometime in the mid-90s the guy I was training and I were having a discussion about the future of technology while we were driving down the road in rural south Texas. I had a bag phone and an IBM Model 70 portable (lugable). He had a Zarus. We both carried pagers. A big part of the conversation was about how someday, we wouldn't need to carry all that crap just to do our job. We both knew that someday all of this stuff would be a single device. Just not a clue what that device would be or how it could work.
Today, about 15 years later, we still work together. I carry a Palm Treo and he has a iPhone. Different job, but mostly do the same thing, just not consultants anymore. I don't think either one of us could do our job without these gadgets. The ability
to ssh into our systems is key to our jobs, and it doesn't really matter what device we use anymore. The gadgets are getting to be more than just a convenience for both of us. They almost define our function in the job. Even if we're out of the office, we still take care of issues, now, not when we get back.
The gadgets have raised expectations for a lot of positions. If I still worked like I did back in the 90s, people would be waiting either until I got there, or got where I could hit a phone line and modem. Now, with the internet (ultimate gadget) and a smart phone, I can fix most problems at 70mph running down the road (as a passenger, of course, not going to break any laws, ha). And that's become almost an expectation.
So, yes I kind of see this as the decade of the gadget, but the gadgets mostly control us.
God help us all.
Who here has put underhanded code in released products?
I admit to adding and concealing the flight cam easter egg in Star Wars: Knights of the Old Rebublic. It wasn't nearly as clever as the contest entries, and it would be impossible to claim innocence if I was caught, but I enabled the "debug" cam using a generic-sounding external variable, put the code inside an "#ifndef _DEBUG" block, added a comment to describe the code as some boring debug message thing (hardly worth looking at), and had a little loop to decode the "Punch it, Chewie!" message to that the string wouldn't show up in the executable.
winning the lottery
Nobody ever wins the lottery anyway. I took a quick sample of the subset of the population that participated in lotteries and none of them had ever won, and by extrapolating that data I was able to prove that nobody had ever won a lottery ever.
Some other studies have been done that came to different conclusions but I believe that their data collection methodology was flawed as their results didn't agree with mine, so I think they can be safely excluded.
After a few months of dealing with clients and management, I think most engineers feel like blowing something up...
The thing that makes it less true is that it is from an anonymous coward and the science was not published. Nothing that was said can be 'proven' or sought out based on what is there.
Even if it is from a very unlikely event.... mmmm... interesting.
Your post is spot on. I'd mod up, but I wanted to clarify (I think you'd agree) that there's a difference between a successful experiment that is inconsistent with a theory and a failed experiment. The purpose of an experiment is not to prove a hypothesis, it's to TEST a hypothesis (or to gather data toward that end). Success means you make a useful statement that aids in the test. Failure means the data were not useful. It has nothing to do with the correctness of the theory or hypothesis.
In the specific quote mentioned, the data "not making sense" doesn't mean that they disagreed with what the experimenter was expecting, it means that they came back in a way that "couldn't happen." That is, that something had gone wrong making the experiment a failure. For example, in some tests I was doing a couple years ago with a prototype radio receiver, I needed to measure its noise level. As a signal, I would sweep a resistive load up and down in temperature---the load outputs noise with intensity that depends on its physical temperature. In this case, as a check, I would start with the load at a low temperature, then heat it past the point of interest, and then cool it back to the starting temperature. I would measure twice, once on the way up and once on the way down. What I found was that the results disagreed between the two measurements. That "does not make sense" in the sense of the article---the testing method was flawed.
In a sense, it was a successful test of a hypothesis. The hypothesis was that the receiver behaves in a particular way (which is what you'd consider the REAL hypothesis under test) AND that the test setup was a valid way to measure that. I disproved the joint hypothesis. In this case, it was the latter part that was invalid---the test was invalid---and I could say nothing about the receiver. This was simply a failed experiment. There is no religion going on by my not claiming that receivers don't behave as we think they do when I just discarded my results.
Every now and then, the reason for a failure might be interesting. This is rare, but when it happens can be responsible for amazing discoveries. In my case, it was a problem of thermal equilibrium. My devices were operating in a vacuum at very low temperatures (about 20 Kelvin) and it can be difficult to affix a heater or a thermometer to just the part of a device that you want to heat or measure....
The OP's statements mirror the general misunderstanding of the scientific method that is rampant in the non-scientific community. We need to help people understand this.
Unfortunately this is not science. There is no new discovery here. This is a piece of speculative history by scientists who are not experts in the field, playing fast and loose with the data in the field.
"Engineering without management is art." -- Jeff Johnson