I try to be nice as possible to the person behind the counter, but I just say the equivalent of "do you want my money or not? Let's just bypass the part where you ask for my info." Party City was the latest place that wanted my info. They have no need for my info. I give them money, they give me fancy paper plates for my toddler's birthday party.

.

Yes these are really good points. Certainly they did abort more than 100 different bad ideas.

There is a really good series "From Earth to the Moon." What I love is how much people were able to accomplish without email, CAD, collaboration apps, etc. It is hard enough to coordinate 10 engineers even with modern technology. You really get a sense of the planning involved from 1961 to 1969 and beyond. They had an overall plan and were determined not to fail their primary mission, and there were big question marks left in their plans for things yet to be invented.

NASA could afford to blow up rockets and not run out of funding. I think that is a key element to work within practical limits of available capital. They were certainly agile and were willing to throw out bad ideas.

Absolutely Apollo 1 was a failure. People died. That was unacceptably outside of the mission parameters. But I argue that is the reason to avoid a careless approach that encourages failure.

I suppose it comes down to semantics of words.

To me, failure means "Failure to meet project goals" that is always bad. Money runs out, timelines slip, safety is compromised, etc.

It sounds like fail-fast means: "quickly write off solutions that are unworkable" To most engineers, that is just a feasibility study. Granted, the faster and cheaper you can write off a truly bad solution, the better off you are. Breaking a few prototype is not a failure as long as that was considered in the project budget. But giving up on a workable solution too early can lead to much churning.

That's why people should fail; or rather, not be afraid of failure.

That is the key element. People take the failure part too literally as a measure of success. Failure may occur. Everyone has to do their own math on the risk/reward. There is no guarantee of the big payout for the 1 in 50 success rate.

Try like hell, recognize failure.

I think that is easier to agree with.

..and many companies burn through their capital on their 3rd attempt at failure. Failure isn't the goal. Forward progress is the goal. Recognizing failure or impasse quickly and cutting losses is the goal.

Sometimes doing nothing is a perfectly good option if there isn't a viable path given the current state of technology, market demand, and capital available. Timing is everything.

100% agree. This 'fail fast' crap is extremely narrow-minded. We didn't get to the moon by failing fast. We got to the moon by trying like hell to get it right. Failing faster would have led to 100 different aborted attempts at the first sign of trouble in a design. All the approaches had many failure modes that had to be worked through diligently. At what point do you declare failure vs. work through a problem?

If you know for a fact that your toolchain covers every case for you, that is great. I have worked on one project where someone took some really great synchronous design from the tool's libraries and put "just a simple set of logic gates" on the output signals to convert the output to gray code. That was fun.

So of course it would be a waste of time to whip out a K-map for everything. But the point is, could you? Or does a designer at least know why glitch cases happen, and what specific actions the tool is taking to avoid them?

I will say that this sort of understanding is helpful in software too for nested if statements, state machines, etc. where you can determine if state changes can be reduced, or if they are covered properly.

Wow, you can see the pavement on the highway and it isn't full of craters. The surface streets had a nice grid-like orientation and stoplights in logical places.

Have you ever been upstate New York in winter, or Boston any time of year?

Maybe it can be deployed sooner in limited areas that are well-mapped and have predictable road conditions. You will absolutely need to keep daily updates of detours and changes to stoplights, etc.

I just wonder if any existing automotive companies will want the liability, or if this will create a rift: traditional automobile companies and auto-automobile companies.

Exactly. Maybe the trend is that CS simply builds on the existing languages and solutions so that underlying principals are less relevant. There are new and higher-level concepts being taught in CS. However, prospective students should carefully weight this against their career goals and what is employable vs. academic study. Employers will care more about the domain knowledge first, and programming ability second. i.e. a math or physics major that can follow good programming practices and has a rough understanding of computability theory.

True, you may not need an EE degree. But if you can't draw a K-map and cover glitch cases, just as one example, then you are not qualified to develop programmable logic. While the FPGAs and micros come with a lot built-in, you still have to understand circuit principles when designing the surrounding support components and proper interfacing of signals, ratings, timing specs, etc. We need to understand power consumption in components to best manage it from software. So typically, the requisite skills are taught in EE, computer engineering, or something closely related. Kudos if a CS program teaches that, but I'm not sure if that is consistent.

Too much imagination with no real think-through:

*Setting ALL traffic lights EVERYWHERE continuously to GREEN - Is this fear mongering? EVERYWHERE? really? 99% of traffic lights are not connected to any grid. Maybe they have local transponders that Ambulances can request green, but it would be negligent to allow a situation that could bypass the interlocks that prevent all-ways green. There is only so much that software hacking can defeat. The professional engineer that would ever allow that situation would be put in prison.

*ATM's across the nation spewing out wads of cash (riot ensues) - ATMs and banking in general do not rely on the internet for core operations. You may find some stupid private ATMs to be vulnerable, but that is their problem. Web banking for customer-access of course is an exposure, but a genuine effort is applied to closing holes in those systems.

*Cutting electricity at night (riot ensues) - Have you ever experienced a blackout? I have. People survive. We are not animals. But, this one is interesting because there are documented cases where power plants have some malware present. However, I am slightly skeptical that PCs would control machinery in a way that a hacker could exploit directly. It would require a program that could specifically interfere with the development and deployment of code into PLCs and other real-time systems that causes damage. Not impossible, but way up there in the 1% of possible things that could happen. Most likely any corruption of information systems could be over-ridden by engineers or resolved by backup systems. There is a much more likely chance of physical sabotage (actually has happened in US.)

This is still the most credible threat, but the fact that it isn't an everyday occurrence like identity theft says that there is either insufficient motive, or other mitigating factors. If it was as easy as some news reports claim, then bored hackers everywhere would be doing it. To the original point, the solution isn't retaliatory strikes on other nations, it is regulatory fines on the idiots who don't understand how or why to firewall critical infrastructure.

*Resetting GPS coordinates ala Die Hard (2 I think) so sea level is revised - I'll leave that to a person who actually understands how that system works. My Spidy-sense says that is just Hollywood.

*DDOS facebook (riot ensues) - LOL probably true.

*Resetting/rebooting medical hardware - Possible, I'll blame the PHBs who allowed that equipment to be connected to public networks. Otherwise, they will continue normally if on private/inaccessible networks.

*Disabling cooling systems at nuclear reactors - Not really substantiated. Explain why the NRC allows the control systems to be web-enabled,

*Robovacuums commanded to "suck up the cat" - You got me there. I don't own one.

*Trains accelerated to maximum speed, brakes disabled - Same reasons as traffic lights and nuclear reactors.

Further examples:

*Hackers lift info from my computer and blackmail me. Why? because free market doesn't understand how to enforce better quality in OS's, and consumers have no power over this.

*My credit card numbers compromised for the 10th time. Why? because free market doesn't care and consumers are not well enough educated/powerless to demand chip-and-pin systems.

*Website goes down and I can't pay my bills. I pay my bills tomorrow when situation resolved.

*Movie studio leaks/hacked/whatever latest movie. Kinda their problem to instill loyalty on insiders and have secure systems.

*Some DIY'er puts his whole home automation online and hackers have fun spying on bedroom / unlocking front door / ordering endless supply of water filter supplies. - Sorry dude, you should have known.

*Car entertainment systems blasts Pron at 100 dB while children in car. - probably will happen soon. I don't trust all car companies to put quality and security first.

Interesting. Maybe this is a cultural difference.

In the northeast US where I am:
        Office == status/universal desire/privacy
        Salary == taboo discussion.

Good advice. A little recon can do you much good.

Totally agree. I've worked with a few physicists along the way. They won't admit it, but they are basically electrical engineers only missing a semester or two. They make fine engineers, willing to read a datasheet and have great attention to detail.