The value of "good enough" technology

Twitter is Good Enough

Twitter drives all my tech-savvy friends crazy. We all agree that the idea - a simple mix of blog, chat, and IM - is a good one. However the site does very little, and what it does it does poorly - slow response, frequent outages, etc. Most developers figure they could write a "better Twitter" in a lazy afternoon, and some already have. Good idea, poor execution, and yet... it's good enough.

Twitter is good enough to keep its network and remain successful. Yes, they could be better, but their networked customer base isn't going to pick up and move to a new service all at once, and people are unlikely to move on their own. Twitter is good enough.

The Dishwasher, the Chinese Room, and a Subservient Chicken

Assume I told you to specify the very first dishwashing machine. It would be very tempting to define the process:

1. The machine will pick up an article.
2. The machine will wash the article.
3. The machine will inspect the article for spots and re-wash if necessary.
4. The machine will rinse the article.
5. The machine will dry the article and place it on the drying rack.

In reality, though, dishwashers just spray a bunch of hot, soapy water on dishes in a rack and dry them with hot air. They don't deal with the dishes one at a time, which is part of the reason that they're small enough and cheap enough to fit in most kitchens.¹

Imagine that you needed to design a system which acted on a small set of instructions which were written in Chinese. You don't speak Chinese. What would you do?

The "right" answer might be to hire some translators, or possibly set up some automated translation software. Those would all work, but would probably be a little expensive. What if I told you that it was acceptable to have a small percentage of failures, especially at the beginning? In reality, a most software is not 100% perfect, especially in early versions...

I didn't randomly pick this task. The Chinese Room is a famous thought experiment in artificial intelligence, which postulates that a person with a good enough "cheat sheet" in a sealed room could pretend to be conversant in Chinese, even though they didn't have any idea of what they were saying. That would be work even better if the vocabulary and topics were confined².

That's how the Subservient Chicken worked. The Subservient Chicken was an advertising campaign for Burger King's chicken sandwiches back in 2004. You could (and still can) give the chicken just about any order, and he'd do it. It was amazing... and yet, the chicken only performed about 300 actions. They were just the right actions to make it look like this crazy guy in a chicken suit could do just about anything you asked of him.

Good enough for an a publicity stunt, but let's take it a step further. Let's say that we wanted the translator in the Chinese room to pretend to speak the entire Chinese language, and the Subservient Chicken to do just absolutely anything you could think of. In considering our approach, remember that a certain amount of failure is acceptable.

In that case, I'd make sure that the initial feature set (Chinese vocabulary, set of chicken stunts, etc.) would be just enough to keep users coming back, putting more effort into making sure all failures were captured and immediately acted on. Yes, the system won't be perfect to start, but it will keep improving, and the improvements will be based on what users are asking for that we can't handle. And in this case, I believe a quick feedback loop would be better than trying to guess what users would want for the initial release. That's how I assumed the Subservient Chicken worked, by the way. I figured that they had some guy acting out things as they came in, only performing new stunts when they weren't already in the system. If you did that, you'd very quickly build up a library of the most common requests, and a small amount of effort would be required to keep the system growing.

Ever wonder how Google's spell correction system works? If you search for "mnokey", you'll see "Did you mean: monkey", right? Although there are a few corrections to the results, the spell corrections don't come from an intelligent system or even a dictionary; they come from tracking user behavior. Just about every time someone searches on "mnokey", they don't click on any search results and search again for "monkey." Google tracks that and uses that as a good guess at a spell correction. The system learns from users.

Everything's a feature

So, what features are up for discussion? Absolutely all of them.

• Security is a feature
• Reliability is a feature
• Performance is a feature
• Scalability is a feature
• Object orientation is a feature
• Test coverage is a feature
• Data integrity is a feature
• Data access methodology (e.g. only via stored procedure) is a feature
• Etc., etc.

Some of those are obviously listed to provoke a reaction, but everything on the above list really is negotiable.

For instance, you might see security as non-negotiable, but Wikipedia is a pretty good example of a site with an intentionally weak security system which has become incredibly successful.

Reliability? NASA shoots for zero defect products. It's enormously expensive, and it's not always successful. Every major Internet service I use crashes or goes offline from time to time. Nobody's 100% reliable. If we say reliability is non-negotiable, we're fooling ourselves.

Performance and scalability? As Richard Campbell and others pointed out during the ASP.NET Scalability Panel, it's a big mistake to spend too much effort supporting millions of users when you don't have a hundred. Of course we should avoid irresponsible programming, but I recommend building working systems that can be tuned when needed rather than building elegant systems from day one.

I understand that many developers view that as sloppy programming, but that's just following personal preference over pragmatism:

• Premature optimization is nearly always misguided
• Which is worse - a horribly inefficient system which has gone live, or a beautiful system which goes to market late enough to be irrelevant?
• Most successful software systems (Windows, Google, MySpace, etc.) shipped in an imperfect form followed by lots of incremental improvements.

I'm really into performance tuning - I wrote a section in our soon-to-be-released ASP.NET book focused on tuning slow ASP.NET applications, from caching to database profiling to index tuning. I enjoy writing SQL, and I think I'm really good at it. And yet, I'm a big fan of SubSonic, which generates dynamic SQL for ASP.NET data access. That's because, while I like hand-crafting SQL queries, I think it's usually an irresponsible waste of time. The better approach is to build a working application on a framework which allows me to hand tune when I need to, then wait until that time comes to get under the hood. It takes restraint to let facts rather than gut tell me where to spend my time, but it's the right thing to do.

So, everything on the list above (and more) is negotiable. Some are undoubtedly important in your application, but it's probably a mistake to try to get all of them perfect on the first release. Ship something, listen, then ship something better!

Network Effects and First Mover Advantage

So, Twitter shipped the first service "social chat-IM-blog" thing, and it's not perfect. Unless they're offline for days at a time or a competitor comes up with an absolutely stunning new feature, though, their network is secure because nobody wants to move to a new system without their friends. Inertia is on the side of an established network.

That's why it kills me to see Microsoft so late to the game with a lot of their Internet services. In many cases, they really are better services, but they're late enough to have a very uphill climb.

What I didn't say

I want to make it clear that I'm not saying programmers should write poor software. We all know that will happen without my saying so... What I am saying is that software teams should focus on shipping software quickly that's "good enough" to be useful to their customers as quickly as they possibly can, then use customer feedback and actual system performance to drive what happens next.

¹ I first heard this example studying for my old-school MCSD six or seven years ago. I no longer have the book and can't find the quote online, but I think it's a fantastic analogy.

² I learned the value of limited vocabularies in my days as a submarine officer. We all got pretty used to communications under terrible conditions - sound powered telephones in the engine room, ship to ship radios, yelled verbal reports during fire and flooding casualties (some of which were drills, some of which weren't). The trick was that we were trained to use very specific terminology. That's great for several reasons - the speaker doesn't have to make any decisions on how to phrase your words, and the listener doesn't parse sentences so much as select from a few possible expected commands or responses. Hmm... this sounds like a separate post...