Tech 4D

Earlier I posted a map of Wikipedia contributors comparing the most active users with general Wikipedia users. In his essay Who Writes Wikipedia, Wikipedian Aaron Swartz proposes that the contributions of the “core” group of Wikipedia contributors are significantly overstated. In addition, he suggests focusing on this small, but important portion of the Wikipedia community to the exclusion of the broader group of contributors is a big mistake.

If this is true, then my Wikipedia Contributor Map oversimplifies what is happening (as was pointed out in a reader comment).

Aaron Swartz wrote a script to analyze the entire history of a group of about 200 articles and conlcuded that while the majority of edits are done by the “core group”, the actual bulk of the words in the articles were done by a much broader group of contributors who have “…generally had made less than 50 edits…“.

Some quotes:

When you put it all together, the story become clear: an outsider makes one edit to add a chunk of information, then insiders make several edits tweaking and reformatting it. In addition, insiders rack up thousands of edits doing things like changing the name of a category across the entire site — the kind of thing only insiders deeply care about. As a result, insiders account for the vast majority of the edits. But it’s the outsiders who provide nearly all of the content.

And when you think about it, this makes perfect sense. Writing an encyclopedia is hard. To do anywhere near a decent job, you have to know a great deal of information about an incredibly wide variety of subjects. Writing so much text is difficult, but doing all the background research seems impossible.

Here’s another paper that comes to a similar conclusion, with some great charts and graphs.

Michael Mace, in his post Why is Apple porting its browser to Windows?, predicts a coming battle between companies vying for control of the rich browser interface. He speculates that Apple is porting its Safari web browser to windows as a kind of trojan horse in order to get the full Apple OS layer onto Windows systems.

…The war to come. This could set up a brutal competition in software layers, between Adobe Apollo, Microsoft Silverlight, Sun’s revised Java, Firefox’s platform, and Apple. Google fits in there somewhere as well, but it’s not clear if they’ll try to create their own platform or work with several other players…

Adobe is certainly in the running. Adobe already benefits from a huge adoption rate of flash players and a lot of new web applications are built to run in flash. The other day, I got a demo from a friend who is building an application for a new web startup. He built it using openlaszlo, an open source development framework for Adobe Flash and native web browser Dynamic HTML. It is clean an snappy and has great interactive animations.

On the other hand, I know others who are building exclusively with javascript / DHTML applications, using libraries like script.aculo.us and prototype and intend to stay away from flash or other “lock-in” frameworks.

I don’t like the idea of one company dominating - I believe it will be far better for everyone if none of the commercial vendors win this war.

– –

By the way, after going years with just Adobe Photoshop, I finally caved in to family pressure and ordered Adobe Creative Suite for my kids (educational license from Academic Superstore). It contains Photoshop, Illustrator, Flash, Dreamweaver and InDesign. Here’s their latest creation:

Cosmokitty Magazine, Summer 07
10 Ways to Get More Food from Your Owner! And how to keep it that way!
How Cutestuff Stays Cute. And you can too!
How does he do it? Durango’s scratching secrets: 20 places to go!
Harmless? 15 fantastic and creative ways to get on the counter and not get caught!
(larger view)

The Google Earth Blog recently mentioned an article by Michael Jones, Chief Technologist of Google Earth, in the IEEE “Computer Graphics and Applications” magazine. The article can be downloaded here.

Michael quotes from Rudyard Kipling:

I Keep six honest serving-men:
(They taught me all I knew);
Their names are What and Where and When
And How and Why and Who.

The rest of the article is devoted Google’s vision of “Where”. But I think there is also a hidden meaning in that particular analogy. The poem is from Just So Stories, The Elephant’s Child which is an allegorical children’s tale about the dangers and rewards of ’satiable curiosity (Kipling’s words). Here’s the full text:

I Keep six honest serving-men:
(They taught me all I knew)
Their names are What and Where and When
And How and Why and Who.
I send them over land and sea,
I send them east and west;
But after they have worked for me,
I give them all a rest.

I let them rest from nine till five.
For I am busy then,
As well as breakfast, lunch, and tea,
For they are hungry men:
But different folk have different views:
I know a person small —
She keeps ten million serving-men,
Who get no rest at all!
She sends ‘em abroad on her own affairs,
From the second she opens her eyes —
One million Hows, two million Wheres,
And seven million Whys!

The person small in this case was Rudyard Kiplings daughter, but we could easily substitute “company large and ambitious” in its place. Perhaps ’satiable curiosity is at the heart of Google’s success.

My family and I recently took a road trip from Philadelphia southward. Google Maps wanted to route us through the Washington D.C. beltway, which can be a parking lot at times, so I re-routed us through Fredrick which only added 5 minutes. Google Maps has the ability to add “waypoints” but it is a hassle and you have to know or guess at intermediate addresses, even if you don’t actually want to go to those places.

You may ask why I haven’t gotten one of those nifty in-car navigation modules - maybe I will write about that another time.

For years I have been irritated that Mapquest doesn’t allow you to add intermediate stops to driving directions. I know they could do it if they wanted to. When we were making the first version of Mapquest in 1994, we already had consumer CD-ROMs with very clean and user-friendly methods, usually involving right-clicking on the map. I suspect that AOL (owner of mapquest) has done some sort of focus group that indicated that people don’t care about this feature.

— update - 6-30-07 —–
I just realized that Mapquest added a way to add intermediate stops a year ago. I guess I wasn’t paying attention! My apologies to Mapquest.
— update —–

Well someone at Google didn’t get the memo because yesterday, they came out with an awesome way to add waypoints to driving routes, and it is better than what we were doing in 1994. As far as I can tell, this is the first time an online map is easier to use than the desktop applications from 13 years ago. I think it is an important turning point.Here’s what you do: First, plan your route.

Second, grab the blue “route” line near Washington DC and drag it to Fredrick.

Done!

Phil Conrad, after reading my essay about engineering goodness, pointed me to Jeff Attwood’s blog, “Bridges, Software Engineering, and God”, which nicely demonstrates that software development has very little in common with classical engineering disciplines like Civil, Mechanical or Electrical Engineering.

Attwood concludes that “…Software development is unquestionably a profession, but I don’t think we can learn as much from the fields of mathematics or traditional engineering as is so often assumed…”

I completely agree with him and I share his frustrations with naive comparisons (I am speaking as a mechanical engineer, computer engineer and a software developer).

I think one cause of misunderstanding is that people tend to confuse the professions with the professionals. Even though software development and engineering are quite different, the people in those professions are very similar - engineers are just like software developers. I’m thinking in particular about “creative technical people.” You know the type; they are drawn to engineering and computer science because they like to make things. They are caricatured in literature, movies and TV as the typical inventor-geek.

Of course, engineers and software developers vary in how well they fit this “technical creative” stereotype, and some don’t fit it at all. And some of very the best don’t have formal degrees in their fields but were instead irresistibly drawn to their careers from other professions. My children fit the mold, but in different ways; My daughter is more of an engineer and my son is more of a computer person.

Although engineers and software people must necessarily follow a totally different process for building things, their ultimate value to society is measured in terms of what they have created. This ties in nicely with my observations on engineering goodness; no matter what process you follow to create new things, you should measure your progress against some standard, evaluate how well you are doing and follow strategies to improve your record.This could be said of most endeavors, but for engineering and software development the application of the principal is the same.

I ordered Cinema 4D for my kids who currently are using Bryce for 3D modeling. But I clicked on the wrong button

and received the “CINEMA 4D WIN NON CG STUDENT/PROFESSOR” instead of the “CINEMA 4D MAC NON CG STUDENT/PROFESSOR.” In case you missed it, the kids use a Macintosh (a sweet Mac Pro - the quietest computer I’ve ever owned) but I bought the Windows version by accident. I didn’t notice the difference so I opened the box. Even though the software installs fine on the Macintosh, the serial number in the box won’t work. I found out from the Academic Superstore, the reseller, and Maxon, the manufacturer, that they won’t take a return on an open box but I can pay a $100 fine to switch the license from Windows to Macintosh. I must also sign a document promising not to use my Windows serial number. I tried to persuade them to cut me some slack for being honest but careless, but no dice. Luckily, after much groveling on my part, the reseller agreed to take back the open box for only 15% plus shipping. I am proud that I’m only paying a $55 stupidity tax instead of $100!

Obviously Maxon is concerned about software piracy but it is amazing to me that they haven’t been able to think of a better strategy than this. Software companies have more options than ever for creative distribution of their products, yet they seem to be stuck in the 1990’s. It reminds me of the Recording Industry Association of America’s battles over online music, which I hope will end badly for RIAA.

Cinema 4D is an awesome tool that is used to make movies and TV productions. Here’s one of Jonathan’s latest creations.

In an earlier post, I speculated that one might use the variance between Quantcast and Alexa as a predictor for success. The basis for this was that Alexa toolbar users seem like early adopters. Another possible explanation can be found in the general feeling that Alexa users are heavily represented in Asia. Do a search on Alexa user demographics and you will find a number of blogs and forum posts suggesting this.

If this idea is correct, I think that under some circumstances, you may still view Alexa as a predictor for success since much of the growth in the population of internet users is coming from Asia.

Here’s the latest data on my Wikia watch:

According to Alexa, Wikia’s rankings were

Yesterday: 849
1 Wk Avg: 1102
3 Mo Avg: 1456

In part 1, I used an undergraduate mechanical engineering design competition to introduce the concept of Engineering Goodness.
In part 2, I provided a vocabulary for measuring engineering goodness.
In this final installment I will describe some goodness math, show why most of us aren’t nearly as good as we think we are and then provide some suggestions for improving our odds.

Goodness Math

I’ve defined engineering goodness in terms of a grid of values and percentages and shown why it is difficult in practice to fill out the grid. But pretend that you could actually calculate goodness not just for one project but for every project you have ever worked on. Or you can consider every project your team, company, competitors or industry have ever undertaken. You would get a bell curve (Figure 1):

Figure 1 Goodness Bell Curve

The best thing about this curve is that it lets you think past your current project or problem. To use the familiar sports analogy, you can work on your average without sweating every single game.

Now apply this concept to the coffee can competition (Figure 2)

Figure 2 – Coffee Can Competition Goodness Curve

The curve is skewed over to the “Not so good” side of things because most entries didn’t even meet the primary requirement, which was to pass the finish line. Delorian and Buggy were good and Oatmeal was great.
I think most creative technical people “get” this basic concept but have no idea what their own curve looks like. For instance, we sometimes work within “segments” (companies, industries, etc) where the curve is off to the left. Creating a “great” solution in a “not so good” company isn’t always a great accomplishment.

I have also observed that most technical people think they are on the right side of this bell curve. This tendency of people to overestimate their capabilities seems to be an inherent part of human nature, and has been reported over and over again in books and literature. Sadly we can’t all be above average.

Another thing I’ve noticed is that many individuals, teams and businesses exert little conscious effort toward moving their own curve to the right and making it more narrow (Figure 3).

Figure 3 – Move Your Curve to the Right.

What they seem to be missing is that the overall value of the solution is not linear as you move along the horizontal axis (Figure 4)

Figure 4 – The Value of Goodness

In fact the difference between a good solution and a great solution can be a huge. Depending on your key metric, it could be millions of dollars, thousands of man-hours, millions of unique visitors to your site or many customer satisfaction points.

If Figure 4 is correct, then small amounts of effort expended in moving your bell curve over to the right can mean big payoffs in the long run. Unfortunately, these payoffs are not easily quantifiable and it is difficult to establish a positive correlation between the initial actions and the end result. Further, it requires a long view of events because results will only show in aggregate over a number of “solutions”.

Now lets look at the Coffee Can Competition one more time (Figure 5)

Figure 5 – Coffee Can Competition Goodness and Value

This chart nicely sums up my original observation about Oatmeal: “No matter how you weight the engineering factors, the oatmeal box was far superior to other designs. It took less time to build, cost less, had less parts, was more reliable and it was faster. It was obviously a great solution. “

Steps to Improve your Odds
Anything you do to move your curve to the right and reduce the variability is usually worth the effort! Here is a short list of ideas:

• Follow a disciplined creative design process – there is plenty of guidance on this subject

• Challenge fundamental assumptions

• Always evaluate multiple solutions in parallel

• Measure against competitors (even if there are no direct ones)

• Don’t trust your instincts until they are measurably proven right

• Don’t assume your solution is good just because it works – let the bell curve be your guide

Engineering Goodness, part 1

Engineering Goodness, part 2

This is a story of the first years of Mapquest, told in order to illustrate a point about the power and weakness of ideas. Retelling any event is risky because memory is imperfect and always colored by the brush of personal bias, so with apologies to those who remember things differently…

The idea
In early 1995 Mosaic and Netscape (created by Marc Andreesen and others) were the most popular browsers, Yahoo was still the hobby of two Stanford grad students, and many businesses were unsure about whether to get a domain name or not. The company I worked for, GeoSystems Global Corp., was a cartography company that had a small group of software developers that among other things built very cool trip routing and CD-ROM mapping applications for companies like AAA, National Geographic and Comptons Encyclopedia. I was an enthusiastic proponent of the new world wide web and so with a little persuading, I got permission to build a prototype to demonstrate the feasibility of using a web browser to display and manipulate maps. Travis and I built it by hacking one of our CD-ROM mapping applications to snapshot thousands of GIF image tiles at three different “elevations”. Then we wrote a quick CGI application to navigate the map. Later on, more people joined the team and we ripped code out of our other applications to make the first map servers and web front end software. A big part of the project was back end work - map data licenses and data processing. Our secret code name was Project Bandwagon and with much effort from a group of talented and commited technical and business people, we eventually launched as mapquest.com on Feb 5, 1996 (see the launch T-shirt below). The company renamed itself to Mapquest a year or two later.

The environment
Early on, there were mixed feelings about the project within the company. Some complained that the web was a huge step backward for users. Our CD-ROM products were way more interactive; you could right mouse click, drag and drop, shift select and change all sorts of layer parameters, so why would anyone want to use a poky 28k or 56k modem with a buggy web browser to do the same thing you could do with a cheap CD? Others maintained, myself included, that there was no business model. I wanted to somehow find a way charge money for each map (we eventually made money with advertising and business services). Others felt we were out of our core business which was publishing and IT services.

But our leaders made some unconventional decisions that paid off handsomely in the long run. The site generated a lot of buzz and was on Netscape’s What’s Cool page for ages. Our traffic grew day by day and our servers didn’t catch up for at least a year. We kept adding equipment until the corner of the office was uncomfortably hot. One day, Brian tripped over an extension chord and the whole site went down for about an hour. I distinctly remember the day we generated 1000 maps per minute; we were all standing around the monitor looking at the summarizer log file as it scrolled down the screen waiting for the number to creep past the magic number. The log also showed our queue wait time which indicated that our servers weren’t handling the load very well.

The competition
There were competitors in 1995 and 1996 but they never amounted to anything significant. One company, a private firm that published both paper maps and a very popular mapping CD-ROM application, demonstrated an interactive map on their web site. This company could have easily created something like Mapquest but they never did. I guess they were making too much money with paper and CD-ROMs to try something new. There was another company that created a download application (presaging Google Earth?) that let you add points, modify layers and annotate your maps. At first I was quite concerned that they would be a big competitor, but they quickly dropped off of the radar. I think the download-install process was too big of a barrier for consumers (I’d love to know what happened to them).

Later on, more serious competitors appeared, including Microsoft and Vicinity (later bought by Microsoft), but by that time we were already established as the place to go for maps and driving directions. Yahoo Maps and Google Maps came even later.

Why a good idea isn’t good enough
Those early competitors had the right technology and plenty of people with good ideas, but they never made it. So what was it about our group that allowed us to be the ones to create Mapquest? I think the answer is a familiar one - it was a critical confluence of factors. In this case those factors were:
* We took technical risk
* We took business risk
* We had good timing
* We were a venture backed company

The right conditions
Afterward, I worked at a number of internet startups. Some were spectacular failures, others did ok, but none were like Mapquest. The experience left me with an appreciation for how difficult it is to create the right conditions for commercially successful innovations.

Marc Andreesen and Fred Wilson have recently written some interesting notes on the investment logic of venture capitalists; how most startups fail and the ones that succeed pay for the ones that don’t. I think the story of Mapquest and its early competitors is a graphic illustration of that principal.

“Candy Mountain! Fill me with sweet sugary goodness” – Charlie the Unicorn

In a previous post, I wrote about what I learned from an undergraduate engineering design competition. In this installment, I explain why I think that most engineers and software developers don’t know how good they are. In a future post I will show why I think most of us are rarely as good as we think and suggest some methods for improving our average.

While the example is drawn from a bunch of mechanical engineering students (myself among them), it applies equally well to any technical creative endeavor; especially to software development.

Why you don’t know how good you are

The superficial results of the coffee can competition were:

• The ramp stopped most entrants: only three or four successfully completed the course
• The difference between the fastest entrant and the next fastest was an order of magnitude: 7 sec, 65 sec, 240 sec

But that only tells part of the story. Table 1 ranks entrants by other key design factors, with 10 being the best and 0 being the worst. I’ve created six design archetypes into which most of the designs fit neatly.

Table 1 Design Factors

Based on these rankings, you can create a weighted average in order to quantify the success of each design. Table 2 shows results weighted towards “test results”. In other words, “time to complete” is more important than other factors such as cost and reliability.

Table 2 - Weighted Average Test Results

If you weigh “Time to Market” (e.g. how many hours it took to build and test) you would get something like Table 3.

Table 3 Weighted Average Time to Market

I have identified a few patterns of failure (sometimes called anti-patterns) in the various entrants:

• Failure to “Paradigm Shift” :Turbine, Flywheel, Rubber Band
• Poor execution : Other electric vehicles
• Gold Plated : Delorean
• Good job! : Buggy
• Great Job! : Oatmeal

My entry was in the Failure to paradigm shift group. I think all of the terms are self-explanatory.

No matter how you weight the engineering factors, the oatmeal box was far superior to other designs. It took less time to build, cost less, had less parts, was more reliable and it was faster. It was obviously a great solution. But what about the other successful entrants - were they good or great? More importantly, when you finish a project, how will you know whether you did a great job?

The saying goes, “Great is the enemy of good enough,” but in this discussion great is exactly equal to good enough. More specifically, the best engineering solution is the simplest one that meets the requirements. So it should be a simple matter of making a few tables (like above) and adding some weighted factors and you will know how you did, right? Unfortunately, there are two major problems with this.

Firstly, if you are doing something new or inventive, you can never know all the requirements because your customers can’t articulate what needs to be invented. Malcom Gladwell does a great job of discussing this type of thought process in his book Blink: The Power of Thinking Without Thinking.

Secondly, in real life we aren’t all given the same set of rules and asked to solve the same problem, so it is often difficult, if not impossible, to find any concrete “competition” with which to compare ourselves. For example, there is no direct comparison for an internal IT project for a customer service application. If it is over budget and one year late, how do you know whether the planners were too optimistic or the implementation was sloppy and inefficient? Conversely, if it is perfectly on time and budget, how do you know that it didn’t cost ten times what it should have cost?

Here are a few more ways you might be blinded from the truth:

• Project Hell. Often things go so badly wrong that there is no sorting out what actually happened. When this happens, it usually makes no sense to try to make sense of the disaster.
• Lax standards. Sometimes people don’t care whether they got the Oatmeal Box or the Delorian, even though they should care.
• Technical Obfuscation. Technical people are people too. As in any population, there are always a few who will hide behind technical jargon and plausible but false explanations.

For all of these reasons, the sad reality is that the vast majority of engineers and software developers will rarely know whether what they created was great, good or bad.

Fortunately, there are ways to deal with this problem, which I will blog about later.

Engineering Goodness, Part 3

Engineering Goodness, Part 1

In an earlier post, I mentioned some new ways to avoid using lollypops, but I forgot an important one that was announced at where 2.0. As Stefan Geens recently mentioned, Geocommons has some great ways to visualize data. For instance, here’s a map of immigration in the US:

GeoCommons is designed to be used b regular people to do this sort of mapping.

Here are a few more notes from the 2007 Where 2.0 conference .

Google’s pride of ownership
Michael Jones, the CTO of Google Earth was a very entertaining speaker. He has a real tricorder from the original Star Trek show and isn’t afraid to use it. He reiterated Google’s aim to “…organize the world’s information and make it universally accessible and useful…” and I couldn’t help ironically thinking that he said it with a certain pride of ownership. Just the kind of thing someone says after purchasing a valuable but rundown building – “it’s mine now and think how much nicer it will be when I clean it up.” Don’t get me wrong – I like Google (may Google be great and live forever) and use many of their products. Some of my best friends work for Google. But sometimes it is scary what they can do.

Open Map Data
I’m very impressed with Open Street Map, an initiative to make a creative commons map of the world. In the US we take for granted some of the access to cartographic data that we have. In other parts of the world (e.g. UK, China) the data is government owned and tightly regulated. These folks are using open source tools to create a community of amateur cartographers. Their goals are ambitious but their strategy is to take small steps first.

Closed Map Data
One of the most entertaining talks was by Ian White of Urban Mapping. He spoke about the difficulties in obtaining theoretically public data (such as metro stop locations) from governmental bureaucracies in the US. Hilarious but sad.

API
Everyone was showing off their web services. The new Mapquest Actionscript API for Adobe Flex looks very interesting. It allows you to quickly make very interactive mapping applications that run within the flash virtual machine. As I mentioned in my earlier post, ESRI also showed a very neat API for adding GIS like functions to maps.

Something in the air
The show had some of the feeling of those early Internet World conferences. Though it was much smaller and definitely less pompous, there was a charge in the air. There were at least a few VC’s in attendance. It feels like 1998 all over again.

I just returned from the Where2.0 conference. One of the speakers made the observation that “pushpins are the cartographic measles of our time“ during her somewhat condescending presentation on cartographic style and design. I have to say that I agree with her on this point. She was talking, of course, about the ubiquitous icons found splattered over web rendered maps denoting the presence of anything from a car dealer to a National Geographic episode.

I condescendingly call them lollypops and I would love to see most of them go away. It has been 12 years since mapquest became the first mainstream mapping site and in all of that time the only novel thing that has happened to those little splotches is that somebody put a drop shadow underneath them.

Happily things are beginning to change. During the Where 2.0 conference there were at least three pretty demos that offer hope:

1. Yahoo Research displayed a great tag based map
   
   
2. ESRI showed some cool web service APIs that can be used to do GISey things to your maps. The GIS community are masters at avoiding lollypops and have been using clever visualization techniques for years.
3. The National Holocaust Museum showed some very striking and powerful visualizations of the Darfur crisis using Google Earth. Aside from the normal icons, there are bar charts showing population of displaced persons.

Here’s a follow up to my last post about Alexa

Notice that Alexa toolbar users are much more interested in Wikia than the general internet audience. I’ll watch this trend in the coming months to see whether the early adopters have chosen wisely.