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

WWDC Tips

Nadyne asks, "So this is my first time attending WWDC. Got any tips for a newbie? :)"

I've got some:

I'd not skip the keynote. ;-) And get there early. Ever since I scored a new mouse for showing up, I'm expecting some kind of keynote give away. Don't do that. It's perpetual disappointment.

I enjoy the Apple Design awards, but I'm less inclined toward the Stump the Expert session.

Take notes about the questions and answers, they are often the most interesting part of the presentations, but not included in the recordings online.

There is a WebObjects talk that is given by a guy (sorry, I don't know his name) but he always creates a song to explain what he's teaching at the end of his session. Sometimes two songs! They are just awesomely funny. I always try to make it to this session. And once again, it's not on the DVDs/online version you can view afterward.

The wireless network will be sketchy and most probably will not work during the keynote. Just know that in advance. Seems like it gets better as the week goes on.

Walk the floor both in the hallways and in the presentation rooms to scout out where the power outlets are. Often there are outlets in the floor, if you bring a small power-strip, you become fast friends will everyone around you.

Trying to schedule your sessions in advance is simply a lost cause. The keynote changes everything. You'll have lunch and time to think on the first day to plan the rest of the week. Don't be afraid to hop sessions, if one session is lame, jump to another one.

The feedback sessions are always fun, but by far the most vitriolic is the Aqua feedback session. I go just to enjoy the banter. :-)

Food goes fast. Get into the rhythm of when the food is set out and try to be there for the first drop. I almost always got the tail end of the Jamba Juices distribution which always meant, I got nothing.

Take some time to walk in the Labs and talk to the engineers. They are friendly and always have interesting things to say.

Oh, ya, there are lots of parties. Enjoy 'em.

The plug-fest is fun, just to see the new hardware devices people bring in to try out.

The Apple campus bash is fun, especially if you've never been there before. Unless you are on the first bus there, don't expect to get into the Apple Store on the Apple campus without a long wait in line.

What are your tips for attending WWDC?

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!

Hyanide: My Tank Bike

I've posted before about my dream car, but I just found my dream bike: The Tank Bike.

German designers Oliver Keller and Tillman Schlootz presented their extremely extreme personal tank concept for the 2006 Michelin Design Challenge, showcasing vehicles made especially for California's diverse and often rugged topography. Hyanide's tread contains 77 (holla!) identical plastic-covered segments of Kevlar rubber held together by Kevlar rope. Each segment flexes independently, allowing fluid multi-directional movement suitable for any conditions including deep mud, sand and snow.

No more bent axles or broken crank shafts for me!

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.

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.

ExCodeWarrior Schwag

I've written before about our ExCodeWarrior dev shirts we got as reward for successfully moving our code from CodeWarrior to Xcode. Well, now you too, can pay your respects to CodeWarrior, in mournful black, as well as honor the great work the Xcode team has done, and all this in time for WWDC 2006! I'll have my ExCodeWarrior shirt on, will you? ;-)

My WWDC Wishlist

After reading John Siracusa's hilarious post about WWDC Buzz Word Bingo, I got to thinking about what I'd most like to see at WWDC. Here's my list:

1. Make it brain dead simple to write multi-threaded applications.

How simple? If my application runs fast on a dual core machine, I want it to run twice as fast on a quad-core, no recompile. Too difficult? I'd settle for automatically routing all AppKit method calls to the main thread only, so anything the user sees with their eyes is on the main thread, but everything else happens on other threads, no extra coding by me.

2. Widescreen iPod phone

First and foremost, make it a great phone. Second an iPod. Third, and a distant third at that, a platform I can build upon.

3. Video Airport Express

Encode TV signal to MPEG 4 and send to my Mac's disk drive in real time while I watch another channel streaming from my Mac.

That's it. I'd be happy with that.

P.S. If you are going to be at WWDC this year, drop me a line. I'll be there, and I'd love to chat!

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.

The General Purpose Thing

Recently John Gruber wrote about the The Mac OS X Tipping Point and finished with this sumation:

You can’t appeal to all people all the time, but Mac OS X comes remarkably close. The old Mac OS, as insanely great as it was, did not.

I think what is so quickly forgotten about the transition to Mac OS X was Apple's against-the-grain assertion that they could build an OS the did appeal to beginner users and power users alike! This was NOT the prevailing wisdom of the day. I even remember seeing previews of the OS in which there were "modes" like standard user and advanced user. Simple Finder in Mac OS 9, ultimately was an outgrowth of this kind of thinking. Additionally, Microsoft was pursuing a dual code base strategy for desktop vs. server. Apple's insistence that you could actually build an OS that did scale from the grandma turning on a computer for the first time to a seasoned UNIX developer was courageous and spunky at the very least.

Recently, I have noticed a resurgence of the idea that the general purpose tool is by definition a less effective solution as compared to something more task specific. This hits home to me personally since I work on software that is used by a very broad spectrum of Mac users. There will always be tension when trying to design software to appeal to such a large and diverse audience, but simply factoring the problem into a "pro" and "beginner" products is the easy way out. You can make software that has general appeal and scales gracefully to a user's needs as they grow, it's just very hard to do! Difficulty aside, it is this kind of "scaling up" that defines what I love about great Mac software. All the core features are apparent and easily discoverable, but as you need more functionality, you effortlessly find them, almost as if the designers read your mind. Tools like these become transparent to your workflow and are a joy to use.

OS X Software for Switchers

Thanks to Ars Technica I've been pointed to another great switcher resource. The post lists software that will make your stay on the new OS much more enjoyable.

Following Directions

Did you ever get one of those tests on how well you could follow directions? I remember a sheet of paper with more than 20 step by step directions (not unlike some usability studies...) and when you get to the last step you realize you've gone all wrong because of a careless reading of the instructions before step one? Well, here's your chance to redeem yourself. Maybe. ;-)

P.S. I must have clicked it at least 100 times before I stopped...

The 2 Fingered Right-click

For you die hard control-clickers MacBook Pro users out there, with Mac OS X 10.4.7, Apple just updated the OS so that in order to produce a right-click you simply place two fingers on the trackpad and click. While not as addicting as two fingered scrolling, this is a welcome improvement and allows Apple to retain their iconic single button mouse without a significant loss of functionality. Could a three fingered click be next? Don't count on it.

IT Collaboration

Christian Buckley is friend of mine, and not only was he recently hired on at Microsoft, but he works in the same building as I do! MacBU shares the same building with, of all groups, our Microsoft IT department! I love that when they walk into work each day or schedule meetings in the conference rooms on our floors, they get to see all our Think Different posters. ;-) Anyhow, for the IT folk in the audience, Christian just got a new shirt that you might appreciate:

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.

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.

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.

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.

Enterprise Feedback for MacBU

A while back I posted about our new release of the Office Resource Kit for enterprise admins. We have setup two methods for you to give feedback on what you'd like to see in the next version:

1. An online survey - It will be active until the end of July 2006

2. An email address - Mac IT Pro Feedback - macitfb@microsoft.com

Note: We had the online survey setup earlier, but inadvertently set it up so after one response, the survey closed. It took us a while to figure out there was a reason only one person responded. ;-)