/* Google Analytics */

Friday, December 12, 2008

Hewlett & Packard, Bacon & Morgan

Earlier this week, Merc columnist Mike Cassidy wrote a touching tribute to entrepreneurial engineer Karl Bacon, who died Nov. 14 at age 98:
In 1946, Bacon and partner Ed Morgan opened the Arrow Development Co. in Mountain View. The two were a tight team who started out doing some machine work for HP and just about anything else that would bring cash through the door. Bacon was the math mind, a self-taught engineer who tended to figure out what needed to be made while Morgan concentrated on how to manufacture it.

Then Morgan got the idea that they could build a merry-go-round for the city of San Jose, which they did. Soon a man named Walt Disney was talking to them about coming up with some rides for a new park he was opening in Anaheim. They did that, too.

Mr. Toad's Wild Ride, Mad Tea Party, Dumbo the Flying Elephant, It's a Small World, Alice in Wonderland, Matterhorn Bobsleds, Pirates of the Caribbean, Haunted Mansion and more.

"They did most of the rides in Fantasyland," says Jane Bacon, 87, Karl's wife of 67 years.
The article goes on to talk about all their other major contributions to amusement park rides. While we don’t think of this as a high tech business, during its heyday 40-50 years ago, this was obviously state of the art.

Other tributes on the Internet include a discussion of their Matterhorn design, and the bio on Amusement Today, and a review of the book about them. Amazon also sells that book, which documents their 20 year relationship with Uncle Walt and his fantasy-land.

Saturday, November 15, 2008

Engineering is "sexy" again?

At least Business Week pundit Vivek Wadhwa seems to think so. (Something about Wall Street jobs being in short supply nowadays).

Tuesday, November 11, 2008

Forbes discovers mobile phone classes

As a follow up to my earlier post on teaching mobile phone programming, this evening Forbes reported on programming classes. Reporter Elizabeth Woyke talked to professors at MIT, Stanford (iPhone), Columbia (iPhone and Android), as well as a Google evangelist.

The overlap between her story and our visit was the course taught by Prof. Hal Abelson and Andrew Yu, MIT's head of mobile services (who we did not meet). Woyke reported:
Abelson and Yu view themselves as training the next generation of mobile entrepreneurs. The course is structured around weekly critiques to teach students project management and presentation skills. Adult mentors who work in the mobile industry provide guidance in and out of class. "There's a lot of asking, 'Why will people use this?'" Abelson says. "We tell the mentors to treat them like real start-ups."
...
As more mobile development courses pop up, they will naturally become more specialized, Abelson says. He advises future classes to embrace themes, such as creating applications for the developing world, to keep things challenging. "Making something for a phone will be old news. There has to be some other spin," he says.
As with my own first-hand observations, these accounts suggest a win-win proposition. Students get credit for taking a class on programming, but by developing applications in a new and emerging industry segment — as with PCs in the 80s or the web in the 90s — they develop cutting edge skills that may be immediate relevant in a commercial (or entrepreneurial) context.

Saturday, November 1, 2008

Teaching mobile programming

1st of 4 parts.

I’ve spent time the last two weeks visiting various universities to see how they do research and teaching on mobile phone programming. I’m posted on the research elsewhere, but wanted to summarize here what I learned about teaching at MIT, Georgia Tech and UCLA.

Based on what I’ve seen, the model for a mobile phone programming class would be a project-based class that combines needs analysis, use cases and prototype system development. Add in some sort of revenue model analysis, and you have a course that introduces budding software engineers to the possibility of entrepreneurship. (Absent revenue model analysis you have the typical engineering “make something cool and let’s see if we can sell it.”)

The class assumes students already have basic programming down pat, and also have at least one project course under their belt. This would be either a master’s level class or an upper division class that follows (say) software engineering.

MIT

Building Mobile Applications. The most famous course on this topic probably that by Hal Abelson, who is now the dean of teaching programmers at MIT. 24 years ago he shifted the EECS introduction to programming to Scheme (MIT’s local dialect of Lisp) with his text, Structure and Interpretation of Computer Programs.

We met with Abelson for nearly an hour to discuss his Spring and Fall 2008 classes offered to MIT CS undergraduates. The spring course (Building Mobile Applications with Android) got great writeups, perhaps because one of his teams won $300K in prize money from the Android Developer Challenge, Google’s Java programming contest.
The student application, Locale, was one of the first made available on the Android Market, and the team is evaluating commercial possibilities. Not a bad return for a 13-week class.

This semester, the class has 10 teams and about 40 students. For Abelson, a founding director of the Free Software Foundation, the iPhone was ruled out due to Apple’s NDA requirements for iPhone developers (abandoned too late for this semester). The projects are instead spread across three platforms.

Instead of being entirely about Android, the Fall course has more balance. Four projects are using Android in Java. Three are using Microsoft Visual Studio and the Windows Mobile SDK, supported by Microsoft Research New England. The remaining three are supported by the Nokia Research Center in Cambridge — two Java applications and one using Python (PyS60).

The class is extremely labor-intensive. Abelson credited Andrew Yu, (manager of mobile services for MIT) with much of the work. Each team has an industry veteran mentor — essentially a voluntary TA. Paul Oka of MSR said he spends 3 hours/week in the class and team meeting, and as much as another 5 hours early in the semester when the students are getting started.

Pervasive Computing. Abelson’s was not the first mobile phone programming course at MIT. Larry Rudolph taught a series of pervasive computing courses, first with the iPaq and then with Nokia phones using PyS60. From this effort, he wrote a boo to provide a Bluetooth programming tutorial and a 2003 pedagogy article in IEEE Pervasive Computing.

NextLab. Abelson’s course is not even the only mobile phone course at MIT this semester. If Rudolph’s course was more technology-oriented than Abelson’s, then the Nextlab course at the Media Lab is more project and need oriented, with a distinct social entrepreneurship spin. The “NextLab” course is part of MIT’s “Next Billion Network,” referring to the next 1 billion cell phone users expected to be added over the next four years — mostly in less developed countries.

We met one of the NextLab instructors (Luis Sarmenta) and visited a class session run by the other (Jhonatan Rotberg). We heard presentations by three projects, servicing Mexican farmers, rural Indian mobile commerce, and Boston low income preschool parents.

UCLA

In Spring 2008, Deborah Estrin taught “Current Topics in Computer System Modeling Analysis.” The class held 25 students — typical for a lab class — mostly master’s students, and was taught uses PyS60 with the Nokia N95.

The assignments are consistent with Estrin’s large research project on mobile sensing, with the students assigned to gather location and sound data and plot the data using Google map APIs. The 12 projects tended (not surprisingly) towards mobile social media.

Georgia Tech

At the College of Computing, there was other interest in mobile computing among researchers. I found two classes.

Mobile Computing. Thad Starner is a longtime (and prolific) researcher on pervasive and ubiquitous computing. Thus, it’s not surprising he’s taught several courses on “Mobile & Ubiquitous Computing.” I couldn’t find the website, but Starner said this semester he’s teaching about 45 students using the OpenMoko handset. Openness is a big deal to Starner, who is well known around Tech for not doing any business with Microsoft.

Augmented Reality Games. Conversely, Blair MacIntyre is teaching augmented reality (the intersection of virtual reality and reality) game programming using Gizmondo. This discontinued Windows CE-based handheld gaming console has limited communications capabilities.

Other Schools

My list is of necessity incomplete: I haven’t been able to visit all of the top C.S. programs in the country. Each school visit took a minimum of 2.5 hours, and then there’s the matter of the plane tickets. Here are a few that I found on the web.

Stanford. At least one faculty that I met this week mentioned Stanford’s course, “iPhone Application Programming,” being offered this quarter (Fall 2008).

Carnegie Mellon is offering a course this semester entitled “Mobile and Pervasive Computing.”

Tuesday, October 21, 2008

Ending performance reviews

S.Culbert's Beyond Bullsh*t(Beyond Bullsh*t: Straight-Talk at Work (Hardcover))2008The WSJ small biz blog this morning highlights a provocative column on HR practices by UCLA Professor Samuel Culbert. That it’s provocative seems to go without saying, since Culbert’s motto (and subtitle of his latest book) is “straight talk at work.”

Culbert wrote in Monday’s WSJ arguing that performance reviews are a bad idea. On the WSJ (inside the paywalll?), he also has a video on dealing with bad performers and a podcast for employees on dealing with a bad review.

From my days as a software entrepreneur, the column resonated with me, because my employees (including the software engineers and testers) always wanted a review, and I always hated doing them. So having someone telling me I shouldn’t do them seems like found money.

To summarize from the pullquote:
The Promise: Performance reviews are supposed to provide an objective evaluation that helps determine pay and lets employees know where they can do better.
The Problems: That's not most people's experience with performance reviews. Inevitably reviews are political and subjective, and create schisms in boss-employee relationships. The link between pay and performance is tenuous at best. And the notion of objectivity is absurd; people who switch jobs often get much different evaluations from their new bosses.
He lists 7 reasons why they’re a bad idea:
  1. Two People, Two Mind-Sets. The review is confrontational because the two sides have different goals.
  2. Performance Doesn't Determine Pay. Often the review is a rationalization for the eventual (budget constrained) salary decision, rather than a review of performance.
  3. Objectivity Is Subjective. Objectivity is a myth: employees change bosses, their reviews change dramatically.
  4. One Size Does Not Fit All. The same checklist is used for all, although people have different strengths and should be evaluated by different criteria.
  5. Personal Development Is Impeded. Employees won’t be honest about areas where they need to improve if it comes back to haunt them at review time.
  6. Disruption To Teamwork. The boss is supposed to lead a team but the review causes employees to conceal and be dishonest, undercutting trust.
  7. Immorality Of Justifying Corporate Improvement. The reviews are supposed to improve performance and the company, but actually they just encourage political behavior.
I don’t completely buy his proposed alternative, which he calls a “performance preview.” However, as a teacher, a parent and someone who was a tech employer for 15 years, I do agree with the goals of his alternative process:
Holding performance previews eliminates the need for the boss to spout self-serving interpretations about what already has taken place and can't be fixed. Previews are problem-solving, not problem-creating, discussions about how we, as teammates, are going to work together even more effectively and efficiently than we've done in the past.
Anything that turns a review from a win-lose to a win-win is a good idea in my book. Also, my personal and business philosophy was always look forward, not back.

The only thing missing is how to adjust salaries, since that was the entire reason employees all pushed for a review. I guess for that I have to buy the book.

Thursday, October 16, 2008

Cleantech Venture Challenge

Cross posted to Cleantech Business

The University of Colorado at Boulder is preparing to host its 4th annual Cleantech Venture Challenge, an international business plan competition for new ventures that somehow address a “sustainability” need. The business plan competition is sponsored by the Deming Center for Entrepreneurship at the Colorado’s Leeds School of Business.

The competition uses a three-stage process. An intent to compete must be filed by Nov. 21, followed by a complete business plan on January 30, 2009. The eight semifinalists will come to Denver March 17-19 for the final rounds and the ultimate selection. The National Renewable Energy Lab (in nearby Golden, CO) will also invite the top renewable energy project to present at NREL.

The top prize is $25,000. The finals will also coincide with a sustainable business summit to be held at the Denver convention center, part of the state’s efforts to position itself in the cleantech business.

Tuesday, October 7, 2008

10 fatal assumptions

In providing feedback to my MBA entrepreneurship students, I went looking for information on market sizing assumptions.

I didn’t find what I was looking for, but I did find another interesting document, from Purdue University’s extension program. The note on “Fatal Business Planning Assumptions” by Cole Ehmke of Purdue offers a list of 10 common but flawed assumptions made by new ventures.

Although he’s in agricultural economics, the first three would resonate with any tech entrepreneur or investor:
  1. We have no competition
  2. All we need is 2% of the market
  3. Our product will sell itself
I would love to see a “10 most common tech startup mistakes” list, but for now this is a suitable cautionary list.