26 February 2008

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.

24 February 2008

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.

23 February 2008

The Perfect Laptop

Business Week's recent cover story on Lenovo's new ThinkPad X300 laptop caught my attention. Can you imagine spending 2 years working on a super thin, super light laptop for release in February 2008 and then have Apple announce the MacBook Air on January 15th? What a commotion must have been had at Lenovo after Jobs' keynote!

It turns out that the X300 is actually lighter than the MacBook Air when configured without the DVD drive. It apparently also snugly fits into a mailing envelope! It has 3 USB ports and an Ethernet port and includes a solid state drive as the only drive option. What's really striking about the X300 is Lenovo's whole approach to the project. When they think of the "perfect laptop" they don't see the svelte curves or shiny metal jewel that Apple sees, they see 90 degree angles, boxy, matte-black, computer that looks all business. David Hill, Lenovo's chief designer and "keeper of the ThinkPad tradition" said it best: "I'm a bit tired of looking at silver computers, I'd never wear a silver business suit."

Despite the fashions of the day, Lenovo is not only trying to remain true to, but underscore the original ThinkPad design by Richard Sapper. I'm impressed by this. They are trying to build an equally, if not more impressive laptop than the MacBook Air, and retain their own identity in the process. It's both courageous and unique these days. In some ways it says something about the times that "simple, elegant, matte-black machines with precise, 90-degree corners" would be thinking differently, while so many are trying to "be like Apple." My applause goes to Lenovo for being themselves! Well done!

22 February 2008

The Mix Tape and iTunes

I know I'm dating myself a bit here, but there was a time when friends my age would exchange songs via cassette tape. It was illegal I'm sure, but such a wonderful labor of love. The carefully selected list would exchange hands and then the recipient would spend typically 60 minutes straight listening to each song trying to deduce the "real meaning" for this song being included in the mix. Meanwhile, the giver would also listen to the same songs wondering how the recipient might be enjoying it. As you can imagine this made for some great follow-up discussions. I was reminded of this recently when I found this product from the UK:

Note: the authentic bent label. There are even other styles shown here.

With 64 MB of storage you can get at least 60 minutes of songs for your gift. Very retro. Fun, not terribly sustainable and probably illegal as well, but still pretty cool.

When I saw this I wondered, and not for the first time, "Why doesn't Apple do this kind of thing on iTunes?" They've allowed gifting for a long time, but that's one song or album at a time, not a collection of specially chosen songs. They could send a custom "iCard" or well designed announcement. Going to iTunes would allow you to download the gift list with a special custom cover for the playlist along with custom messages for the whole list and each individual song. What you're selling here is the experience of the music and the gift of listening to each song specially selected for you. There would be a one click "Add to my iPod" once the songs downloaded so you could get going right away. While you listened you could continue to refer to the sender supplied comments for each song on your iPod. As an added bonus, if the person receiving the list, already purchased this song on iTunes, it wouldn't copy down a duplicate song, but just link it into gift playlist with custom text. In this case the cost of the collection would go down by the cost of the duplicate song.

This isn't just about love birds or anniversary collections either. I can see "get well collections" sent, "congratulations you did it!" collections, and even "inspiring songs from a friend that cares" lists being given. I can even see adding a movie or movie rental to the list with the connection of "this movie makes me think of you" or "let's watch this together..." etc.

I suppose every regular Mac user who blogs has to post from time to time, with wishes for Apple to fulfill. I haven't done my fair share of them, so here's my penny in the fountain. I think it would work wonderfully. Come on Apple, give us Mix Tape gifts on iTunes!