Experience

Especially with a code base that is mature, assumptions correctly made years ago can be terribly difficult to deal with later when the current and new assumptions reign. Writing code that lasts even 5 years and "is robust" is what everyone wants to do for sure, but the recipe for doing just that is not easy to learn and even harder to actually do. For example, you might know what changes need to be made to conform to even the most obvious object oriented design principles, but the business requirements and time to market needs dictate leaving once again old crusty code alone and racking up yet another round of technical debt. Over time, this technical debt will demand payment and the effects on your ability to hire, employee morale, design changes possible, speed of delivery, testing burden, marketing message etc. become very real and very painful. I wonder, can these concepts can be fully learned without actually experiencing pain? Could you even attempt to learn these concepts experientially in college? My experience so far makes me think that one may know something intellectually, without really knowing it. It seems like for so many, one may talk about design patterns or abstraction or low coupling, but until you actually try to build something the other way, the painful way, you just don't appreciate what you are avoiding. What's worse, junior developers who, for no fault of their own lack experience with "the hard way" have a difficult time understanding why one must "go the long way around" to do what seems like such a direct solution. Passing on the stories of the past and their consequences and lessons seems to be an unending challenge.

From my economics book comes this fictional story which I think illustrates the point:

"One Pepsi plant is managed by an economics major with an MBA and has a labor force with an average of 10 years of experience. This plant produces a larger output than does an otherwise identical plant that is managed by someone with no business training or experience and that has a young labor force that is new to bottling."

I definitely fall into the "young labor force that is new to bottling" camp. In the technology industry there is a tendency to glorify the young and bright rather than those who have the experience and have paid the price to learn the lessons that matter in the long run. Whenever I talk to some developer and we talk about where they learned some valuable lesson about software development, rarely do they refer to a book. Almost invariably, they say, "I worked with Joe on this project and he showed me x, y and z. I learned so much working with him." Smart developers, experienced developers who know how to teach and share important lessons to junior programmers seem like a key to the experience problem. Sadly, junior developers who have the presence of mind to ask, listen and apply what they hear are hard to find, and senior developers who are both willing and able to teach effectively are even more rare.

Perhaps the answer to all this is simple. Perhaps it's just he or she who writes the most code, wins. What I mean by this is simply when one writes a lot of code that increases the probability that he or she will make more of the key mistakes needed to learn how to write software with longevity. Just getting more exposure to "how bad things can get" helps bring a sober reality to each line of code written thereafter.

What's remarkable about all this, is that failures in teaching and learning are what keep us "discovering" new ideas that are 40 years old. Truly, "there is no new thing under the sun."

Metacognitive Miscalibration

A few tweets ago, (I always feel weird referring to Twitter in the past tense) I posted: Why are the unintelligent or uninformed so arrogantly confident while the intelligent and well informed so often unsure and apprehensive? There is something very human to thinking you know more than you really do about a subject or issue. While, this problem can be seen in many areas generally it's particularly acute in software development. For example...

AppleScript in Office X

Back when Mac OS X was just about to go 10.0.0 we were busy working on getting Mac Office working on the new platform. There was a lot of pain involved with the transition. Many APIs had been removed and alternatives needed to be provisioned (and tested), the new Aqua interface guidelines had to be applied to the whole of Office and a host of other issues needed to be addressed. I was at the time on the team that wrote the tools for automated testing and I was pushing hard to get Office wide AppleScript support on the list of features we'd commit to doing for Office X. I wanted this not only for our customers, but to augment our testing efforts. With an API to drive the applications we could automate many "smoke tests" on a daily basis as well as set the stage for long term AppleScript based test suites. Automation testing benefits are often not fully realized, especially static automation, until the version after you setup the automation, so I was especially anxious that we get our API in Office X, so we could reap the return on investment for Office 2004.

I remember talking with Jim Murphy about getting AppleScript support like it was yesterday. We were in building 44 and his window office was near the 2nd story walkway that connected our building to the cafeteria. In my naivete I asked why we couldn't just build a some kind of layer to call into the engine code of Office and presto, AppleScript dictionaries for Office would be complete. I pointed to some improvements Apple had made to make AppleScript a better inter-application communication protocol and ask, "How hard could it be?" Jim turned to me and said, "Hard? There's nothing easy about it. It's all pain. All pain." Then as was typical, turned back to his work, leaving me to think.

In this case, I was the unintelligent and uninformed, but very enthusiastic novice. Jim turned out to be right. For Office X, we did try to do the AppleScript work, but it turned out to be much more difficult a problem to solve. After months of work and many dead ends, we pulled the feature from the Office X feature list. For Office 2004, we tried again. In this case, Jim himself, one of our best developers, ended up spending the better part of a year getting AppleScript to work with Office, which is probably worth another post in and of itself. I thought I knew more than I did, I thought the problem was simpler than it was. My confidence and thinking was miscalibrated. The root cause was my lack of understanding and experience.

Wicked Problems

Sometimes, even the best developers underestimate the scope, breadth and depth of a problem. In a drive for simplicity, I observed in myself and others another kind of design time problem where thinking was miscalibrated. The cycle I have observed looks like this:

1. Developer looks at a problem A, and thinks he or she fully understands the problem.

2. Developer designs a simple solution to problem A.

3. Developer codes the simple solution.

4. Developer or tester or marketing or customer use simple solution for problem A.

5. Bugs trickle in and solution A is modified, bit by bit, bug by bug, until it is patched in a thousand ways and no longer looks or acts like the simple solution. The solution is complex.

Some will say, "Hey! Why didn't that lame developer take the time to really understand the problem? Then he could have taken the time to fully comprehend the complexities of the problem, and then design a simple, elegant solution!" The problem with this is that many subtleties to the problem do not manifest themselves until very late in the development process which make re-architecting the solution for such a small issue un-reasonable. But this is a "death by a thousand paper cuts" issue. What's worse, many architectural issues can only be comprehended after years in a problem space, and as promotions or attrition happen, the so called simple solutions, with their complex instantiations proliferate in code.

Adam Richardson spoke to the challenges of wicked problems when he said:

Wicked problems are very difficult to understand by staring straight into them and looking for clear detail, however. They need to be approached from the edges, sort of like doing a jigsaw puzzle where you find the edge pieces first. Having peripheral vision that is trained to be sensitive to the edges is a key capability (this applies both to product teams and to business units - wherever wicked problems occur).

Normally this causes the developer to tack on simple solution to solutions with patch upon patch applied with the Hippocratic Oath echoing in their ears to "do no harm", but deceptively the bandage is not big enough for he wound, and no one knows.

The Desire to Learn

Another reason why some can feel "informed" when in fact they are not is that they have lost the hunger to learn. They've lost the desire to learn and grow. René Descartes said it this way:

Good sense is the most equitably distributed of all things because no matter how much or little a person has, everyone feels so abundantly provided with good sense that he feels no desire for more than he already possesses.

There is a reason for diversity of opinion, it provides the natural tension that keeps us from thinking we've got the problem solved. When I left Microsoft to go back to school and finish my degree, many asked, "Why are you doing that? What are they going to be able to teach you?" I'll admit that this partially resonated with me. I wanted to be the sage of wisdom, but as I've spent time with teachers and students, many of whom do have less "industry experience", I have learned an enormous amount! To put it bluntly, I have been humbled. I've learned things technically, intellectually, physically and even spiritually. I feel so blessed. I'm beginning to think that what any given situation can teach you depends largely on the person experiencing the situation and very little on the experience itself. Put another way, there's a great difference between 50 years of experience and 1 years worth of experience repeated 50 times.

Personal Pride - the Anti-change Agent

Closely related to the lack of desire to learn is the desire to avoid being wrong. So much in school is focused on being right, knowing the right answer to a test or the correct proof or solution. In sports, no one likes to lose. Everyone likes a winner! But this desire can work into our minds in a limiting way. Leo Tolstoy wrote:

I know that most men, including those at ease with problems of the highest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.

At work I would say, "We don't fail half as much as we need to." I still think this way, but now I've found a new reason: Failing keeps our mental muscles and joints from stiffing with pride and forming into the arthritis of the mind.

The Well Intended Deception

Another reason for metacognitive miscalibration I think stems from the very basis of good object oriented abstraction and encapsulation. When I write some simple app with Cocoa's AppKit and Foundation libraries, I am, as they say, standing on the shoulders of giants. I've wondered how many actual lines of code are called when I double click a simple app like TextEdit. Who wrote these lines of code? When did they actually get written? What were the discussions behind their design and implementation? Even Apple couldn't fully answer these questions. It is all this code that even the simplest of Cocoa applications depends upon. But still we continue to have demos around how "few lines of code" were needed to accomplish something. This is a well intended deception, because really, more code is being executed and written, but only now how this code works is opaque. It's well intended because who wants to write, maintain and debug more code? Why not offload this to Apple? I expect these demos to continue, because less code for a developer to write is the canonical example of efficiency, but there's something wrong that comes from this. It's the feeling that you actually really understand what is going on to make your application tick. These assumptions and abstractions can be benign, but they can also make one feel and think that they know more than they do and can do more than easily possible.

In the process of detail management that is software development, making things simpler and more tractable is an excellent goal, but there's a limit to how "simple and easy" things can get and still be valuable. Recently I overheard two students talking about building an iPhone application. The one said to the other, "Dude, they showed this awesome demo of Spore, where in only 2 weeks, 2 weeks! they got this awesome iPhone game running! It's so easy. We can totally build an awesome iPhone app!" First, I love the enthusiasm and I hope they do in fact build an awesome iPhone application. Apple was trying to demo how easy it was to build iPhone applications and I think we've never seen a mobile platform that's better for developers, however:

Taking a senior developer who as spent the last several years of his life building games and developing Spore, bringing him into Apple with full and uninterrupted access to Apple's staff of iPhone engineers that have been developing the iPhone SDK and iPhone applications hardly equates to a college student being successful at all the complexity involved with boot-strapping a company and building a successful iPhone application from scratch. Building great software is still hard, hard work. It's tedious, often un-glamorous and takes someone who doesn't mind getting down and dirty with the details to make something great. Most will simply give up, and even those with the passion and stamina to continue are hardly assured of success. I suppose I'm arguing simply that a healthy dose of Steve Job's famed "Reality Distortion Field" do not a great developer, company or software make.

There are probably other reasons we tend to think we know more than we actually do. But the lesson for me is this: I need to take some time to ponder and reflect regularly. Am I in the "unintelligent or uninformed and arrogantly confident" camp? If so why and how can I get humble? Am I part of the "intelligent and well informed but unsure and apprehensive" group? If so why and what can I do increase my tolerance for risk and decrease my fear of being wrong? A little meta I know, but the title should have warned you. :-)

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.

Numbers

One of the great benefits of working at Microsoft is that when you add a new little one to your family, you get 1 month of paid paternity leave. Recently, we've had the opportunity to take advantage of this benefit. Since our little baby was born, I've been home working as Mr. Mom. I've been mostly offline, except for early mornings and late nights when the kids are sleeping. My boss isn't going to like it, but since I've been gone for paternity leave, I've logged on to my work email only once, and that was just to make sure my out of office emails were working. Needless to say, I've been happily busy with family.

I haven't been so busy that I didn't catch Apple's announcement regarding their new iWork application, Numbers. I haven't bought a copy, or logged into work to see what others are saying about this announcement, but I'm guessing it's much like when Apple announced Keynote for the first time. A combination of deep respect for Apple's software and design capabilities, coupled with sense of, "Let's get back to work and make something great!" kind of attitude.

What follows are some of my personal feelings that I've considered amidst making meals and playing at the park with my kids. I don't in any way attempt to speak for MacBU or Microsoft, these are just one person's opinions, specifically mine. And yes, I do work in MacBU, and yes I can't share everything I'd like to say for obvious reasons. So, here goes:

Once upon a time, it was decided that we needed to move to a more open file format. XML was the obvious choice. There were and are a lot of good reasons for opening up your file format. I'm not going to discuss these at length, but one of these in particular is that folks are not forced to use your application to both read and write files that others can use. This is a good thing.

Allowing anyone to read and write your file format is a bold move because it says in essence, "We don't need a locked down file format to compete. The format can be available for everyone, and we'll compete on the ease of use and efficiency of our applications. We have what we think is the best interface for reading, creating and managing Office documents, but if someone has what they think is a better way to build Office documents, wonderful, we welcome it!"

What Apple has done with Keynote, Pages and Numbers is exactly this. With each one of their applications, they've created a user interface that reflects how they think people want or should want to act when building a presentation, document or spreadsheet. I've been in this market for a long time, and obviously have opinions about how things should be done. If someone else has what they think is a good solution for building Office documents, I think that's great.

From another perspective, I think Apple's work on Numbers underscores that despite the large advances being made in web interfaces, there is still a place for rich client applications. Both iLife, iWork and even the Google Maps application on the iPhone reinforce that there's lots of opportunity left for innovation in the "rich client" arena. Numbers specifically proves there's opportunity left for innovation in the productivity applications space. I certainly think there is, and folks who think that the problem space that Office lives in is "essentially solved", should think again. There's plenty left to improve. Plenty. That's what makes it exciting.

Some have said, "I bet MacBU is envious of Apple being able to start from scratch." Now that's a loaded comment. Let me try to address the different parts. First the envious thing. Apple is a great software company and at Microsoft, software is pretty important too! ;-) At the very core of MacBU is the desire to produce great software for the Mac platform. When the business unit was created, the whole goal was to focus our energies on producing seamless and compatible, but very Mac, applications. There are a certain set of problems one must focus on when working on Mac Office. There's another set of problems one must focus on when working on iWork. You trade problems sets, but they are just different problems sets! The grass is not always greener on the other side of the fence. Most people with significant software experience will know that "starting from scratch" is one of the most risky and difficult things to do. I don't think anyone is excited about scrapping years worth of effort just to have a clean start at things. From a programming perspective, that just makes no sense.

Also, Apple isn't starting from scratch. They are building methodically on the several foundations they've laid over the years in Keynote, then Pages and now they've added Numbers. One might even say that, Numbers is Keynote and Pages with better table and function support, and not be too far from the mark. This kind of progressive building together is what Microsoft did with Office originally. There's a pattern here. The bigger questions in my mind are really these: "Will Apple's software foundation allow them to add to and improve their software for the next 20 years? What will be the rate of their improvement?"

Lastly, in a very real way, we do "start from scratch" every product cycle. I wish you could all experience the high energy and exhilarating discussions we have when we are planning for the next version of Office. We "wipe the slate clean" and do our best to remove all inhibitions and constraints when we think about what we can do next with Mac software at Microsoft. And this doesn't just happen in MacBU. My favorite example of this, right now, has to be the new UI in Win Office. Maybe someday I'll write about that more in-depth, but the way that Ribbon interface elevates access to the many features of Office and makes Office easy to use is just wonderful. Anyone who's serious about interaction design in software should take a serious look at what this interface does and how it does it. There's a great deal to be learned, not the least of which is that sometimes you need to dramatically re-think the user interface of your application and not be afraid to do exactly that.

Finally, as in the past, the question will undoubtedly be asked, "What is the core value of Office on the Mac?" I'll answer that with one word: compatibility. Mac users are the kind of people that want things to "just work" and Microsoft Office for the Mac offers that exact value proposition. Mac users want to enjoy all the great things that make the Mac experience wonderful, but still be able to share documents and communicate in a Mac way in a Windows dominated world. MacBU is categorically in the best position to deliver on this promise of compatibility.

iPhone Applications

When Apple announced that the "sweet" iPhone Software Development Kit was going to be AJAX and "Web 2.0 stuff", most developers scoffed. A few went to work, and now we are starting to see some web applications built specifically for the iPhone.

First up is a very nicely designed shopping list application named OneTrip. It was the first iPhone application released as far as I can tell. It's also my personal favorite.

Then 37Signals Ta Da List web app simply senses if you are hitting their website from an iPhone and adjusts to look like this:

OmniGroup is working on a version of their getting-things-done application OmniFocus for the iPhone and they have some screenshots online here.

Notice how these iPhone web apps follow or try to follow very closely the iPhone look and feel. This is a testament to how these developers really get the "build the experience" ethos. That said, even with all this focus on looking "iPhone-like" without the smooth transitions, it's really quite a different feel.

An attempt at a full list of all iPhone web apps can be found at iPhone Application List, but be prepared for some ugly looking iPhone apps. I think the delay in releaseing a "real" iPhone SDK may actually help cement the iPhone experience. With a solid customer expectation of what it means to be an "iPhone app" this could actually lead to an better user experiece with all 3rd party iPhone applications long term. Let's hope!

Apple's official documentation and guidelines for developing for the iPhone are located here: http://developer.apple.com/iphone/

Transitions

You may have heard the saying, "It's the journey, not the destination." I like this saying, but I have never applied it to user interface design.

Normally, when prototyping or sketching up a UI design, I focus on the end states, the screenshot. Once you have that, you link screenshot to screenshot in a kind of storyboard that shows the process the user will follow to accomplish a task. Most of the time, these are just paper sketches. Sometimes I'll do some high fidelity screenshots, but normally the sketches are enough.

What's amazing to me about the iPhone experience is how much time Apple spent, not on the end states, but the transitions through and to the end states. I'm really starting to think that what makes you feel so great about the device is just as much the easy to use screens, but the ease and smoothness of "getting there." The "journey" through the iPhone interface is filled with great transitions from beautiful state to beautiful state. It really is just as much about the transitions as it is about the destination.

I started to think about other great experiences that I've had at restaurants, shopping, even a few websites and I realized that a very large part of what made them so enjoyable was really the way they managed the transitions. Every step of the way was cared for, curated really. I've always known the "out of box experience" was important, and the functional flow through the application critical, but designing the visual flow through each functional transition, this is a whole new idea.

The 1.0 that wasn't

From what I can gather, the biggest problems with the iPhone seem to be as follows, in order of severity:

1. You can only use AT&T network

2. The EDGE data network is slow

3. The keyboard takes some time to learn

4. Making a phone call can take more "taps" than with other phones

5. No way to Cut, Copy or Paste

(I'm leaving off the list the fact that so many are having trouble activating their phones. I think this is AT&T's capacity planning problem, and I don't think we'll see this happen again.)

This is remarkable. The iPhone is NOT a simple device. It is a complex feature-laden phone, iPod and web device. And with all this functionality, the most folks can do to complain about it is reference something related to the items above.

This phone flies in the face of all those who think that 1.0 products must be either fully focused on one task to be done well, or those that consider 1.0 products something you should avoid by default until the next release, you know, the one with all the bugs worked out. The iPhone while complex and full of features, does have a simple interaction and experience. It is so compelling and just fun, that to miss out on this version while waiting for the "next rev" seems almost unbearable, once you've played with it. As others continue to market proudly their "alpha" and "beta" stickers, Apple shows us all, that you can deliver a 1.0 experience that really is complete.

What it means to be 1.0 will never be the same.

Silverlight

The best thing about Silverlight is its icon. For regular users it's a web-browser plugin that allows you to view and use Silverlight content. What Silverlight content is there? Media and stuff. Have you ever seen a website done completely in Flash? Well, now you can do that but with Silverlight. From my perspective this is fundamentally about competing with Flash. There are some cool things going on under the covers to make this happen and as a developer, I understand the geek factor there. By the same token, as a developer, my ability to develop amazing software is directly related to the toolset available to me. So I ask myself, "Which toolset gives me the greatest ability to develop amazing software?" Flash or Silverlight? PHP or Ruby on Rails? Cocoa and Core Animation or XAML and .NET? I don't think I can compare any of these with much authority, but I have a hard time believing that the next killer app, web or otherwise is going to show up as a Silverlight application. Still, I love the icon.

Apple Slips Leopard to Oct 2007

From Apple's Hot News web page:

Apple Statement
iPhone has already passed several of its required certification tests and is on schedule to ship in late June as planned. We can’t wait until customers get their hands (and fingers) on it and experience what a revolutionary and magical product it is. However, iPhone contains the most sophisticated software ever shipped on a mobile device, and finishing it on time has not come without a price — we had to borrow some key software engineering and QA resources from our Mac OS X team, and as a result we will not be able to release Leopard at our Worldwide Developers Conference in early June as planned. While Leopard's features will be complete by then, we cannot deliver the quality release that we and our customers expect from us. We now plan to show our developers a near final version of Leopard at the conference, give them a beta copy to take home so they can do their final testing, and ship Leopard in October. We think it will be well worth the wait. Life often presents tradeoffs, and in this case we're sure we've made the right ones. [Apr 12, 2007]

This is interesting. Apple, like many companies often slip their release dates. Historically, however, Apple has only slipped a little on ship dates, but this slip, from Spring 2007 to October 2007, is the largest slip I remember. It's very uncharacteristic of the rhythm of shipping Apple has had over the last 5 years.

Leopard is certainly Apple's most ambitious OS release yet, so it stands to reason that they could have bit off more than they could handle. I'm sure this was further compounded by the additional resources needed for both the Apple TV and the iPhone. I also wonder what the "secret features" are that Jobs referred to in his last keynote. Some have suggested that this slip was to add unplanned functionality, but I don't get that sense. I tend to believe that this is just what it's stated to be, a resource issue.

There are 3 variables you can change when managing a project: scope (how big it is), resources (how much money and people you can allocate) and time (how long the project will take). It looks like Apple reduced their allocated resources for Leopard, and without a corresponding reduction in scope, they were forced to increase the time the project would take. I'm sure this is super painful for them, it always is, but not long from now, they'll ship and this will all be a distant memory. Personally, I'm glad I don't have to put up with all the rumor sites constantly suggesting that Leopard is just about to RTM. ;-)

Update: Best quote from our chit chat around the office here: "Woah. October? :( Stupid iPhone. I want my Time Machine."

Credibility

I was just skimming through the Windows Vista User Experience Guidelines and while in the Design Principles section I came upon this title, and I just had to laugh:

There is a point where marketing ceases to be marketing and becomes information; relevant, valuable information. There's also a point where something, truly informational becomes marketing. Branding folks like to say that any interaction with your product defines your brand. Whether you are working on marketing or strictly informational stuff, it's important to pause and ask yourself, "What does this say about me?" Sometimes, it's that simple human question that's enough to help you know when you need to work a little harder to remove a subtitle.

Hardware and Software

John Gruber writing on Apple's choice of AAC as the DRM-free format sold on iTunes, makes this interesting comparison:

Apple’s use of AAC in lieu of MP3 is analogous to the Mac’s switch to USB in 1998. USB was an industry standard that wasn’t taking off because PCs didn’t ship with built-in USB ports, which PC makers didn’t include because there weren’t many USB peripherals on the market, which peripheral makers didn’t want to build because there weren’t enough PCs shipping with USB ports.

Then came the iMac, whose only peripheral port was USB. (It didn’t even have FireWire.) All of a sudden peripheral makers had a reason to make USB gadgetry, and after that, PC makers had a reason to include USB ports on new PCs.

Hardware and software are the Yin and Yang of the tech industry. Some argue that one is more valuable than the other, but you can't separate them. You need both. Apple is one of the few companies in the position to capitalize on this reality. From a human computer interaction (HCI) standpoint, if we are going to move forward the interaction, this necessitates hardware advances. And who is in the best position to push forward hardware advances that are included by default? Apple.

The newest and perhaps most interesting HCI advances recently have been the result of great software and great hardware, together. The Tivo, Microsoft's XBox and XBox Live, Nintendo's Wii and Apple's iPhone and Apple TV are perfect examples of what amazing things can happen when great hardware design meets with great software interfaces. Additionally, from a purely experiential perspective, people feel better about laying down large quantities of cash for something physical rather than something that's purely intellectual property, as much as I personally value the later.

Fundamentally, where should you look for human computer interaction innovation? You should look to the people who can move forward the whole stack, and can integrate it fully, seamlessly. In the realm of personal computers, that leaves only one company: Apple.

When to Automate Testing?

Note: The following essay applies to software developed for an upgrades-based business model. While it may apply to other software business models, I make no attempt to defend that assertion. Also, see my disclaimer if you think this is more than just my personal opinion of the world.

The Problem

In the beginning, you're a small team, maybe 10 developers and 10 testers. (Okay, this is a huge team, but I'm trying to make the numbers easy, work with me!) You ship your version 1.0 and it's a huge success and you make loads of money! You also get lots of feedback on what could be better. So, you go to work on version 2.0. Some of what you need to make version 2.0 great is more developers. You hire one or two more developers and one or two more testers, but there is a problem: the testers must test everything in version 1.0 plus all the new stuff scheduled for 2.0. You've hired exceptional testers, and they dig in and with long hours, they are able to test sufficiently, barely, and you ship 2.0. Everyone attends the big ship party! Whoo! After a while, you look at your finances, and realize that while 2.0 was much better than 1.0, there's still a lot that could be better and your customers make that very clear. So the market for your product is not saturated which means there's still lots of upside. On top of that, your sales team informs you that by just adding feature X along with feature Y you can expand your potential market by at least double! Enthused by the success of your product you move on to version 3.0 and it's about at this point that you begin to sense some nervousness from your test team. Testers always seem to be a hyper-critical bunch, it is their job you know, so you brush off that antsy feeling, excited by your increasingly successful product. By about version 12.0 you realize what the testers were all nervous about:

Note: The numbers are fake, but the problem is real.

Let's say 1 developer produces 1,000 lines of code each product cycle. Can you see a pattern here?

The graph of code growth looks like this:

The number of testers you have working on the product must either increase with your code base or you're doomed to shipping a product of lower quality, eventually. Also, incase you're wondering, increasing your testers in proportion to you code base has some pretty negative financial implications as does pushing out your ship date to make room for more testing.

If that were not enough, there's some pretty solid evidence that that even the original 10 testers were insufficient for the initial 1.0 product code base, let alone the scaled and additional load that has grown over time! Exhaustive, comprehensive testing is simply impossible. So while in version 1.0 the testers had to make intelligent priority judgments about what to test, in version 12.0 the testers have to basically divine the future if they have any hope of getting to the critical bugs manually!

It really is this hard.

The professional testers I know have an enormous challenge at hand and must be so absolutely decisive about where they spend their time, it amazes me. Sometimes new testers, or those unfamiliar with software development, will simply think, "Hey, all I have to do is find all the bugs!" and they'd be wrong. What they have to do is find every important bug and verify that every critical code path is working. (And loads of other stuff, but that's for another essay...) You see, at the core of professional software testing, there is a built in, super advanced, internal priority system. Great testers seem to have an efficacy gene that allows them to explore the areas that are most important and identify the worst bugs. This is a skill and an art and the world could use more great software testers.

The Automation Pill

Given all the forgoing, it is absolutely incredible to me, that once a tester is given the chance to write code to automate some of their work, somehow, for some reason, this priority system goes into stealth mode. I don't know why this is. Perhaps it's the part of the brain that you use to write code messes with the part that compares the relative costs of automation. Perhaps it's the dream, "If only I could automate all the 1.0 feature testing, at least in 2.0 I could focus just on the new, fun stuff." It could be, and sometimes is, a manager, long lost touch with what core testing is all about, and now looking for ways to "drive efficiency and reduce costs" asks for something as silly as 100% automation. It could be a million things, but this is for sure: Test Automation is a fantastic tool that I believe can help with the problem mentioned above, but like most tools, when it's miss-used, it hurts.

When to Automate?

So when do you automate your tests? I don't know, for sure, but I do have some questions you might consider when making the decision. All of these questions have a common theme, and it is this: What is my return on investment for automating this test?

Script Death

When you invest time to write an automated test, you implicitly lose time you could be using to find and file bugs. That lost time will only pay off over time if your test continues to be valid for certain number of test runs. The best way I've heard this described is "script death."

When you write the script for the first time, you give it life. It lives, as long as you don't need to modify the script in any way, and the results of the test continue to be valid. If the script has a bug in it, or the product under test changes, or a new OS version changes an assumption, or a new CPU comes to town and causes your test to become invalid, your script had died and you need to re-examine if you are going to invest the time to fix it or not.

Update: I had forgotten where I had read this concept, but it was years ago. Thanks to a link, I found Bruce McLeod's weblog and a link to Brian Marick's 1998 article on this very subject of When Should a Test Be Automated?. It's a great read, I highly recommend it. This was one of the first articles I read on test automation back when we were just starting our Mac automation system.

When you write a test script, or go to update a test script because of "script death" consider the following questions. I'm sure there are other questions I've left out, but this is a start:

Is the feature a core/critical feature?

Since the pay back in test automation always comes back as the script is run, will it be run many times? Automating to ensure no regressions in a critical area, like testing that a security hole is plugged, or testing a core area, like file open, and file save would be great candidates for automation because the cost of a regression in these areas is very high, and they'll be run with each new daily build.

Is the test tedious and error prone?

Some tests might not be core or critical, but the testing involved is mind numbing and easy to mess up. A good example of this might be, say, opening 1,000 user documents and making sure you app doesn't crash. :-) Tedious testing makes unhappy testers, and a happy tester is a productive tester.

Will my test script verify results via a fragile method (screen capture) or a sturdy method (API)?

For the automation to be worthwhile it must verify something! I've seen far too many glorified crash tests marked as automation. If you don't have verification in your automation code, then the only time it's going to fail is when you encounter a crash, a good thing to be sure, but far short of the scripts testing potential. When writing your script, you'll need to consider what methods you'll use to get data back from the system for verification. Find or make APIs that you can use (AppleScript can be very useful for this, hint, hint.) Screen shot verification is fraught with difficulty. Avoid it if you can.

Is the feature I'm trying to automate undergoing a lot of churn?

One thing that will cause script death just about faster than anything else, is the product changing. This is why scripting to the API, (You do have an API right?) is so much better than scripting the UI. Typically, the UI changes much more frequently than the API ever will. Either way, consider if the feature is new and undergoing lots of change. If so, avoid automating your tests around the feature until it has settled down. (This can mean toward the end of the product cycle, which is when you are busiest looking for those show stopper bugs.) Just know, that if your test script doesn't get much value this product cycle, it will in the next provided the feature doesn't change.

Who or what is the "oracle" for what is correct behavior and what is not? Does that have a good chance of changing?

Automate around things that can be verified from a dynamic oracle. All verification will need some kind of code that says, "I'm expecting X did I get it?" If you are encoding in your test script the definition of "success" how sure are you that what is "correct" will not change? If you are not very sure, move to another area for automated testing.

Is thet test easy to automate? Does the script have a good probability that "death" will not occur?

If it's easy to automate something and the probability is low that things will change, go for it. A good example of this is automating your setup and install testing. These kinds of tests are going to be done over and over again and most installers have some kind of script-ability built in.

If this script will save me 1 minute's worth of time, and it will take me 30 minutes to write, will the script run 30 times to break even for my invested time? Will it run longer and actually save me testing time in the future?

As you near the end of your project cycle, the chances that your automation will earn back it's investment in the current project cycle diminish. At the beginning, things are too turbulent. The best time to write automation is about the middle of the cycle, when things are mostly stable, but there are still lots of builds left to test.

How hard will it be to internationalize this script to test localized builds?

Some scripts are easy to write and the verification easy to setup for your English builds, but once you localize your project "script death" becomes rampant. Keep this in mind. If you are writing a script, how hard will it be to localize the script when the time comes? Can you write it "OneWorld" from the beginning? If it is almost certain your script will die on the localized builds, don't plan on using automation to augment your localization testing with out significant work on your test scripts.

When this script fails, how easy will it be for me to investigate the failure?

Investigation is by far the most time intensive part of test automation. Write your scripts so they are atomic or very specific in what they test. Don't write test scripts that run for 30 minutes, unless that's the explicit purpose of the script. You don't want to be running a script for 30 minutes just to repro the failure that occurs in the 29th minute of the test execution. Write your scripts so they are super easy to read and so that the logs "yell" what the test is and how it is failing. Your automation harness will play an integral role in how easy it is for you to investigate your automation failures.

Small, atomic scripts run great in parallel!

Can I trust this script to really test this part of the feature?

There is often a hope that automation can some how magically babysit a feature just like a human tester running through a test plan. This is simply not true. A human can see so much more of what is going on and pattern match a thousand different things simultaneously. An atomic automated script will have its blinders on and be fully focused on verifying only what you specified when you wrote it. Don't under-estimate how stupid automated tests can be.

In closing, automated testing is not a silver bullet that is going to solve all the problems of testing and software development. It is a valuable tool that you'd be silly not to employ in managing the complexity of software testing. I believe James Bach said it best:

"I love test automation, but I rarely approach it by looking at manual tests and asking myself “how can I make the computer do that?” Instead, I ask myself how I can use tools to augment and improve the human testing activity. I also consider what things the computers can do without humans around, but again, that is not automating good manual tests, it is creating something new."

Software Factories

Now this is interesting. Jack Greenfield and Keith Short take on the future of software development:

Total global demand for software will grow by an order of magnitude over the next decade, driven by new forces in the global economy like the growing role of software in social infrastructure, by new application types like business integration and medical informatics, and by new platform technologies like web services, mobile devices and smart appliances. Without comparable increases in productivity, total software development capacity seems destined to fall far short of total demand by the end of the decade. What will change to provide the massive increase in capacity required to meet demand? It is not likely to come from adding developers. Instead, software development methods and practices will have to change dramatically to make developers much more productive.

Read the whole article here.

Martin Fowler has a whole essay on this topic: Language Workbenches: The Killer-App for Domain Specific Languages?

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.

And to round out the discussion Neil Davidson responds to Steve Cook with this insightful comment:

As much as I find the technical side interesting, the thing which really fascinates me is how the way people write software will change in the future. ... I've been thinking about it a bit, and I think that although the analogy with the changes in industrial manufacturing (from craftsman to mass production to mass customization) is interesting, I'm not sure it really holds true.

I think one of the key things you mentioned was the analogy to the supply chain, and how this chain will lengthen. The way I see it, software will always need a craftsman at one end. Software is intrinsically hard to do, and requires people, or teams of people, to think very carefully and deeply about what they're doing. The tools, processes and components they use will have to change though - it is at this point in the supply chain that I can see mass production happening. I think the analogy is that you're always going to need craftsmen like carpenters and bricklayers to build a house, but the tools, techniques and materials they use will be mass produced. At the moment we're at the stage where the bricklayer makes his own bricks, and the carpenter cuts his own trees down. I don't think the craftsman will be replaced, but the tools he uses will be provided by companies who provide (or are) software factories. That's the point I was trying to make about a few companies dominating the market - somebody will discover that they can produce an e-commerce software factory and sell hundreds of thousands of the things at $1,000 a piece rather than two or three a year at $100,000 a go (because it's no longer a problem constrained by people's time). Presumably Microsoft believes it will be them and that's possibly part of the reason why they're entering the CRM, accounting and business markets.

Does Apple see any of this? Do they think it all too distant to consider currently? Either way, what an interesting time to be developing software!

Composition Arts

In a kind of déjà vu moment, two of my favorite blogs posted about the same thing, on the same day! The topic: How writing code is similar to writing prose. Christina Wodtke of Boxes and Arrows takes E.B. White's “List of Reminders," from The Elements of Style and compares them to web design. Matt Linderman of 37 Signals compares the stages of the writing process to that of software development. I think there's a lot to be learned with these comparisons. Without a full understanding of how construction or manufacturing actually occur, it's easy to compare software projects with construction projects. I think there's probably more similarity between writing software and writing prose than manufacturing or construction.

WebKit's JavaScript debugger

Now WebKit includes a JavaScript debugger named Drosera. To use it you need to get the newest build of Safari and enter this in the Terminal:

defaults write com.apple.Safari WebKitScriptDebuggerEnabled -bool true

The best quote is this one:

One of the unique things about Drosera, like the Web Inspector, is that over 90% of it is written in HTML and JavaScript. This is a true testament of what you can do with web technologies today and the rapid development that WebKit allows.

This is cool.

Glue That Doesn't Set

Dave Thomas posts about how Perl and Ruby are like glue that connect things together on the internet. The problem with Perl, he conjectures, is that it "sets". When you read Perl, especially if you didn't write the code, it's difficult to discover what is going on and therefore difficult to modify. Now, you can write obfuscated code in any language, but I'd have to agree that Perl has a propensity toward poor readability. What's interesting to me is that Ruby is described as the "Glue That Doesn't Set" or the code that is always easy to read and understand the intent of the author and on top of all that easy to modify. That's pretty high praise if you ask me. I wonder if it's more the conventions and included libraries (Rails, in this case) that make this so, and less the language itself. It's an interesting metaphor anyway.

Small (relatively speaking)

This has got to be my all time favorite comment from the press:

"The autonomy of this relatively small division allows Microsoft programmers to cut loose and design the best software they can imagine… Microsoft's Mac offerings are routinely credited as being more innovative, elegant and robust than its mainline PC products" – Terril Yue Jones, Los Angeles Times, September 2005

There's a lot of energy out there in defense of the small, the startup, the two or three in a garage, and I don't want to take anything away from that, I am a romantic at heart. There are wonderful times to be had by all and room for everyone, but to perhaps add some balance to the discussion, there are some very good reasons for "big". Consider Six Apart the makers of some very successful blogging software. Two founders with a company that has been on the blogging wave from the beginning, the perfect poster child for small and agile. And yet Mena Trott president and a co-founder of Six Apart, writes a post entitled: In Defense of Big (relatively speaking) She writes:

An underlying theme over at Signal vs. Noise is the concept that smaller is better -- smaller in terms of start-up capital, company size, development teams and even hardware. As part of a two-person team that created the initial versions of Movable Type and TypePad, I certainly understand the logic in encouraging small and nimble teams. The eighteen months that Ben and I spent in our spare bedroom coding was probably our most productive for bare-bones software development. Of course, during this same time, we were afforded the luxury of not having to do anything much more than coding and designing -- our project management was done via (what felt like) telepathy.

A long time ago (well, maybe not that long ago -- it just feels like it), Ben and I were at a fork in the road where we had to decide whether we wanted a small, niche company that would serve as a nice lifestyle business or try to be something bigger and take a gamble that Six Apart could make a serious impact on blogging. (A "lifestyle business" is one of those terms that money/funding people use to describe someone who can make a nice lifestyle for themselves with their company, but doesn't really make jobs or opportunities for a lot of other people.)

So here we are -- a big, small company or a small, big company. I've been on both sides of the table and have to say that it's pretty nice where we are. And since the "small is better" argument is very often offered in both elegant (Signal vs. Noise) and ignorant (Generic "Being Corporate Sux!!") ways, I thought I might contribute my reasons to why bigger can be better.

She then lists her reasons:

1. More people, different view points.

2. Accountability.

3a. Creating jobs for many people.

3b. It's nice not to always have to bootstrap.

4. The ability to shift roles.

5. Sticking to what we're good at.

6. It isn't just an American thing.

7. Creating products that really make an impact.

I'm a bit biased in talking about this whole thing, but I can say that the small startup resonates with me, like with others. That said, there are great things you can do for others as more people use your product and with the scale comes the blessings and challenges of software in the large. Check out her full post. It's a great read.

Adobe and Microsoft on PDF

Brian Jones has a follow up post about the whole no default PDF support in Office debacle. It's an interesting read that also points to the official statements of both Microsoft and Adobe regarding the issue.

It seems like Adobe isn't as concerned about financial implications of PDF creation loss as it is about losing the control over the openness of the PDF format. Does that last sentence strike as a bit of a strange oxymoron? Welcome to the ironies of success.

On team politics...

I think from time to time, everyone has to deal with politics. Depending on your organization or team your milage may vary, but where there are people interacting, trying to get results, chances are you'll encounter some team politics.

I recently finished reading The Five Dysfunctions of a Team by Patrick Lencioni. It was a wonderful read, I highly recommend it. The book is setup as a fable, so the story is fake, but the ideas are very real and practical. One part I really enjoyed was when Kathryn (the CEO in the story) defines politics:

Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.

Think about that for a while. There's some great wisdom in this definition.