By Example

Microsoft's recent introduction of Live Mesh is a perfect example of a core difference between Apple and Microsoft. Apple is, at heart, a product company. Microsoft is, at heart, a platform company. Both produce products and platforms, but the way they approach the problem and communicate with developers is decidedly different.

With Live Mesh Microsoft says, "Come, build on our platform and do amazing things!" What is the oft cited example for using Live Mesh? Multi-device synchronization of data. Now, to be sure, this is a big and very hard problem to solve. In fact, I really wish Apple's Sync Services were much, much better, but do you wake up in the morning thinking, "Man, I really have a Multi-device synchronization problem?" Most people don't. What they do think is, "Man it's great that when I put stuff on the web, I can get it wherever I am. All I need is a web browser." You see, syncing folders or sharing data across devices isn't top of mind in the way a developer thinks about it. Microsoft's challenge is mapping their platform to real problems in a persuasive way.

Contrast this with Apple's normal product focused pattern. First they release a product that solves a real, tangible problem people have. Say, "I hate it that I have to carry around my iPod and my Cell phone everywhere!" or "Man I wish I could buy that cool song I just heard, right now." or "I have so many digital photos, I wish there was an easy way to do something cool with them." or "Man I hate it when I loose files on my computer, I wish I could just go back in time." To solve these problems Apple, like Microsoft, has to build a platform, but this platform is built for a product first, which they use and improve. Then when they talk to developers they can say, "Did you see this cool thing we just did? You can do the same thing or even something better! Here's how we did it..." It's the difference between saying, "Here are the tools, let me show you how to use them." and "I used these tools to do this great thing. Let me show you how and maybe you can do the same thing." Ultimately, it's leadership by example.

Another great example is Apple's use of the Cocoa APIs in their own applications. Apple builds amazing products and then is able to say to developers, "We used the same APIs available to you today!" Contrast this again to Microsoft. Windows Vista was released with some remarkable new C# APIs. Many of them very cool and very interesting, but what is Microsoft Office written in? C and C++. What APIs does Office use? A multitude of Office only APIs and libraries shared among the applications. Does this hurt C# and the new "WinFX" platform "street cred"? I think so.

Ultimately, Apple and Microsoft are trying to solve many of the same problems, but the path you choose while logical to you, may not be so logical to those you most need to persuade and inspire. No one can argue with the results. For me Apple's "solution first, platform second" approach makes for easy understanding of new ideas as well as providing the activation energy needed to try something new.

Heuristically Thinking

You don't have to understand calculus to appreciate this entertaining story:

A teacher, trying to explain what a theory is, asked this question: “If you take a letter half the distance to a mailbox and stop, then start over going half the remaining distance and stop, then repeat the process over and over, theoretically will you ever really get to the mailbox?” One bright student said, “No, but you’ll get close enough to mail the letter.”

There are many definitions for what a heuristic is, but the one I like best is illustrated in this story. A heuristic is "close enough." I am beginning to believe that more and more what matters in software isn't so much building the perfect algorithms, that match and mimic real life in every way and hold up in every edge case. What matters most is getting a model that comes close enough. What matters are heuristics.

My favorite chemistry textbook, has this to say on the topic of "The Kinetic Molecular Theory of Gases" (KMT):

However, although laws summarize observed behavior, they do not tell us why nature behaves in the observed fashion. This is the central question for scientists. To try to answer this question, we construct theories (build models). The models in chemistry consist of speculation about what the individual atoms or molecules (microscopic particles) might be doing to cause the observed behavior of the macroscopic systems (collections of very large numbers of atoms and molecules).

A model is considered successful if it explains the observed behavior in question and predicts correctly the results of future experiments. It is important to understand that a model can never be proved absolutely true. In fact, any model is an approximation by its very nature and is bound to fail at some point. Models range from the simple to the extraordinarily complex. We use simple models to predict approximate behavior and more complicated models to account very precisely for observed quantitative behavior. In this text we will stress simple models that provide and approximate picture of what might be happening and that fit the most important experimental results.

The textbook then goes on to explain postulates for this model of thinking, many of which by themselves are absolutely false, but taken together and used properly, they create a system of thinking that works for a wide range of situations. This collection of half-truths produce a half-truth baked solution, absolutely, but one that is indeed close enough.

For example, some "half-truths" or "simplifications" if you will, involve assuming things like: each molecule of gas is perfectly spherical in shape and any collision is perfectly elastic in result. Or worse, the volume of all these individual molecules is assumed to be zero! Individually, each of these 3 statements is categorically false, but they were the right bits to "design away" as they defined the problem space so that the model could be simplified, made useful and the problem of dealing with billions of particles be made into something tractable.

To me, this is more than simple object oriented encapsulation and abstraction. This is thinking about the whole problem differently. It's about looking at individual behaviors from a very small sample and knowing, by some spark of genius, which attributes are the important ones to the ultimate outcome of the system as a whole, and which are not. This is writing software that is able to predict things, for example, test software that is able to predict when "something good" has happened and also when "something bad" has occurred. This is about designing software by building software models that categorically do not reflect the real complexities of the system, but that taken together, get "close enough" to do real work in the real world. Ultimately your models will fail when pushed to the limits, but even just understanding those limits will help you better understand the problem you are tasked with solving! It even begs the question: What kind of programming language best allows for the definition and use of heuristic models?

I don't know where I first heard this, but someone once said something like, "Where Microsoft codes if statements, Google codes in Bayesian probabilities." There are more data and variation in that data than there ever was before. If you are going to write or use programs (very likely) that deal with large amounts of data (also very likely) it might be a good idea to get used to thinking about things in heuristic terms. It may not be exactly perfect in every case, but it will be close enough.

Finishers Wanted

When I was a little boy my Mom had me memorize this little poem:

Stick to your task ’til it sticks to you;
Beginners are many, but enders are few.
Honor, power, place and praise
Will always come to the one who stays.

Stick to your task ’til it sticks to you;
Bend at it, sweat at it, smile at it, too;
For out of the bend and the sweat and the smile
Will come life’s victories after a while.
—Author Unknown

I think my Mom had me memorize this poem because she knew I would need it. She understood better than I the old adage that "Life does not reward us for effort expended." Finishing is required.

For me, it is exciting to find a problem and imagine a way to solve it. The creative exhilaration in coming up with a solution that will work within all the constraints involved is almost intoxicating. I have a remarkable tolerance for ambiguity and when the major "problems" as I see them, have been solved, filling in all the details seems so much less important. The hard design work has been done. There's perhaps little glory in all the simple, small and detailed work needed to connect the dots and make the grand vision a reality. However, software is ultimately just simple 1s and 0s and if you don't fill in all the details, then all you are left with is a dream. You've got to have both the vision and the finishing of all those tiny details.

"This is all your app is: a collection of tiny details." - Wil Shipley

Missing a few details can drastically reduce the value of the whole idea. I guess that's why I love Mac software so much: There's the constant demand from both the users and my peers for my concerted effort across the entire spectrum of "pie in the sky" ideal to actual, practical details in implementation. To make it work in software, you need to consistently execute well across the whole spectrum of work. Let me underscore the words consistently execute again, they are very important.

Matt Ball recently wrote a nice post about some up and coming Mac developers that worked so hard on their first release, but since then have produced relatively little. They haven't created new apps, updated their 1.0 apps, even posted to their blogs. Some still have ideas in picture form posted in all their high fidelity glory, but with no application to show or sell to the customers that have been waiting to see the finished product. These developers seem to be struggling with consistently executing against their plans.

Matt goes on to explain that he thinks this is related to their young age. Most of these developers are young (19 years old) and he thinks suffer from some kind of "shiny ball syndrome" where they are easily distracted from one project to the next. I don't know the developers, and they could be easily distracted or they could have absolutely justifiable reasons for their delays, but the result is the same: Doubt builds as to their ability to consistently finish their ideas. Their credibility and reputation weakens.

Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison

I don't think it's age. I think that's far too simple an answer. I know developers in their 50s who struggle from this exact same problem. It's not size or lack of resources either. Look at Microsoft. Here's a company where a large part of their problems revolve around consistently producing, not a lack of money or great people or innovative ideas.

The idea is not the thing!

One part of the problem comes from patent law. There is a remarkable and universally held assumption that ideas are worth a great deal. I will not say ideas are worthless, but they are worth far less than most of us realize. Even the most simple idea takes remarkable effort, and follow through to get designed, built, packaged, and ultimately used by others. This is why I felt My Dream App was destined for difficulty. They had enthroned ideas as the product, when in reality it's all the grunt work after the idea that make the product. It's all those pesky little details and the consistent effort required to follow up and deal with each of them that matters.

Finishing is the thing!

When the iPhone was released, there was a collective groan world wide from designers who had years before envisioned the ideas that Apple had now so beautifully produced in a finished product. Kim Lenox, Senior Interaction Designer of Adaptive Path explains:

With the launch of the iPhone, I’ve been hearing many grumblings from interaction designers who’ve worked for various, well known consumer electronics companies. We can all see in the iPhone aspects of our concepts from years past that were brushed aside or died prematurely. Our concepts are suffocating under the pile of NDA verbiage, never to see the light of day. What sets our mere concepts apart from this final product however, is a company with leadership who has the fortitude to take the risk, find the budget, and push the technology for the single cause of designing compelling user experiences. Apple got it right.

Amazing isn't it? Once again, it's all about execution and finishing, not just the ideas. Leadership is important for sure, but finishing the job in a company is so much more than Steve Jobs simply saying, "We're going to build an iPhone and it will have a compelling user experience." It's thousands of decisions made by hundreds of employees at Apple and elsewhere. It's dealing with setback after setback and still pushing forward. It's taking the right calculated risk (EDGE and AT&T) and saying no to other things (10.5 on time, a Dev SDK) in order to finish. That is the task of finishing and at Apple, it seems to be part of their DNA.

Tranquil and Steady Dedication of a Lifetime

One of the most important attributes of a software company I would like to work for, comes from an idea the late Adlai Stevenson a U.S. Democratic politician explained when referring to patriotism:

What do we mean by patriotism in the context of our times? I venture to suggest that what we mean is a sense of national responsibility ... a patriotism which is not short, frenzied outbursts of emotion, but the tranquil and steady dedication of a lifetime.

In a great software company, there wouldn't be "short, frenzied outbursts of emotion" but a consistent focus on finishing in a steady and sustainable manner. My guess is that those prone to "putting on a big, glitzy show" and those that don't effectively resist the "constant bombardment of new and exciting things to try out" will have set themselves up as an unsustainable business, and ultimately end up disappointed.

Saying No: a feeling of strength in reserve.

One of the biggest challenges is just saying no to things. What's hard about this is often you need to judge between what is "good", what is "better" and what is "best". In order to do that which is "best", you will, you must say no to many, many things that are "good" and "better". This is heart wrenching work, but choosing what you do now to remain focused and finishing, this is your competitive advantage. When asked what work he was most proud of from among his work at Apple, Steve Jobs famously said, "All the products we didn't ship." Many people and businesses talk about focus and priorities, but very, very few actually finish the idea and follow through with the well executed decision making and focus required.

“You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve.” - Pablo Picasso

Keep Moving Forward!

There is a scene in Disney's animated movie Meet the Robinsons that I love. The story is of a young boy inventor who is learning. During this particular scene he is trying hard to fix a peanut butter and jelly gun, used to automate sandwich building. Everyone is watching him and it looks like he's going to succeed, finally the time comes to try his fix. The whole thing explodes sending peanut butter and jelly everywhere and onto everyone in the room. He is devastated, but immediately he hears cheers and people start to comment on what a great failure that was! "You Failed!" "And it was awesome!" "Exceptional!" "Outstanding!" "Uh, I've seen better." "From failing you learn, from success, not so much." They congratulate him like he succeeded. They ultimately propose a toast to his brilliant failure. He is stunned. The motto of this family is: Keep moving forward!

This is a good motto for anyone working with software. The challenges are so great and the problems so complicated and frequent, you simply must have the determination to keep moving forward, to and through the finish. Start small and build momentum and keep finishing small things, just to keep in the habit of it.

This is not always easy. Sometimes I would come home from work so frustrated with how slow things were going and how little progress was being made, I'd tell my wife I just needed some time alone to cool down. I'd go into my room, open my laptop and write a blog post. I'd post it and point to it while saying to my wife, "There, I did it. I produced something today! It may not be much, but at least I produced something tangible!" You've got to keep in the habit of producing or finishing. You can't let those muscles atrophy.

One of the best development techniques I've seen over the years is test driven development. The pattern is to build a small test that represents an improvement you want to make to your program. Once the test is built, run it and watch it fail. Then write just enough code to make the failing test pass, then run the code and watch the test pass. Repeat. This tends to lead to low coupling and good cohesion and a reasonable test bed. The real hidden value is regular focus on tangible completion in a consistent way, over time. Just keep moving forward step by step and then after some time you'll be impressed as you look back on the mountain of work you've accomplished by such simple means with constant effort.

There are bugs to be fixed, old code to re-examine and refactor, performance problems to analyze and improve, build automation, test automation and website improvements, help docs to write, blogs to read, posts to write, ideas to explore, customers to contact, emails to read and write. Your job is to choose which of all of these you will do now, and then keep moving forward. Those who master the art of consistently and sustainably producing value, are setup for success. Be one of them. Don't quit. Don't stop. Focus on consistently finishing something of value, no matter how small. That's what the world will pay you for, and since so few seem to stick to it, there's plenty money in play for those who pay the price to consistently finish the job.

iKnow iDeas

A fun parody of Apple. The product? Paper napkins.

Classic Apple

When Apple announced the iPhone, I signed up for "more information" and gave them my email address. Today they sent me this:

On so many levels this is classic Apple.

Update 1: The graphic I uploaded from the email I got from Apple has misteriously disappeard. I'm guessing it's some copyright issue, but I recieved no notice from Apple or Google, just that the graphic was gone. Interesting.

Update 2: Looks like I'm too paranoid, the picture is back. Must have been just another blogger bug.

In demand

Ever laconic Seth Godin posts on what he sees in demand these days:

We don't need pilots. We need instigators and navigators, rabble rousers and innovators. People who can't follow a checklist to save their life, but invent the future every day.

I don't think Seth really understands what it means to be a great airplane pilot, but what he's trying to say is right. There was a time when folks who could do the "cog work" (e.g. follow this procedure, the same way, every time. etc.) were valued, but not any more. Moving away from the front line, I might say, what we need are leaders, not managers.

On the hive mind and the wisdom of crowds (or the lack thereof) Steven Johnson of the New York Times summarizes:

A swarm of connected human minds is a fantastic resource for tracking down software bugs or discovering obscure gems on the Web. But if you want to come up with a good idea, or a sophisticated argument, or a work of art, you’re still better off going solo.

There will always be a premium on creativity. You just can't engineer that. It's a human thing. There are problems you can solve with money, but being creative isn't one of them.

Impatience and Design by Counter Example

“Don’t worry about other people stealing your ideas. If you’re ideas are any good, you’ll have to ram them down people’s throats.” - Howard Aiken, IBM Engineer

This is my favorite quote for the day. Innovation, with all the ideas and execution that it requires, fails to happen for so many reasons, but most common in my experience are these two:

1. Design by Counter Example

2. Impatience

Design by Counter Example

Suppose you come up with some fantastic idea, you are excited about it, so you begin to share it with your coworkers and friends. If your friends are smart, they'll begin to analyis your idea for weaknesses and flaws. They'll do this not because they don't like you or don't trust you, they'll do this because it's what they are trained to do. Find the problems and worse, find the 100% solution, the solution that works everywhere. You'll know these people because they'll often begin their comments to you with "No, but..." or "What about..."

The problem with the "No, but..." response is that it sets up conflict, and no forward progress in idea generation can be made until the conflict is resolved. Worse, conflict resolution wastes time and energy and discourages more idea sharing. The "What about..." response almost always follows with some scenario or example that counters your idea in some way. Your response will often be an attempt to resolve that counter example, which when solved will be rewarded with a new and different counter example. Corner case upon corner case, what was a clear, bold and brilliant idea, gets designed into a complex, multifaceted feature that is costly to explain, build and test. If you share your ideas with a team of smart people, this can happen in a disastrously quick manner.

Impatience

Impatience is perhaps the subtlest of innovation killers. You will need patience as you develop the ideas because it will be hard to teach your idea to others, and then once the vision is clear, it will take yet longer to actually implement it. Remember it took Steve Jobs 18 months to convince the record labels to let him build the iTunes music store. If you back down at any point in this long journey, that is when innovation dies. This is why I believe, in so many ways, it's all about the execution.

Ideas are important too, and when you are generating ideas, being creative, all too often a well meaning individuals will ask you to rate the ideas and place them in priority order for potential business impact. This is a good idea, but done too soon, it's like asking a 3 year old what valuable contribution he or she will make to the world, and bereft of any intelligible response condemning the toddler to uselessness.

This impatience to see whether an idea is good or not kills innovation because the real innovation happens generally not in one brilliant flash of light, but at the interaction of ideas, and often ideas interacting with others in the periphery. I first heard Steve Jobs coin the phrase, "connect the dots backwards" and I think this applies here. You can't tell what will be important until after the fact, after the interaction. What you need is a safe place for lots of ideas to interact with out getting shot down. It looks like this:

Creating an environment where ideas can patiently interact and people can interact with the ideas before making the "do or die" business decision is key. What's even more important than the ideas, is that you don't kill the idea generators and integrators, that is, the people! Consider this story related by Heike Bruch and Sumantra Ghoshal in the February 2002 issue of the Harvard Business Review:

"In a major U.S. oil company, for example, we witnessed a committed and enthusiastic manager gradually become apathetic. An IT specialist, he was assigned to an inter-disciplinary strategy-development task force that was charged with creating a new business model for an up-stream division. The team came up with several radical proposals, but they were met with lukewarm responses from senior managers. After several months, the team's ideas were diluted to the point that not even the IT manger found them interesting. What had once been an exciting task became a farce, from his point of view. Believing that no one was interested in new ideas, he concluded that he was foolish to have been engaged as he was. "I distanced my self," he says, "I knew that none of our innovating ideas would ever make it to implementation. So I continued working out concepts and ideas-but with no skin in the game."

To be fair, even the best organizations occasionally create cynics out of enthusiasts. But some organizations seem to make a practice of it by constantly sabotaging any flickers of creativity or initiative."

When creativity flickers, don't let the cold winds of cost benefit analysis prevail. Provide the fuel of saying "Yes!" and patience to wait and see, even if you must suspend your disbelief. This will give people the space and time they need to make great things happen. Remember it took Michelangelo years to complete the Sistine chapel and Goethe spent almost 60 years writing his masterwork Faust. Good things take time.

So, if you want to be innovative here's my advice:

• Focus on execution, on making ideas reality. For every thousand great ideas, only one reaches someone with the courage to actually do something with it.

• Stop saying "No, but...", learn to say "Yes, and...", find a way to talk about ideas that adds more and moves them forward. Give folks what they want. Suspend your disbelief.

• Be patient, great things take time. The really great ideas are going to be a collision of ideas. Let them grow so they can interact.

$30,000 Apple Logo

A few months ago we got a bunch of Intel Mac minis (Intel Core Solo). We got 64 for automation and a some others for testers to use. When I saw the pile of boxes sitting in the hall to be recycled, I knew I had to save them. We piled them into my office knowing that there would be something I could do with them, but I just didn't know what or when. A few weeks later, it hit me. I opened up OmniGraffle and sketched out the plan:

The Plan For those of you not experienced with pixel art, what you see above is the Apple logo. I might add that it's very hard to come up with something that will look like the Apple logo with so few pixels. Seriously, try it. Once I got something that looked good, I got Joe to come and help me out. It took a bit of effort, but with Joe's help and some double sided tape, we got it finished: My Office Apple Logo I like to think I have the most expensive non-Apple-assembled Apple logo in my Office. This week we got our shipment of an additional 64 Intel Mac minis (Intel Core Duo) for automation. Hmmm, more boxes...

Work and Play

From David Heinemeier

You don’t have to work hard to work well. You don’t need sinister eyebrows or only 4-hour sleeps or a booked calendar to be serious. But somehow that image sticks so bad that we tend to view fun as the opposite of Serious Business Stuff(TM). It’s a false choice, not a real fight. And you accept its premise at your own peril. Fun is all about creativity, innovation, play, experimentation, progress, and seeing real things come to life. If you make fun an enemy of business, you’re judging all these desirable concepts by association.

I just had lunch today with one of our Excel testers and while we were discussing some testing ideas, she just blurted out, "I'm so in love with pivot tables! I just love them!" I laughed, but I loved to see the enthusiasm about of all things, pivot tables! Work can be play indeed!

Colour Like No Other

I remember the first time I saw this Sony commercial, I was blown away. Check out the high quality QuickTime movie here. Simply amazing. This is the kind of creative advertising that inspires, entertains and sells. Well, it looks like they are at it again!

What happens when you strap 70,000 liters of paint to the sides of some old buildings and explode the colored paint everywhere? I guess we'll find out.

My First QTVR: Petra, Jordan

A few years back, my sister and I went on a travel study trip to Egypt, Jordan, and Israel. It was fantastic! I had a digital camera, a wide angle lens, a Kaidan mount adjusted for the focal point of the lens on my Dad's Kodak, DC265 Digital Camera, and enough storage for about 64 "high quality" digital pictures.

Side Note: If in the future, you are going to bring a digital camera to a place where you will most likely never visit again, make sure you have enough batteries and storage to take as many pictures as you can, even if it costs a lot.

Well, I did get a few good pictures, but one of the most interesting places we visited was Petra, Jordan It is was one of the high lights of the trip. I set up the tripod and 12 or 13 portrait pictures later, I had enough to stitch together in Apple's QTVR creation software. It was super fun and I thought you might enjoy the look around. You can also check out the Google Maps images here.

Curiosity and Exploration

From the beginning I've liked what's going on over at Make magazine. I love their video podcast and all the crazy projects they put on display. What they show are regular people, just like you and me, doing stuff, making things, being creative. I was just reading an article titled, Life is Not a Spectator Sport by Darla Isackson in which she makes a very interesting point:

Today’s children are following the example of many adults to become watchers instead of doers, consumers instead of creators, observers instead of active participants. ... Instead of singing, they watch others sing. Instead of making up stories, they watch or listen to stories someone else made up. Instead of figuring out how to do something and developing a new skill they watch someone else perform.

This is so true! There are many reasons for this, but one that stands out to me is the very focus on math and science, these left-brain, less active, and somewhat less creative activities. What's funny to me, is that while the whole schooling infrastructure is supposed to produce excellent employees, what the post industrial revolution market needs is "makers", people who creatively produce.

Paul Graham recently published an essay about the The Power of the Marginal. Near the end he makes this summary comment:

If I had to condense the power of the marginal into one sentence it would be: just try hacking something together. That phrase draws in most threads I've mentioned here. Hacking something together means deciding what to do as you're doing it, not a subordinate executing the vision of his boss. It implies the result won't be pretty, because it will be made quickly out of inadequate materials. It may work, but it won't be the sort of thing the eminent would want to put their name on. Something hacked together means something that barely solves the problem, or maybe doesn't solve the problem at all, but another you discovered en route. But that's ok, because the main value [of] that initial version is not the thing itself, but what it leads to. Insiders who daren't walk through the mud in their nice clothes will never make it to the solid ground on the other side.

The word "try" is an especially valuable component. I disagree here with Yoda, who said there is no try. There is try. It implies there's no punishment if you fail. You're driven by curiosity instead of duty. Which means the wind of procrastination will be in your favor: instead of avoiding this work, this will be what you do as a way of avoiding other work. And when you do it, you'll be in a better mood. The more the work depends on imagination, the more that matters, because most people have more ideas when they're happy.

If I could go back and redo my twenties, that would be one thing I'd do more of: just try hacking things together. Like many people that age, I spent a lot of time worrying about what I should do. I also spent some time trying to build stuff. I should have spent less time worrying and more time building. If you're not sure what to do, make something.

So what should you do? Don't just watch, do something! Don't be afraid to try. Fear kills creativity. Just do something, anything and you'll be surprised how much you'll learn and how well it will go. It's the doing that matters.

Words Matter

When I wrote the title for this post, it seemed almost trite. I don't mean it to be. The words we have at our disposal define the thoughts we are able to think. If you've learned another language and become fluent enough to think in that language, you know what I mean. I spent two years in Brazil as a missionary and grew to love the Portuguese language. While I took my required 2 years of German in High School, there's nothing like living the language to teach you subtleties of the words. There are some ideas that simply can not be described in another language. The Portuguese word saudade, I think, falls into this category. Further, there are the synthetic languages, like Arabic, where I understand that one symbol can take a whole English paragraph to explain! Simply put, the words you use matter, and more than you might think.

My coworkers often chide me, because when I have a new idea, I'll spend hours trying to come up with the name for the thing. Why? Because it frames the way you think about the idea and code names simply don't switch well. You've got to get the name first. I've never really been able to explain this, but I just heard a speech given by Bruce Sterling that I think finally explains the idea really well and introduces several new ideas along the way. The Internet of Things, check it out.

It's All About the Experience

For Father's Day we decided to take a road trip down to visit my folks in Vancouver, WA. It was a great weekend and spur of the moment we decided to let the kids and Mom stay with the family for a few more days while I took the train back to Seattle. I've never taken the train anywhere. Purchasing the ticket online was a breeze and the Vancouver depot is old and just darling. Right after I got on the train and we started pulling away, I looked back to see the bridge the train just came over rotating on its center to allow boats through, and that was just the beginning of the picturesque trip I am now experiencing. I'm in Business Class which means I paid the extra $13 for an electric outlet I can use to power my laptop during the 3 hour trip. It's quiet, and pretty smooth once you get used to the rocking from side to side. There's a sign, in the front of each car that says, "Using a cell phone? Please be considerate of others." And if someone has a long, loud conversation they take it to the enclosed vestibule in-between each cabin car. It's quiet and comfortable. There are wide isles! I'd have to really reach in order to touch my neighbor across the isle. Also, I didn't have to be at the station 2 hours early like for an airplane trip, and there are no lines! (Incidentally, there was no security check of my bags at all! I guess trains are not as big a security risk as airplanes? I don't know...)

I'm half way through the ride as I type this and all I can say is if AmTrack is not growing, it's simply because they haven't figured out how to improve and sell the experience of classic train travel. I could easily envision luxurious lunch appointments, private booths, full Wi-Fi internet access and large windows. They could have family cars for longer trips, where children don't have to be strapped to a car seat, or confined to coach class seats on an airplane. No more road trip bathroom stops. There would be constant access to excellent food, time and access to movies, board games and always a dynamic and beautiful view. This is to say nothing of having your young child gently rocked to sleep. (As I look around right now, there are already 5 adults asleep.) If I were in-charge of AmTrack I'd remake it into a posh, elite experience that people could look forward to and remember as the calm, peaceful way to travel, a level above cars and planes. It's not the destination, it's the journey when you are on a train. When you are paying for a commodity, you are destination driven, but when you are paying for an experience, then you can charge a premium, and this is exactly what Apple sells, but Amtrack hasn't figured out yet. It's all about the experience. On top of all that, who wouldn't pay more to have every kid, in every car, at every intersection or passing park wave at you?

General Theory of Design

I was catching up on some of the blogs I try to read and I found this fantastic definition of design by Brian Sooy:

"Design consists of creating things for clients who may not know what they want, until they see what you've done, then they know exactly what they want, but it's not what you did."

This is so true. As I see it, the only way around this is to ship as frequently as possible. The folks over at 37 Signals provided the more visual representations both above and below.