Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:High quantity manufacturing not more cost than (Score 1) 211

If you are using a low-volume, low setup-cost process like CNC or 3D-printing, then you have to consider the higher cost per unit (marginal cost) due to the time spent on the machine. You are paying rent on that expensive machine, and the time your parts take to build are directly correlated to that. Divide your engineering costs and other fixed costs over that small number, and you have a really expensive product.

Buying 30 parallel setups (or even renting them) becomes prohibitive very quickly (how many machines can you buy, or rent time on, who will operate them?)

A high-volume process has high tooling charges (molds, die cutters, etc.) for faster processing times (less time renting the machine per part.) But it will never be more expensive in the long-run unless there is something very peculiar about the geometry of the part being made. If that is the case, you have a problem and should reconsider what you are designing and/or doing overall.

Considering the expected volumes, this should have been considered from day 1. If the break-even on this was beyond a few hundred units, then something is very wrong and it was doomed from the start.

Comment Re:Who Exactly Gets To View a Company's Code? (Score 1) 126

I'd like to make sure there is professionalism and safety is a priority in BOTH places. Code review is just one aspect.
Industry is probably further ahead than you imagine, look up SIL.

Open-source just isn't going to happen in auto or industry. The only people who will spend time looking at it will be the competition (who would love to see your product fail), or students who have spare time but no frame of reference. Neither is a comprehensive means of reviewing code in the proper context.

An independent (and closed-source) code review should be a part of some industries. But it has to be conducted according to those specific industry norms and testing specifications. That takes years of experience and typically a committee of professionals from that industry to define.

Comment Re:Varies, I suppose (Score 2) 533

Average voltage on an AC line is 0 volts. RMS is probably what you intended. But yes, Watt-hours are all basically the same for a given RMS voltage/frequency. We will ignore power factor, that would take a lot longer to discuss...

Just to be pedantic:
The electrons going through your appliances are almost entirely the ones that were in the wire of the appliance to start with. Some electrons may actually drift enough to have come from your house's wires. But for any significant number of electrons to physically be the same ones that were in the power plant is very low probability.

This may not seem obvious at first, but the reason is that the drift velocity of electrons is actually very slow relative to the currents typically used. In other words, a piece of wire has so many damn electrons that you don't really need to move a very large portion of them to get a large current. If we were all using DC mains, then eventually you would see electrons making a round trip. But with AC, as mentioned above, the average voltage is 0, so the electrons move back and forth, but not typically getting very far in either direction.

Also, a more direct thing to consider is that most electrical systems use isolated transformers. So literally, the electrons are not passing from the utility across that barrier (unless auto-transformers are used.) It is an energy conversion to/from a magnetic field.

Comment Re:Varies, I suppose (Score 1) 533

There is a clever and very practical solution I've heard of in Germany that utilities are using to dump excess renewable electrical energy: hydrolyze to H2 and inject into the natural gas system. Infrastructure already exists, technology already exists, very low cost to implement. So you aren't exactly storing for the purpose of the electrical grid, but overall energy management is pretty good.

Similar things can be done with stored thermal systems in northern climates (you can heat water when energy is in excess and draw from it later.)

Comment Re:Oh this is easy .... (Score 2) 394

Exactly, I'm getting to be a codger with a 5-digit ID. But, I recognize that if you don't have some social media presence, then you just don't exist. And it isn't really an age thing. Plenty of people twice my age look forward to seeing what I'm doing through Facebook. I'm lucky that my wife does most of the posting for both of us because I just don't want to spend time on it.

But that is the real difference, do you text and check Facebook when stopped at every red light, or do you keep one foot planted in the Analog world?

Comment Re:Hmmm (Score 1) 262

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.


Comment Re:Ridiculous (Score 1) 112

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.

Comment Re:Ridiculous (Score 2) 112

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.

Comment Re:Ridiculous (Score 1) 112

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.

Comment Re:Ridiculous (Score 1) 112

..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.

Comment Re:Ridiculous (Score 1) 112

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?

Comment Re:The profession is in decline (Score 1) 154

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.

The shortest distance between two points is under construction. -- Noelie Alito