“Do you have these symptoms? Here is the problem I think you have and here is how I can help you solve it.”

According to Sean Murphy in “Three Sales Pitches That Never Really Work”

Approaching Early Customers

  • Poor: “Would you like to play with this?”
  • Poor:  “Would you like to use this?”
  • Poor:  “Would you feel bad if our free product was discontinued?”
  • Poor:  “You would be really stupid not to try our product.”
  • Better:  “Do you have these symptoms? Here is the problem we think you have and here is how we can help you solve it.”

“No one wants to be the last ostrich to pull its head out of the sand.”

According to Huw Price in “Is the cold fusion egg about to hatch?

I proposed in my essay that science should be more tolerant of its mavericks, when so much is at stake. If I’m right, then the reputation trap itself is the thing that should be condemned and ridiculed, not the science of LENR.

Not surprisingly, some readers weren’t convinced. Some concerned commentators even worried about what the piece would do to my own reputation. So, three months later, am I having any regrets?

On the contrary, the story has become even more interesting, in my view. I want to offer some updates for readers who weren’t persuaded last time that these developments were worth following for themselves. And I want to sound a note of caution for anyone who still feels confident that they can continue to ignore the field. If LENR is on the verge of a comeback, the reputation trap will turn inside out very, very quickly. No one wants to be the last ostrich to pull its head out of the sand. You have been warned!

Tip of the hat to Frank Acland.

Why chip designers won’t risk tool changes

According to Tom Simon

Years ago I thought that chip design companies would embrace the latest technology and be eager to adopt new tools. What I learned was that the people implementing and managing design projects were taking a lot of risks with almost every aspect of their projects. What they most wanted is to minimize risk from the design process – especially from design tool changes.

The reluctance to change goes much deeper. In the middle of a project a design team would never be willing to change tools, or even tool versions. Even minor updates from vendors can have subtle algorithmic changes that affect results. Beyond the obvious possibility of an outright bug, there can be variations in results that can affect every downstream step. This is true for implementation and sign off tools.

Chip companies spend significant resources on correlation and validation of tools. In some cases, known bugs in software are compensated for and if a tool vendor were to suddenly fixed the bug it could break the flow. Pretty much the only reason a design team will change any tool or tool version is to fix a show-stopper issue.

Active learning methods are more effective than lecturing

According to Mark Guzdial

Last year, the Proceedings of the National Academy of Sciencepublished a meta-analysis of 225 studies (see paper here). The conclusion appeared as the title of the paper, Active learning increases student performance in science, engineering, and mathematics. There is increasing evidence that improved teaching reduces the achievement gap between disadvantaged and more advantaged students, e.g., in Biology (see paper here) and in Computer Science (see new paper here from ICER 2015).

Now, Nature has just published a paper (see it here), Why we are teaching science wrong, and how to make it right, which includes the quote, “At this point it is unethical to teach any other way.” Wired magazine’s article on the active learning papers (see link here) makes the connection more explicit: “The impact of these data should be like the Surgeon General’s report on ‘Smoking and Health’ in 1964–-they should put to rest any debate about whether active learning is more effective than lecturing.”

It’s now a matter of science, not opinion. Active learning methods are more effective than lecturing. We should encourage use of active learning methods in our classrooms. The blog post linked here connects to resources for improved teaching methods in computer science. There are active learning methods that we can use even in large classes, like Peer Instruction (see PeerInstruction4CS.org).

Custom computer hardware too expensive for universities to build

According to Mary Jane Irwin interviewed by Leah Hoffman

Most of our work since then has been this simulation-based work. There’s been very little building.

Is that because of cost?

It’s really, really expensive these days to build custom hardware at the current or near-current technology node. You just can’t afford to do it at a university, so most architects do simulation-based research. Some design with FPGAs, and that’s great, but the number of people building custom hardware in universities has dwindled to almost nothing.

The interpreter from Rossi’s ideas to the standard world

According to Fulvio Fabiani, the lead engineer on inventor Andrea Rossi’s E-Cat,

Rossi doesn’t like standard reasoning. He is not a linear researcher. I find myself arguing with Andrea because his views are not compatible with other points of view in a way so you can exchange information. I am lucky that after three years I now have a certain confidence, and this confidence allows me to do things in my own way regarding the power supply system, because what he thinks is not feasible for standard and linear technicians. I’m acting almost as an interpreter from his ideas to the standard world.


He comes with a paper fluttering, saying ‘Oh, I had this idea, we have to try this’, throwing away 15 days of your setup of a reactor because he wants to try something different, and you have not even finished the idea that he had previously. Rossi is an avalanche of great ideas.


I assure you that I have seen things that only I, Rossi and a few other people saw. We really saw things… I really saw the new frontier of energy. There is nothing in comparison. You cannot imagine. I speak of the E-CatX and many others of Rossi’s experiments. We have tried lots of things, and we have made some twenty and more different reactors. And I can assure you that with some of them we have truly seen a new world. Energy density, reaction capacity, in the sense of things never seen. The new frontier of energy. The field that this reaction opens up is so vast that it’s almost impossible to imagine all the capabilities and possibilities.



Innovation and standards

According to Dave Rich

The whole point of a having a standard is recording common practice.

[We] have a long history that other end users and implementers of the standard do not have. It’s easy for us to understand the intent, and search the LRM for justifications, but those other people do not have that benefit. And all the people in that environment (training, support, maintenance, AEs), are faced with these problems every day (and many times each day).

According to Brad Pierce

There are more answers to “Why Standards?” than just “recording common practice”.


For example, “Standards can fuel innovation by providing a common starting point.”

Importing Java-style interface classes was an excellent addition to the SystemVerilog language, but they were not common practice in SystemVerilog tools.

According to Dave

I’m not trying to say there’s no place for innovation in standards, it’s just that you can’t forget the underlying principle that brought everybody together in the first place.

I know that if you get a lot of engineers in a room they all will want to work on new and exciting ideas but you can’t forget about the foundation. My favorite analogy:: you can build the most advanced aircraft in the world, but it will never take off unless someone designs the rubber tires.

According to Brad

I’m not objecting to investing some resource into perfecting our rubber tires, I just don’t think the ones we have now are so defective that we can only dare taxi around the airport.

There ought to be a balance between maintenance and innovation, if only to fire up the enthusiasm of the participants. I don’t know anyone that wants to be on projects that have fallen completely into maintenance mode. Maintenance is an honorable and necessary function, and we all do some of it, but it’s thin gruel that should only be eaten as part of a balanced diet.