After watching the documentary I decided I wanted to do the same thing. How cool would it be to drive a vehicle that painted with its tires? What kind of artwork could I come up with?

Not wanting to take forever on the project, I moved quickly to create a gameplay prototype. The first problem I ran into, though, was that to reuse my existing 3D codebase would require more work than I wanted to spend on a prototype, particularly since I needed to integrate a physics engine to get the effect I wanted for the vehicle dynamics.

So, I took a look at Flash, noticed that there were a few 3D render engines and a few physics engines, and figured "why not?" Granted, I've never used Flash before, but I went to Adobe's site, downloaded the Flash 30-day trial, and went to town.

A few days later, and I have a prototype of CarPaint: http://www.gamesunplugged.net/CarPaint3D.html. If you check it out, be sure to click the Help button to see the controls and instructions.

It turns out that BMW also created an iPhone App off this idea – something I just found that out as I searched for the name of that documentary for this post. I'm going to download it and check it out. In the meantime, I'm going to let the Flash version cook for a little bit as I look at porting it over to a Windows-based application using my engine – and of course consider I'll consider the iPhone App route.

Everyone wants to be successful. Entrepreneurs want successful businesses. Athletes want to win. Engineers want to build perfect solutions.

The problem is that most of us try to be successful through grand strategies and big plays. Entrepreneurs hold off on starting a business until they have that "killer app" idea. Baseball players try to hit the home run. Engineers try to design a solution that will address any possible situation. Meanwhile, another company comes out with a better "killer app", the baseball player strikes out trying to "swing for the fence", and the engineer ends up with an over-complicated solution that has to be scrapped because it doesn't work.

As JD Meier reminds us, the key to winning isn't the big play. The key to winning is to build momentum off a series of small wins. By focusing on small goals, small tasks, and small features, we allow ourselves to adapt to change, to measure tangible progress, and to celebrate successes early and often.

One ships games, the other ships students and a designs a sandbox game (termed “a curriculum”) in which players (termed “students”) can build the right collection of assets and resources (termed “courses” and “a portfolio”) to take them toward their goals of entering the game industry.

The funny part to me is that you could say the same thing for a Lead Software Engineer. Or an Artist. Or a Director. Or a Construction Worker. Or a CEO. It's all the same.

Everything in our human world is a system that follows one very basic pattern of all systems: input-process-output.

In the quote above, the patterns are players-build-goals and students-courses-industry. Consider functions: parameters-implementation-return value. Silly, but it works.

One of the "tricks" I've learned in any problem solving situation is that when I come across a difficult problem, or I'm having a hard time coming up with a solution, I always refer back to the input-process-output pattern. Doing so helps frame the problem into manageable chunks, or at least gives me a few manageable chunks to break down further.

Besides, going back to the original quote, I enjoy finding parallels between two seemingly different topics. The neat thing is that if you follow the basic system pattern, then you can usually find those parallels quickly.

So, anyone want to take a stab at tying together two completely different topics through the basic system pattern? If so, put it in the comments. I'll start.

Baseball: hit-run-score

Basketball: dribble-shoot-score 

Okay, not completely different.

Do you challenge the conventional wisdom? Or do you tend to stick with what you know?

It’s in our natural human tendency to stick with what we know, despite knowing that moving toward the future requires us to challenge today’s ideas. It’s part of our survival instinct to stick with what we know, but this mindset is also what has held us back throughout our history.

Challenging the conventional wisdom is important to make progress. In software, that means trying new designs and retooling technologies to solve problems. It means moving beyond the mainstream thought and breaking the mold. It means finding the answer to one simple question, “Why do we do things this way?”, and coming up with a better solution.

Recently I came across a story that supposedly comes from engineers at NASA. It’s probably been around for a while, but reading it reminded me why it’s important to challenge the status quo:

Does the expression, “We’ve always done it that way!” ring any bells? The US standard railroad gauge (distance between the rails) is 4 feet, 8.5 inches. That is an exceedingly odd number. Why was that gauge used? Because that is the way they built them in England, and English expatriates built the US railroads. Why did the English build them like that?

Because the first rail lines were built by the same people who built the pre railroad tramways, and that is the gauge they used. Why did “they” use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons, which used the same wheel spacing.

Okay!

Why did the wagons have that particular odd wheel spacing? Well, if they tried to use any other spacing, the wagon wheels would break on some of the old, long distance roads in England, because that’s the spacing of the wheel ruts. So who built those old rutted roads? Imperial Rome built the first long distance roads in Europe (and England) for their legions. The roads have been used ever since.

And the ruts in the roads? Roman war chariots formed the initial ruts, which everyone else had to match for fear of destroying their wagon wheels. Since the chariots were made for (or by) Imperial Rome, they all had the same wheel spacing. The United States standard railroad gauge of 4 feet, 8.5 inches is derived from the original specification for an Imperial Roman war chariot.

Specifications and bureaucracies live forever. So the next time you are handed a specification and wonder what horses butt came up with it, you may be exactly right. This is because the Imperial Roman war chariots were made just wide enough to accommodate the back ends of two war-horses.

Now, the twist to the story…

There is an interesting extension to the story about railroad gauges and horses’ behinds. When we see a Space Shuttle sitting on its launch pad, there are two big booster rockets attached to the sides of the main tank. These are solid rocket boosters, or SRBs. “Thiokol” makes the SRBs at their factory at Utah. The engineers who designed the SRBs might have preferred to make them a bit fatter, but the SRBs had to be shipped by train from the factory to the launch site. The railroad line from the factory happens to run through a tunnel in the mountains. The SRBs had to fit through that tunnel. The tunnel is slightly wider than the railroad track, and the railroad track is about as wide as two horses’ behinds. So, a major design feature of what is arguably the world’s most advanced transportation system was determined over two thousand years ago by the width of a horse’s ass.

Embedding non-image data inside an image isn’t a new trick, but some reddit commenters are finding that data for a Spore creature is uniquely embedded in the .PNG file that can be downloaded from the creature’s Sporepedia entry.

While some commenters originally discovered data embedded in the alpha channel of the image, they now believe the data is embedded in the RGB channels as well, possibly giving up to 8k of extra data storage in some estimates.

Again, storing data in an image is nothing new, but as Troy Gilbert points out, “it’s a very clever, modern, web way of handling it. It allows for trivial sharing by the user through whatever means they’re accustomed to because sharing an image is an almost universal feature of any collaborative software. So, user’s can attach the thumbs to their e-mail, or post them to their Flickr account, or put them on Facebook or their MySpace page, or send them in an IM.” Then when a friend opens the image inside the game, they’ll get the creature.

It’s definitely an inspiration for some work I’m doing, and you can bet I’ll be considering ways to incorporate this into some of my solutions. It also kind of gives a new meaning to file sharing.

The trip was good, relaxing, and I hardly thought of events back home. I went back to work today with a fresh perspective and readiness I haven’t had in a while.

I read two books and got about halfway through on a third. One of the books I read was The Myths of Innovation, by Scott Berkun, who is also the author of my favorite project management book, The Art of Project Management.

In The Myths of Innovation, Berkun looks at the history of innovation, including the software world (he worked on Internet Explorer in the 1990’s), to reveal how ideas truly become successful innovations. It was a great read, and I especially appreciated Berkun’s framing of innovation in the context of the history of the world and all the great minds and companies that have been considered innovators.

I’m sure in the future I’ll have more to say about this book, and I plan on reading it again at some point so I can take notes. One paragraph in particular stood out to me, though, so I thought I’d share:

The best advice I’ve read on starting creative work comes from John Cage, the most innovative composer of the 20th century, who said, “It doesn’t matter where you start, as long as you start.” He means that there can be no perfect beginning: it’s only after you start – no matter how roughly – that you can evaluate and build on what you’ve done, shift directions, or start over with the insight and perspective you’ve gained in the process. Innovation is best compared to exploration, and like Magellan or Captain Cook, you can’t find something new if you limit your travels to places others have already found.

Innovative thinking in the corporate environment is not a big bang idea like the world’s corporate marketers would like you to believe. Innovative thinking is a process of continuous value improvement for the customer, the company, and the employee, and for innovation to be effective in a company the process needs to occur at all levels, from the CEO all the way down to the lines of code we write and the widgets we make.

Put another way, innovation is a mindset, not a result.

According to the article, Google strives to achieve a balance between chaotic ideation and rigorous, data-driven idea evaluation. Note the difference: ideation vs. idea evaluation. Ideation is the process of forming ideas. Idea evaluation is the determination of trhe value of an idea. One is creative. The other is analytical. Striking a balance between these competing forces is critical to any innovative organization, and it’s something Google does well.

In addition, Google’s leadership ensures the organization has a clarity of purpose and a high level of attention to detail. Many of us have heard the stories of Google’s seemingly chaotic culture, but that chaos is actually well managed through clear, simple directives.

Other elements of Google’s innovation system include:

• Strategically patient management with a farsighted mission less concerned with short-term profitability
• A proprietary infrastructure that gives control over design and emergent technology (BigTable).
• An accelerated product development lifecycle where the prototype to release process considers marketing and testing the same thing.
• Support for 3rd party development provides a continuous feedback loop for iterative improvement.
• Ruling its technical ecosystem, knowing how, when, and where all products are being used.
• Maintaining architectural control while allowing 3rd parties to innovate and experiment before entering partnership agreements.
• An organizational design in which innovation flows from the bottom-up.

As large as Google has become, it is still a fairly nimble creature and there’s something for software companies and their engineers to learn from it:

• Focus on long-term goals and maneuver toward them in the short-term.
• Build technologies for the long-term.
• Build products to start usability testing as soon as possible.
• Embrace successful 3rd party organizations and technologies.
• Demonstrate an ability to manage yourself and your projects.
• Give everyone the opportunity to present ideas and allow them to take ownership over those ideas.
• Provide tools and an environment for collaboration.

And that’s just a quick list of lessons. There’s plenty more, and in reality a level of microcosms exist in the macrocosm of Google’s innovation machine. For instance, engineers can use these lessons in innovation for their personal work, while managers can use them for their own organizations. Of course, companies can institute these practices across the board, as well.

The bottom line is that innovation isn’t a pipeline or a process or some magic formula. It’s a holistic system of balance between creativity and analysis that works best through an organization encouraging collaboration, efficiency, and a sense of managed chaos. It’s not easy to achieve, but as Google has demonstrated it’s very possible. I’m sure a number of companies would do well to pick up a tip or two from them.