Tech 4D

When Tolstoy wrote War and Peace in the 1860’s, he sprinkled it with side chapters where he ranted against the historians of the day. He complained that they told history as a progression of major events precipitated by “great men” when in fact history is a much more complicated progression of cause and effect. Tolstoy was particularly sarcastic when he highlighted the conflicting conclusions of various historians (for instance English vs. French vs. Russian). At one point, he proposed applying the scientific method to history, asserting that a complete understanding of an event could be obtained by slicing that event into smaller and smaller pieces, in exactly the same way that a math student performs integral calculus.

Perhaps Tolstoy’s idea can finally be realized by using the power of mass collaboration?

—-

I’m posting this from Cashiers, North Carolina. I wanted to visit some local civil war battle fields on the drive home (Interstate 81 in Virginia), but it is turning out to be quite difficult to find the information on the web.

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.

Despite its many innovations, Wikipedia is still a very traditional encyclopedia, following a pattern that was laid down in the late 1700’s by Diderot and others. Each article summarizes a particular topic, discusses details and provides references. Each article is a linear discourse that starts at beginning and reaches a conclusion about the topic, which in wikipedia is termed “consensus.”

The problem is that there can be only one consensus (as they said in Highlander) . One of the biggest criticisms of Wikipedia is that its articles are not accurate. Accordingto wiktionary, accuracy means “…exact or careful conformity to the truth...” Since everyone has a different view of what is true and false, by definition every article in Wikipedia is inaccurate.

It turns out that this is nothing new. Encyclopedias have been controversial since the very beginning. For instance, the encyclopedists in eighteenth century France were considered to be radicals, distorting the truth in order to weaken the might of the catholic church and the monarchy.

Wikipedia proponents feel that it harnesses the “wisdom of the masses” in order to optimize the truth of articles. On the other hand, critics could claim it optimizes the truthiness of articles.

I believe the biggest problem with Wikipedia is the encyclopedia format itself because most interesting topics defy consensus. Take my original example of the American War of 1812: was it the result of upstart United States taking advantage of Britain’s preoccupation with Napolean or was it U.S. finally fighting back after years of oppression? The answer is “yes to both.” You might argue that a skillful writer can illustrate both viewpoints in a single article, but that is an over-simplification. Even seemingly objective areas such biology and physics can be fantastically controversial.

Why does Wikipedia need to be like this? Is Wikipedia an anachronism; an eighteenth century idea repacked as a modern day internet phenomenon? What would happen if Wikipedia somehow removed the imperative for consensus, instead embracing and requiring differing viewpoints? It certainly would no longer fit the established pattern of an encyclopedia, but perhaps that pattern is no longer useful.

I’ll conclude with a quote about history and historians from Leo Tolstoy’s War and Peace, Book 11 (which I am reading and enjoying right now):

The first fifteen years of the nineteenth century in Europe present an extraordinary movement of millions of people. Men leave their customary pursuits, hasten from one side of Europe to the other, plunder and slaughter one another, triumph and are plunged in despair, and for some years the whole course of life is altered and presents an intensive movement which first increases and then slackens. What was the cause of this movement, by what laws was it governed? asks the mind of man.

The historians, replying to this question, lay before us the sayings and doings of a few dozen men in a building in the city of Paris, calling these sayings and doings “the Revolution”; then they give a detailed biography of Napoleon and of certain people favorable or hostile to him; tell of the influence some of these people had on others, and say: that is why this movement took place and those are its laws.

But the mind of man not only refuses to believe this explanation, but plainly says that this method of explanation is fallacious, because in it a weaker phenomenon is taken as the cause of a stronger. The sum of human wills produced the Revolution and Napoleon, and only the sum of those wills first tolerated and then destroyed them.

“But every time there have been conquests there have been conquerors; every time there has been a revolution in any state there have been great men,” says history. And, indeed, human reason replies: every time conquerors appear there have been wars, but this does not prove that the conquerors caused the wars and that it is possible to find the laws of a war in the personal activity of a single man. Whenever I look at my watch and its hands point to ten, I hear the bells of the neighboring church; but because the bells begin to ring when the hands of the clock reach ten, I have no right to assume that the movement of the bells is caused by the position of the hands of the watch.

Breaking news! - Earlier I pointed out a trivial example of conflicting editorial views on history within Wikipedia. Recently, someone resolved the conflict by completely deleting the entire sentence:

Smaller scale conflict occurred in North America with the USA finally reacting to years of British assaults on US shipping, but the conflict ended inconclusively.

The poster gave the following reason:

I edited a line about the war of 1812, because it isn’t actually relevant to the Napoleonic Wars.

Some people will disagree with this line of reasoning and so the attempt to resolve the conflict has actually created a new conflict. Luckily there is a mostly reasonable discussion of the problem on the talk page and I suspect we haven’t head the last of this ongoing drama.

Wikipedia’s detractors like to point to this type of conflict as an example of the problems with community driven content, but to me it is a beautiful thing. Here you see a small group of regular people who, in the process of creating a summary of the Napoleonic Wars, are interacting and learning in a deep, personal and permanent way. At the same time they are creating something that is pretty good, and it is useful to many, many other people.

“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.

Last week, Fred Wilson wrote, in Whats wrong with Alexa that he isn’t sure Alexa can be trusted with anything.

I agree that there are some large inconsistencies with Alexa, but you can still get some useful information by cross-checking Alexa with Quantcast (or comScore if you can afford it). For instance, here’s a correlation of the two sites Fred talked about, digg and del.icio.us;

Table 1

Assume that quantcast is more accurate than alexa (I think there are good reasons). From Table 1, you can see that alexa overstates the importance of del.icio.us and mildly overstates digg.

Now lets look at some other sites:

Table 2

Based on Table 2, I would throw away the alexa results for mapquest, history.com, discovery.com and nationalgeographic but keep information from the others.

Based on these comparisons I think I can also infer something about the demographics of Alexa toolbar users: they are classic “early adopters”. It would be very interesting to make correlation of alexa to comScore or quantcast and then calculate whether alexa toolbar users are good predictors for success of a new web trend or property.

Conversely, you might use this effect to predict failure as well. Take a look at mapquest vs maps.google.com (this is really scary). A Yahoo press release quotes comScore Media Metrix saying that, as of April 07, mapquest traffic increased by 3% while google maps traffic increased by 49%. But look at the alexa chart for mapquest:

During that time mapquest suffered a 50% drop in alexa toolbar users. Unfortunately alexa doesn’t report on subdomains, so I can’t get data on maps.google.com, but if I could, I suspect I’d find a large jump in usage of google maps by alexa toobar users.

So this data tells me that the early adopters that used to be mapquest users are leaving in droves while at the same time mapquest is adding new users who aren’t early adopters. This isn’t a good trend for any web property. On the other hand, there is a huge difference between the quantcast ranking (174 vs 13) and mapquest numbers, so perhaps alexa toolbar users never liked mapquest and it is no big deal if a half of them leave in one year. Or maybe something else is going on?

I’m an early adopter (I started using google maps in Feb 2005 when someone had to tell you about it) and I’m sorry to say that I don’t use mapquest very much any more.

(Thanks to Matt Owens for helping me with the data)

I’m amazed at the different ways in which the internet and Moores Law continually enhance and disrupt our society in new and interesting ways. Lately I’ve joined in the debate over cyber charter schools in my home state of Pennsylvania. Pennsylvania currently leads the US with our innovative cyber charter schools, but there is a movement afoot to cripple or dismantle them in favor of the status quo public schools; PA House Bill 446.

I think people just don’t “get it” yet. And that is completely normal! I was part of the original team that created mapquest.com, an innovation that came from Lancaster, PA - NOT Silicon Valley. We created mapquest in 1995/96, long before high speed internet, Google and YouTube (as of May 07, mapquest is still ahead of YouTube). At that time, we had many detractors who could not understand why anyone would want to use a slow modem and clunky personal computer to get driving directions or find nearby businesses, but we proved the doubters wrong. Like mapquest, many people cannot see how cyber charter schools will work in our future but it is a future worth working for.

There has been a lot of posturing and polemics from both sides, including an absurd opinion piece in the Philadelphia Enquirer.  The closest thing that I’ve found to a netutral treatment of the subject is in the Lancaster Intelligencer Journal.

I believe the real issue is that traditional public schools suffer from a very high fixed overhead and cannot respond to the rapid fluctuations in student populations inflicted on them by cyber charter schools. Conversely, the cyber charter schools, with their low overhead and technology focus, can quite easily ramp up and down in response to demand and thus are more free to take risks on innovative programs. Traditional schools are like General Motors and cyber schools are like Silicon Valley. Just as with GM, public schools struggle to deal with the pace of our times, while cyber charter schools, like the entrepreneurs in Silicon Valley, are naturally responsive. Just as in the business world, our public policy should support BOTH institutions and acknowledge the strengths and weaknesses of each!

So how do we do that? One way to deal with high fixed overhead is to amortize costs over time. Why not provide relief to to public schools by spreading the cost of change over three years instead of one year? The mechanisms are already in place, since the current costs are calculated by averaging the number of students over the past year. This would let districts make and keep long term commitments while still allowing cyber charter schools to continue to serve in their own niche. This type of program would provide stability for our present while still encouraging innovation for our future.

When I was a mechanical engineering student, I joined a five state regional A.S.M.E. design contest. The challenge was to make a coffee-can-shaped cylinder roll, under its own power, down a 15 foot track, climb a steep little ramp, pass a finish line, then roll back, all under its own power. The fastest vehicle to complete the course would be proclaimed the winner.

I figured this simple little task was perfect for me, being a creative, clever fellow, with good grades. I knew that, if you are smart and creative and approach a design problem with an open mind, you will eventually find the best answer. I was confident my design would be superior to all others. In fact, the simple little task was perfect for me, but not in the way I had envisioned - it taught me a lesson that has shaped my behavior ever since.

My friend Mike and I teamed up to work on the project. We decided early on in the design process to forsake the conventional wisdom of using an electric motor, feeling that we could transcend the pack mentality and come up with something truly revolutionary. Our idea involved planting a ridiculously overpowering gasoline model airplane turbine inside the can. A complex series of baffles and levers would manage steering and reversing. The scheme might even have worked if we could have figured out how to prevent the propeller from sucking the whole contraption toward one wall and subsequently choking itself of air.

Our friend Andre’ approached the problem more pragmatically. He knew the real problem was to maximize the power to weight ratio, so he focused on reducing weight rather than increasing power. He was very good at model building and constructed a beautiful, meticulously crafted wooden device that was light and fast. As the six or eight weeks of design and development drew to a close, I began to see that his conventional, but well executed cylinder was much more effective than our flying can. I wasn’t completely deflated, though, because the flying can was still pretty radical and it did some things very well. Besides, if we couldn’t win, then Andre’ would!

When the great day arrived, many students piled into a few cars and drove to the neighboring evil-rival university to witness the combined industrial might of the next great generation of engineers. There were 10 or 15 schools represented, each with a broad range of designs.

Someone even had the nerve to come up with the turbine idea - baffles and all! His version didn’t work either. Before the competition, all of the devices were laid out in a display area like so many monster trucks awaiting the axle swapping, gear grinding action action action of a tractor pull! The event, however, more closely resembled a demolition derby because only five of the 20 or so entrants even completed the simple little task.

The combined efforts of all of the entrants represented hundreds of hours of devoted labor, yet only five of us even arrived at a workable solution. Andre’s design was one of the five, but he didn’t win. In the display area, nestled among the microprocessors, gas engines, aerospace aluminum, delicate wood and high strength steel was a completely homely, unpretentious cardboard oatmeal container which contained a cheap little radio shack electric motor taped to a pencil and a spool of thread. It couldn’t compare in looks to some of the more elaborately constructed entries and it certainly wasn’t high-tech. But when its owner placed that oatmeal can on the track and let it go, we all knew that we had been out-classed. That can practically flew down the track, stopped on a dime and flew back to its master. The performance wasn’t just a little bit better than the competition - it was almost 10 times faster than the nearest rival was.

Afterward, we listened with awe and respect as the winner demonstrated his device. The beauty and elegance of his design was obvious once he described it to us, but we hadn’t thought of it ourselves. Hundreds of students in five states had been given the same set of design requirements. Among all of these participants, he alone had come up with a design that was overpoweringly superior to anything else: much simpler to build, 10 times faster, and much more reliable.

Here’s a diagram of the device.

The entire parts list is: cardboard oatmeal box, pencil, pin, two spools, thread, cheap radio shack motor, two AA batteries, wire, scotch tape. Wow.

I didn’t despair of ever achieving such greatness and virtue, rather I had something to shoot for. I was forced to concede, however, that I wasn’t going to get the right solution every time. Since that competition, I have worked in many fields and on many different projects. When I finish something, I look upon it with a critical eye, enjoying what I have accomplished but not assuming that I got it right just because it works. I have had a few successes and a few failures, but through it all, I have been guided and directed by that oatmeal box.

I’ll present a statistical analysis of the competition in a later entry.

Engineering Goodness, part 2

Engineering Goodness, part 3

Here’s a great example of editorial differences of opinion about history within the wikipedia community, this one relating to the US / Britain War of 1812 as it relates to the Napoleonic Wars

• Revision 1

Smaller scale conflict occurred in North America with the USA attempting to take advantage of Britain’s pre-occupation with Napoleon and invade Canada, all attempts, however, were defeated.

• Revision 2

Smaller scale conflict occurred in North America with the USA finally reacting to years of British assaults on US shipping, but the conflict ended inconclusively.

So who is right? I guess it depends on who you are…