It’s happening!
Twelve years ago, I started talking about disintermediation of education. Today I read an article in The Economist that talks about a gentleman from India named Krishnan Ganesh who has set up a company to provide Indian tutors to American schoolchildren.
Cooooooool.
Yay!! Wired Magazine tells me that the Sixth U.S. Circuit Court of Appeals in Ohio has overturned the Stored Communications Act!
Basically, the Stored Communications Act made it possible for the government to seize your email records directly from your ISP, without a warrant, and without ever telling you. While I understand that many people are all in favor of violating civil rights of guilty people, I am really really against violating the rights of innocent people, and any time you make it easy to violate the civil rights of guilty people, you pretty much guarantee that some innocent people’s rights will be violated as well.
I thus see this verdict as a Good Thing. Go EFF! Go ACLU!
Robert X. Cringely has an article where he says that Google will ultimately be killed off by employees who have left to start their own company.
While I don’t own any crystal balls, I don’t think Google is as doomed as he does. His reasoning is that the 20% time Googlers have to work on other projects will result in 4,000 new product ideas per year, of which 400 will be good, but only about ten of which can be turned into new products. He says that the people who had the other 390 will be bitter and go start their own companies.
I have to argue with some of the math.
80% of the the projects on my list are either internal tools or add-ons to some existing product. It is way, way easier to think of a feature enhancement than a completely new product. I would be really surprised (and disappointed) if they aren’t already working on a to-do list manager, so my list probably has 0% new products.
While Cringely figures there will be 390 worthwhile projects per year that will get killed, I figure that the number of worthwhile new-product ideas will be less than 20: (3700 coders in FY 2006/ 3 people per team) * (1 new product / 10 projects) * (1 product that is worthwhile / 10 proposed products) = 12 worthwhile products.
In 2006, as near as I can tell, they launched nine new products: GCalendar, GDocuments, GSpreadsheets, GCheckout, SketchUp, GCo-op, and about three versions of existing products for mobile phones.
Only four of the things I mentioned were really new (vs. a port to phones) and came from in-house (vs. acquisitions). GCo-op doesn’t seem all that major to me, so really there were three major new in-house products: GCalendar, GSpreadsheets, and GCheckout. If my estimations are right, then that means that there were nine new products that got orphaned. Probably less than 10% of the people who have orphaned products will leave, so that means less than one project would leave. If that product required Google’s infrastructure, then chances would be even lower that it would escape.
The fact that two of the products that were released in 2006 (SketchUp and GDocuments) came from acquisitions says to me that Google doesn’t have enough new product ideas internally to keep up with the number they can release and support. I don’t know, but I suspect that I was being optimistic in my estimate of new products per 20% project. It’s probably much lower than 10%. This would mean that Google actually has quite a ways to go before they start losing people who are frustrated that their pet project got cancelled.
I expect that there are a non-zero number of people who will quit and start their own companies, but I think that will be because they see an opportunity in an area outside of Google’s business. They will decide to open a restaurant, or consult, or design video games, or set up a charter bus tour company. Some people will step off of the treadmill and raise kids, go into the ministry, or become forest rangers or professional snowboarders. While Google might miss those people, I don’t think that the professional snowboarders will be a threat to Google’s continued existence.
Permalink Comments off
I have seen a lot of discussion over the years of the relative strengths (or weaknesses) of specific languages. People talk about why they use this language or that language, and they seem to always talk about specific linguistic constructs of their favored language.
“Mine has generics!” “Mine has macro expansion!” “Mine has closures!”
Sometimes the various devotees will give a nod to the richness of their language’s libraries, or to the robustness of their compiler, but rarely.
Recently, I’ve been working on a hobby project in PHP while reading up on tools like odb, JML, Daikon, Esc/Java2, javaspider, and EmmaECL. The contrast is stark.
PHP is stable enough, and seems to have plenty of libraries, but PHPEclipse quite downrev compared to Eclipse, the debugger doesn’t work at all for me (and I don’t now where to start troubleshooting), and there are essentially no additional tools. I feel like a starving dieter writing reviews for a gourmet food magazine: shackled to PHP and pining for the abundance of the Java tools.
Java’s advantages in the tool arena aren’t accidental.
I am just about ready to swear fealty to Java, purely because of the richness of the third-party programming toolset.
Permalink Comments off
I recently watched some people debugging, and it seemed like a much harder task than it should have been. It seems like inside an IDE, you ought to be able to click START LOGGING, fiddle some with the program of interest, click STOP LOGGING, and have it capture information about how many times each method was hit.
Then, to communicate that information to the programmer, change the presentation of the source code. If a routine was never executed, don’t show it in the source (or color it white). If none of a class’ methods or fields were executed, don’t show that class/file. If a method was called over and over again, make it black. If it was hit once, make it grey.
It doesn’t need to be color. You could make frequent classes/methods bigger and infrequent ones smaller. If the classes/methods that were never changed were just not displayed — not visible in the Package Explorer in Eclipse, for example — that would be a big help.
Permalink Comments off
Maps are quirky things. The Web is amazing.
I was looking at Canadian province boundaries for a hobby project of mine, and found a strange divot in the border between Nunavut and Northwest Territories. Google maps shows the border running happily due east along the 70th parallel, then suddenly dropping down about seven miles, going over about five miles, back up to the 70th parallel, and continuing east as if nothing had happened.
I was stumped as to what it might be. I looked at the area at the highest zoom, and I could see absolutely nothing interesting there: no roads, no lakes, no nothing.. I speculated that maybe there was a Minister of Parliment who had a summer cottage there, because nothing else made sense.
I asked the geography types here, and one asked a friend, who posted it on MetaFiler, and I got an answer! The short answer is that there was a prior land claim that the government just didn’t want to open up again.
It turns out that the reason that I couldn’t see anything interesting on the sat images was because Google had the divot in the wrong place. It’s supposed to be over to the right a bit. I drew a line on the map over where the Nunavut Act says it is supposed to be. There is in fact a lake there.
Now think about this. Fifteen years ago, I would have never had access to a map that showed that level of detail. (Or maybe I could get access, but it would take enough effort that it wouldn’t be something I did casually.) Fifteen years ago, if I wondered about the divot, I wouldn’t have even known how to start finding out what that divot was. And, if I found an error in the map, I wouldn’t have known who to contact about fixing the map in the next printing. Now, thanks to the Web, I can do all those things.
It’s been thirteen years since I discovered the Web, and I still think it is pretty amazing.
Interesting article on how datamining for terrorists doesn’t work.
From the article: “Finding terrorism plots is not a problem that lends itself to data mining. It’s a needle-in-a-haystack problem, and throwing more hay on the pile doesn’t make that problem any easier.”
Permalink Comments off
I blogged before that I thought Microsoft was vulnerable, that Google should offer their email and calendar to businesses. Well, it’s happening now. It’s not clear if the data is on Google’s servers or behind the corporate firewall, but I’m guessing (from the lack of any saying otherwise) that it is on Google’s servers. Apparently Outlook causes enough pain that some companies are willing to let their data out of their control.
Permalink Comments off
Coté riffed on the cake analogy in my last posting. If I understand him right, he seems to be saying that, just as you scramble to figure out what cake your boss wants by consulting other information sources, you should scramble to figure out what to do when your software process is underspecified.
I’m not sure that’s a perfect analogy, since in the cake analogy, you had other sources of information about the boss’ desires. You had access to your boss’ schedule, phonelist, and permission to act on their behalf. For underspecified software, you would have to use a lot more imagination to figure out just what it should look like, and your management might not give you the time or budget to do so. 🙁
Permalink Comments off
This is a response to Joel Spolsky‘s review of Dreaming in Code, a book about the development of Chandler at the Open Source Applications Foundation.
I was at OSAF for two years. Many of the things Joel says are consistent with my view of how things happened, some are not, and some are fully correct but don’t tell the whole story. Some of the things people on the discussion group are speculating are wrong. I’m going to write responses down in no particular order with no particular story arc. I’ve tried to boldface the thesis topics of each idea.
(Note that I haven’t read Dreaming in Code yet, so am not commenting on the book, just Joel’s review of it and the comments on the discussion group.)
There was an implication that the people at OSAF were lazy and interested in doing as little as possible to keep getting their paycheck. I think that is a grave disservice to the people there. Getting a paycheck isn’t usually that difficult — especially for people of the calibre that OSAF could attract. Top coders want to ship stuff!
However… in a normal company, you have the VP of Marketing representing the customer’s interests and the VP of Engineering representing the developers’ interests (i.e. could it actually ship). The two act as check and balance, so that the customer gets something they want in a reasonable timeframe. Unfortunately, Mitch was acting as the VP of Engineering, and the VP of Marketing, and the customer, and the venture capitalist.
Furthermore, Mitch had been very successful. It seemed reasonable to believe that if he thought we should do X, we should do X. This meant that Mitch didn’t get particularly fierce pushback when perhaps he should have. For example, he was adamant that we should do Chandler peer-to-peer, without a server. Doing a collaborative calendar without a server is really, really, REALLY hard. He eventually clarified that by “server”, he meant “something difficult to administer”, and so OSAF started working on a server.
Mitch has many many many fine points. He is a good and caring human being. He is clever. He has an ambition to make the world a better place. However, he has also been very very wealthy for a very long time, and I think that Mitch’s environment has taught him that that he does not need to be particularly clear in his instructions.
If my husband says to me, “please get me a cake”, I’m going to insist that he tell me what kind of cake, what event it is for, how many people it is for, and when it needs to be ready, and where it needs to end up. However, if my Powerful Boss says, “oh yeah, and order a cake” right before she hops in a cab to go to meet with the President, then I’ve got to figure everything out myself — and I have strong incentive to do so. I’ll go find my boss’ calendar, look through upcoming events on the schedule, guess at which one is likely to need a cake, and phone the boss’ cook to find out what kind of cake the boss likes. If I am really on the ball, I might phone the other participants’ people to find out if there are any food allergies, likes, or dislikes. If I am good, my boss will come back and find out that in fact she did not need to give clear instructions; if I am not good and there is no cake, I most likely would (eventually) find myself no longer employed by Powerful Boss.
This vagueness might be acceptable for cakes, but it’s death for developing code efficiently. For example, Mitch said that by “server”, he meant “something difficult to administer”. Either he changed his mind or he just never realized that he needed to be clear that he meant “something difficult to administer” instead of “always-running software that responds to requests from other computers on the network”.
I think Joel was right that too many designers slowed us down. Something that made it even worse was that the team grew person by person, i.e. was not wholly in place at the onset. Every time we got a new person on the team, there was a significant adjustment period while they lobbied for their own ideas for how things could be done better. For example, Lisa Dusseault is a big WebDAV person. After she started, she lobbied for doing more with WebDAV, saying that Life Would Be Better with WebDAV. She convinced us, and we started doing a lot more with WebDAV. She was probably right, Life Probably Is Better. But changing things around certainly cost us some time.
I think Joel was too harsh on stamping. He is right that being able to send things around by email is not exciting. It’s going the other direction that is more interesting: taking email messages and being able to turn them into things easily. An email message might also be a task: “Could you please frizbat the hongtholt?” An email message might also be a calendar item: “Can we meet next Thursday at 12?” Yes yes, with Outlook you can drag an email message onto your to-do list or calendar, but you still have to (had to?) fill in all the to-do information by hand. Tedious. The text recognition was supposed to do that for you.
I have said before that current to-do list managers suck rocks, and email clients could be much better. Chandler in the Grand Vision would have / could have addressed those. However, we found out very early on that people didn’t care about to-do managers or email clients: in 2003, people’s pain was centered around calendaring: you really had to buy Outlook and run an Exchange server to get halfway decent one, and even Outlook was only halfway decent. There was not a way at the time for a small business or non-profit without an IT staff to coordinate calendars. Period. So we focused on calendaring, which IMHO was the least exciting and revolutionary part of Chandler.
Something that Joel doesn’t mention as being a barrier to getting help from the outside world was that in the time while I was there, we never had a contributor agreement/license in place. So Jane wants to contribute some code: what sort of agreement governs the code that Jane contributes? For most open source projects, that issue is just not thought about because there is no money involved. But with OSAF, there was serious money involved.
First, Mitch Kapor was (is) a wealthy man, and wealth attracts lawsuits. Second, OSAF pays genuine salaries. Third, the plan was always for OSAF to become self-sustaining by providing different (i.e. non-GPL) licenses in addition to (not instead of!) the free GPL licenses.
Hence, we couldn’t really accept much code without a contributor license. That didn’t get done, in large part because our counsel, Mitchell Baker was stretched waaaaay thin also running the Mozilla Foundation. (She’s now only running the Mozilla Foundation, and appears to be doing a fine job of that.)
(Side note — I was absolutely amazed at how much volunteer support we got for NON-coding tasks. From help installing our phone system to CSS stylesheet help on our wiki to advice on video capture tools, the open source community was breathtakingly generous.)
Chandler is an open-source cathedral, not a bazaar. It’s a very different way of doing an open-source project, but that is not inherently wrong or bad. You need cathedrals sometimes.
Finally: Chandler most definitely does have a mascot — one of Mitch’s dogs. 🙂
N.B. I have zero negative connotations associated with the word “boss”. It means exactly the same thing as “manager” to me, except is less formal and fewer syllables. I thus forget that some people attach a negative connotation to it. I meant no negative connotation in the Powerful Boss paragraph.
Permalink Comments off
« Previous Page — « Previous entries « Previous Page · Next Page » Next entries » — Next Page »
Considering retirement.
