China is stealing software? Yes, but it’s not as useful as it sounds.

Inside the Chinese Boom in Corporate Espionage is the headline in a recent article in Businessweek (now named Bloomberg Businessweek). It reports an 007ish tale of software theft by a Chinese windmill company. American Superconductor Corp (AMSC) had a profitable partnership selling control systems to Chinese wind turbine company Sinovel. As for all expensive industrial equipment, software plays a vital role in wind turbines. So when stolen/edited copies of their software turned up in Sinovel machines, and Sinoval stopped accepting equipment from AMSC, it was a calamity for AMSC.

   The Business Week article implicitly blames high tech “Chinese espionage,” which has been getting a lot of coverage in the US press recently. But as a very interesting blog post by Steve Dickinson points out, the actual theft was very traditional. An insider (one of the software’s chief developers) was bribed  to turn over the source code. Nothing high-tech about the theft, unless you still call email “high tech.” And according to Dickinson, the theft was predictable, and was facilitated by lack of low-tech protection measures by AMSC. 

Continue reading

Roger Bohn – Google Scholar Citations

Roger Bohn – Google Scholar Citations.

Google does its usual amazing job of organizing information. They have a “scholar” page for every academic, with their best guess of all the papers written, and how many times they were cited. In some cases, they found web-accessible versions of academic articles  that I was not aware of.

Rather than trying to keep my own list up to date, I may come to rely on Google to do it for me.

Airplane fires are still “craft” stage

I just presented some of my research on how flying went from Art to Science, at the INFORMS conference. (Very short paper  at http://escholarship.org/uc/item/2sj362h9. Long working paper is coming soon.)  My colleague Erica Fuchs related a recent experience that demonstrates how certain activities in flying are still at what I call the “Rules + Instruments” stage, which got started in the 1930s.

During a flight to Chicago, she noticed a “bad smell.” One of the other passengers was an off-duty airline pilot who also noticed it, and went rocketing up to the cockpit to tell the pilots.  The result: they landed immediately, at an unused airport near their flight path.  A mechanic flew in and found that one of the light ballasts had overheated, producing the smell. He replaced it, and they proceeded.

Ten years ago, this would  have been treated much less urgently. “Bad electrical smell” is not very specific. But a few recent tragedies have focused attention on the problem of fuselage fires. The sobering insights were that 1) we still don’t have good instruments for detecting or locating fires in some parts of an aircraft  – the human nose is still the best we have,  2) most burning smells are not serious problems, but when there really is a fire, sometimes the only effective countermeasure is to land; 3) every minute counts.

Pilots used to follow an elaborate checklist, attempting to diagnose and solve the problem in flight, but in a couple of cases that gave the fire time enough to take hold and destroy the aircraft. So on her flight, the procedure apparently was “when you can’t identify the source, land as fast as possible.” Does anyone know what the “official” checklists look like now, for this situation?

Official report of F/A-18 crash

On December 8, 2008 a Marine Corps jet crashed near my house, killing four civilians. The USMC did a thorough investigation and held a press conference about the results, complete with powerpoints. However, I was not able to find the actual report anywhere. I eventually filed a FOIA request, and got a redacted version of the report and all its attachments.

The crash fit a common pattern: a lot of small mistakes, by a variety of people, added up to a disaster. It was not just the pilot at fault, although he was certainly involved.

Because these reports were hard to get, and will be of interest to others, I’m putting them up on this site. If I can find a better (more relevant) repository, I’ll also post it there.

There is a lot of bureaucratic material in the reports. I will gradually post all of it. Questions are welcome – use the Comments section.

Continue reading

The Diminishment of Don Draper : Andrew McAfee’s Blog

Interesting post by Andy McAfee about what he refers to as the Oracular approach to decision making. (Andy took over the Entrepreneurship course I taught while on sabbatical at MIT a few years ago. By all accounts he did an (even) better job than me!)

The above lists of characteristics are focused on a single fictional character in the advertising industry, but in my experience they’re fairly common across business oracles and their decisions in many real-world settings as well. When I reflect on how I’ve seen strategy, marketing, planning, and product design decisions made at large organizations, I see a lot of the stuff listed above.To be sure, I also see business oracles gathering lots of data, commissioning studies, and sometimes even running experiments. But I often get the sense that the point of all this activity is to confirm the soundness of the oracle’s initial idea, rather than to test it a state of affairs captured elegantly by this New Yorker cartoon. Several people at last week’s workshop on business experimentation observed that it takes months for many companies to set up even a simple experiment today, and opined that this is because of the great care taken to ensure the outcome.

via The Diminishment of Don Draper : Andrew McAfee’s Blog.

I’m not going to try to summarize  his post here, but I would add that a good Oracle is called an expert. And expertise is real – and it’s necessary at the Craft end of the Craft-to-science spectrum.