Web-Based Software or Customer-Built Software?

Adam Bosworth writes some interesting thoughts about the difference betwen waiting around for the IT guy to write your software for you, versus using some kind of existing general-purpose environment and building your own, or at least customizing them:

...the problem IT faces isn't sloppy languages. It is irrelevance. For much (although certainly not all) of the work IT does, IT is like children building sand castles on the beach and watching the tide roll in. That tide is highly customizable web based solutions, Salesforce.com today, perhaps Talaris tomorrow. Ask the average Salesforce.com customer (meaning a salesrep) if he is happier with the solution he has now or the one he had back when IT was building a customer CRM for him.

Maybe I'm missing the thrust of this, but I think what he's saying is that lightweight solutions like Salesforce.com win out over custom-built solutions by IT departments because they already exist and are flexible enough to be adapted to the individual's needs.

Over the past couple of decades of building and using software I've seen a lot of things go by, including scripting languages, Visual Basic, and many, many, many attempts to empower "regular people" to program things up for themselves, the way they like it. The best so far has to be HyperCard, from Apple Computer. It's dead now, though my brother Harvey doesn't think so. The scripting language is intuitive, forgiving, and like English. But it's still incredibly hard to get "what you want".

The problem is that customization isn't particularl easy, and most people don't bother. People don't pick Preferences or Settings from the menu. They don't change the garish blue menu bars of Windows XP (okay, they do all set background wallpaper images). Which means that people are still using programmer-built tools as the programmer intended, and the fact that a few of them are more flexible than others doesn't argue pro or con web-based software.

Consider FileMaker or DBase, totally flexible, open-ended databases. Do whatever you want. They have not taken over the world. More point-specific databases are what people actually want. Salesforce.com is tailored to a specific problem, has contact information and tracking as its focus. Would you really want to build that yourself with an open-ended database construction kit? Not me.

So I guess I don't see a trend here at all; it's just evolution. It's the usual flurry of exploratory software, new ideas, attempts to find the Holy Grail. Maybe a better analogy is a sports analogy, though I try to avoid them. Each new bit of software, web-based or not, is like a play in a football game. The play is sketched out on a whiteboard before the game (the business plan), it's taught to the players, then it's called on the field. Some plays move the ball forward, some do not. It's not inherently the play itself, but the execution of it, and the quality of the defense (competition) and the weather (business climate, evolution of technology, etc) that decide whether or not your pass is completed for a touchdown, or intercepted (large competitor) and used against you.

Web software hits the wall

I have been thinking a lot about web-based software versus rich-client software recently, fueled by thoughts by Adam Rifkin and visions by Marc Canter and a bunch of other stuff besides.

We are staking our company on client software, but not traditional "applications", but true network-based applications. I think that web software has hit the wall, and is becoming marginalized because of inherent limitations in what is possible.

The world wide web is a bit like cable TV: it's a downstream thing. A web site dispenses content to lots of clients, but the clients struggle interacting in an upstream capacity (like cable). If you've ever uploaded photos to a web site, you know that it's inherently a downstream activity, this web surfing thing. Uploading is like swimming upstream, salmon jumping out of the river, making little progress, struggling....

But that's not even the biggest limitation. It's not a coincidence that Napster, Kazaa, and instant messenger clients are all native applications: they simply could not work over a web-based platform. They call it peer to peer but what it really means is that the applications can use the network any way they want, rather than being forced to talk only to the server from which they were spawned, as web software must do.

Consider also that so-called "web software" wouldn't work at all without the native application called the browser. And it is not a trivial piece of software, no matter whether you look at IE, FireFox, Safari, or whatever. They are complete operating systems unto themselves, and they still do a lousy job of running application software.

That's because they're web browsers. Not application platforms. Java notwithstanding. There's no support for good UI (Laszlo notwithstanding). And they're limited in terms of what they can do on the network, for security reasons.

So we're watching blogs and wikis and social networking and web-based services grow on the web platform, with the conspicuous absence of messaging, collaboration, and file sharing, because they're basically not possible.

We think that many of these useful network paradigms can still be combined, but it requires an entirely new application that itself is kind of a platform, like the browser was before it, but which enables a richer kind of communication-based work to be done. We have that, although today it looks a bit more like instant messaging than it does a web browser. Or does it look like Kazaa? Or sort of like an email client? Hmmmm....

The chief value of web-based software is that the data stays on the web site, centralized. This is undeniably powerful. But it's quite possible to do without using a browser as your dashboard. We think that combining centralized data with an inherently powerful communications tool you get the best of both worlds.

Software: Like Coats of Paint

The software industry has diverged into radically different categories in the past 5-8 years. It used to be that there were very few programming languages that "mattered", and everything was written in "C". Along came Java, and changed everything.

Java is an interpreted language, which means nothing to most people, but it's a synonym for slow. Java is a convenient, addictive, easy-to-use, but ultimately lightweight programming language. It is not used at all for "desktop software". It's rarely used (any more) for "applets" which download and run through your browser. It's very heavily used for server-side software. In fact, essentially all modern web-based "services" are written in Java, or worse, in a scripting language like Perl or Python or PHP. Hmmmm. If it starts with P, maybe it actually is.

But interpreted languages require another program to interpret them, Java requires a runtime, and for server-side software usually an application server like "TomCat" or "JBoss". All this stuff runs on top of a web server, usually "Apache". So your friendly neighborhood web site like, say, Friendster, is a bunch of layers of software running on top of an app server on top of Apache on top of the core OS.

Layers of paint.

When you paint furniture, or your car, after 2 or 3 layers, you're supposed to scrape it all off, down to the bare metal, and start over. In the software industry we use that phrase "down to the metal" to mean going down to the operating system level that everything else sits on top of anyway. It's faster. Better. Simpler. But usually much more difficult. So people don't usually bother. Or they hurt themselves trying.

Programming in C on UNIX or Windows systems is like welding. By contrast, I call Java the hot glue of the internet. A couple of college kids can quickly put a compelling demo together by painting over something else, like making a stage set, and that demo can often attract funding, and then real users, and then it all bogs down and gets slow and sticky or it falls apart. If you've ever hot-glued anything together, a month later you know what I mean.

At Five Across, we started from scratch and wrote our own technology, in C, which runs lightning fast on the bare metal operating system. We think this will become a significant competitive advantage. It also means that our application software is under a megabyte in size, compared with, say, our competitor Groove, which is 50 times larger.

Some say layers and abstractions are good, but although they make things easy, they also limit what is possible because everybody's building on top of the same layers, and they constrain functionality to what the layers make possible (example: you can't do peer-to-peer conversations in a web-based piece of software. At all.)

I say scrape off all that paint and build some real software.

It's a Wonderful Life

I watched the end of It's a Wonderful Life on TV tonight, under a moon just-past-full, with blustery winds. It's a beautiful night, and seems portentous somehow. I had to go outside to keep a few things from blowing away and I looked up at the moon, and thought a bit...

We are an incredibly fortunate lot, all of us. Anyone able to read this blog post is amazingly lucky. You have a computer, internet access, and the luxury of "reading blogs" while much of the world is not so well off. It's a wonderful life after all, not a bit like Potterville.

I am the CEO of a startup company in Silicon Valley, an amazing opportunity and responsibility at the same time. I won't say "I don't know how I got here" because I do know how I got here, and it was a lot of hard work and risk and not a few mistakes along the way. It's funny to watch a schmaltzy old black-and-white movie and get sentimental, but the truth of many things doesn't age, or change. I was strangely inspired by watching Jimmy Stewart and Donna Reed...

When I was at Apple, during part of the bubble burst time, I remember Steve Jobs saying that it was a time that many companies would be regrouping, saving, being conservative and careful, and it was a perfect time for Apple to "step on the gas" and accelerate, hire more people, innovate more, and come out the back side of the downturn at full speed, hitting on all cylinders. You need only look at Apple's stock price today to see the wisdom in that, and the phenomenal success that Apple has shown in the past 5 years.

As we head into the holiday season, often considered a miniature downturn in our industry, I am highly motivated to do the same, to invest some idea capital and hard work and come out in the new year with some bold new product direction, renewed momentum, and start an incredible year for Five Across. We were in Atlanta last week and had a few true brainstorms and I had a breakthrough or two on the laptop on the Delta flight headed home.

Can't wait to polish up some of these great new ideas and unleash them in the new year. It's a wonderful life!

Flashes of Brilliance

I never thought I'd be one of those people sitting in a conference and actually blogging about it, but here I am. I'm listening to Doug Englebart talking at the Accelerating Change conference at Stanford.

I've met a lot of "smart people" in my career. Silicon Valley is full of them. Few are truly brilliant. Most are, well, full of themselves in one way or another.

Doug Englebart is, I'm convinced, truly brilliant. He is talking in dated generalities like paradigms and human capability, but they transcend the existing computer industry and looks at the whole thing afresh. I'm boggled.

I can't sum up what he is saying, but at the heart of it is communal intelligence. Like parallel processing, it requires the collective intelligence of communities to process information. "It needs to be open source, in the same way that natural language evolved in an open way."

My favorite bit: someone told Doug Englebart a long time ago that things needed to be "easy to use" and "easy to figure out". He said, "oh, right, that's why everybody is riding tricycles." His point was that nobody really understands how they ride bicycles; it is a very complex activity, yet people figure it out and it becomes natural.

I have a lot of new things to think about.

Gaming Open Market

I'm participating in a conference this weekend. Two conferences, actually. I was at BloggerCon most of yesterday, though I've bounced back and forth to this other conference, Accelerating Change 2004, which just happens to be two buildings away from BloggerCon on the Stanford campus. I'm lucky to live near Stanford.

Anyway, I'm sitting in a session entitled Real Money in Virtual Economies: The Future of User-Created Content. They're talking about gaming, and they're also taking about trading in the sense of eBay and stock markets and such. Gaming Open Markets. Right.

I guess my head has been in the sand or something, but I have no idea what they're talking about. That doesn't happen to me all that often at conferences. I'm able to figure things out on the fly, able to grok complicated things. I went to college at an excellent university. But what the heck is this about?.

The guy who's talking right now is saying, and I quote: "...spawn camping. There's a particular dragon in the game who has a particularly high quotient of some kind of treasure ... and that sort of supports these high-margin dealers, and it incents them to these anti-social behaviors ...." I guess collaborative games have some kind of secrets or commerce or something that people are willing to spend actual money on.

I'm sitting in this particular chair at this time because, according to the schedule, the next session at 10:30 is Large-Scale Collective IQ: Facilitating its Evolution which also sounds kind of high-minded, but the speaker is Doug Englebart, the guy who's credited with inventing the computer mouse, among other things. I expect it to be quite interesting. I'm not yet ready to run out and do some real-time trading in the gaming market, but there's still a half hour for me to become a convert. What, if anything, this has to do with Accelerating Change, I'm still waiting to discover.

Meetings, Meetings, Meetings

Ask anyone you know: corporate meetings are one of the biggest wastes of time and money known to humankind, yet they persist as one of the primary mechanisms for "getting things done." Why is that?

There are many reasons. One of the more prevalent sources of meetings is self-aggrandizement. By calling a meeting, particularly one with lots of important people in it, you, too, look important! Another big contributor is the standing meeting, in which the same people meet week after week, Mondays at 11:00, and try to think of things to talk about. These are also known (to me) as lint trap meetings: they work like lint traps in dryers, catching random bits and issues that have no other forum for discussion.

Yet standing meetings are usually the only time that a team actually all sits in the same room and therefore it's hard to justify cancelling them altogether. But what to talk about?! I wrestle with this each week at our own standing staff meeting, trying to come up with meaningful agenda items. I think my team would tell you that the effort is not always successful :-)

Check out this typical corporate meeting (you really have to watch the short movie); lots of people pedaling in different directions.

Rethinking meetings requires restating their purpose. There are a handful of genuinely useful reasons to have a meeting: achieving consensus, making a decision, disseminating information in a context where a dialog or questions is important. In short, where there needs to be a conversation. If a conversation isn't taking place, the meeting is probably useless.

On Process

I am very interested in process, a word that means different things to different people, but seems to permeate everything.

The word process is from the Latin words meaning "to go forward", or proceed. The whole point of process is to get something done, or to get somewhere.

Who better to think about and implement process than a computer programmer? That's what programmers do all day long. There is no other profession that thinks even half as much about process at both the micro and macro level. Everything a computer does, every instruction it executes, has been lined up in advance by a programmer. Every contingency must be thought through. Every error condition, every likely or unlikely scenario, every conceivable thing a user might want to do.

When I think of business process I think at the micro level. What are the actual steps that must be taken to accomplish a task? Which ones of them require thought ("which folder should I put this in?"), which require mechanical effort (stapling several sheets together), which ones involve tagging with information (labeling the folder), which involve communication ("I'd better tell my boss that I've put the non-disclosure agreement in the file entitled Agreements").

The macro level of process, is of course, what drives it all, and is often overlooked. Do you really need to keep a paper copy of something that originated electronically? In the case of a non-disclosure agreement, the answer is "yes" since it has a signature on it. In most other cases, the answer is "no" because it is redundant at best and out of date and incorrect at worst. Forget about the trees: a paperless office is just more efficient in terms of process.

What fascinates me most about process is the way it involves people. Or not. If you look at most business process, either in textbooks, embodied in enterprise software, etc, it is set up from the point of view of the business itself, not from the point of view of the people who have to follow it. The life of an invoice through a chain of approvers. But not a day in the life of the Controller who may have to approve countless invoices and fit it into her busy day.

Business process is something that involves people. This is why much of it never happens the way it was intended. File servers don't get used, files are out of date, people move from group to group, and everything falls back to a blizzard of email. That's not process. Or, more to the point, email is to process as shouting and waving arms is to the British Parliament.

In my view, in order for a process to work, it starts with buy-in from the people who actually have to follow it. Without that, only police states like large multi-national banks can truly institute process.

Protocols and Structured Communication

My company builds software called InterComm. It looks at first blush like an Instant Messaging client, and in fact it is. But it's built on top of a brand new protocol that is rich and wonderful, not SIMPLE and limited. We call our protocol XSIP, and it's intended not just for chat, but for truly structured communication.

Network traffic all observes some protocol or another; that's the way networks function. A protocol is much like a human language: the software at each end of the wire needs to understand what language is being spoken in order to make sense of it. There are protocols for everything: IM, email (the protocol is SMTP, which stands for Simple Mail Transport Protocol), FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol) and hundreds more. Usually protocols are special-purpose, created to get one particular job done. Even HTTP, upon which the entire World Wide Web was created, is an extremely simple protocol that for the most part boils down to a single command: GET filename. If an entire multi-billion dollar industry can be built on top of a single command in a new protocol, just imagine what a rich structured protocol that has over 50 carefully crafted commands can do. That's what keeps me up late at night: imagining that very thing.

My career goes back to the beginnings of Adobe Systems and the PostScript programming language, in 1985. I've written two books on PostScript, in fact. PostScript was a protocol for printing pages, but unlike its predecessors, it was not a limited command set that controlled just the functions of a single printer. It was an over-arching protocol for all printers, even those that might be conceived into the future. Very ambitious, and very powerful. It was not a printer driver, it was a page description language.

We have done the same thing with InterComm and our network, though nobody can see it yet. We have an underlying structured protocol that can represent all kinds of interactions between computers, both human-to-human, which encompassess voice, video, and chat, but more importantly, human-to-computer and even computer-to-computer conversations. Filling out a web form is basically human-to-computer communication, since I knew you were wondering about that.

All of the competing IM networks offer just human-to-human conversations. Video and voice over IP seem amazing at first until you realize you're still talking to the same person, over the same channel, and although it's useful, it's not exactly revolutionary—just pick up the phone, if you know the other person is there. Works better than shouting at your computer.

Anyway, where we're going is into interesting ways for computers and people to interact with each other. We'll include lots of kinds of assets, files, calendar items, web links—the building blocks of the internet, and of communication.

If you think that the SIMPLE protocol in use by AOL and Yahoo is providing great service to our industry, consider these two small facts:

• Video, and voice, and web cams, are in fact not supported in the protocol, which is why none of that stuff interoperates between, say, YIM and AIM and iChat. All the interesting stuff is done with application-specific proprietary protocols.

• There is a 256-character limit for each message. Just try pasting something moderately-sized into AIM and see for yourself. The last time I saw a limit of 256 limit on anything of importance was in about 1986 when the Macintosh fontID range ran out (they thought nobody would ever have more than 256 fonts).

I realize that this is a bit overly technical and out in right field but I actually get excited about this stuff, and I can't believe how primitive it all is, and how much power is still untapped in the internet. I just can't believe it!

And if you think Jabber is the answer to all the world's problems, just go to their web site and try to figure it out. I dare you. Besides, XMPP is the wrong way around. It is a protocol with a lot of angle brackets, which don't help that much, but no rules (semantics) about what should be said over the network. This makes for a lot of one-off features that work between some clients, but overall it's no better than SIMPLE as a protocol; just less efficient, because of all the XML overhead.

On Being a CEO Blogger

Many people have written to me because I entitled my blog "CEO Blog". Apparently it's unusual for a CEO to be blogging. Who knew?

My old colleague Jonathan Schwartz over at Sun seems to be one of the other few. I knew Jonathan back in the early 1990's when we were both running software development companies building software for NeXT computers. He sold his (Lighthouse Design) to Sun. I worked with some of the other Lighthouse people (notably Roger Rosner) at Apple more recently; Roger built Apple's Keynote application, a great piece of work. It's amazing how the people of NeXT have quietly been so influential in changing the world. Leo Hourvitz, William Parkhurst, Dan'l Lewin, Mike Slade—there's an ex-NeXTer in the fabric of many of the important innovations in the last decade.

Anyway, being a CEO blogger shouldn't make one a celebrity; having something interesting to say is (hopefully) what blogging is about. Jonathan's blog is always extremely interesting, and he's prolific. I'd think he had a ghost writer if I didn't know better.

I have heard from many customers, and other random people, after starting my blog. It is extremely rewarding, because the dialog is personal, and direct, and thoughtful, because there is an underlying topic (some blog posting or another) that begins the conversation. I like interacting with our customers and those who might some day become customers; it's the best part of my job. I only feel a little guilty that I do it from my keyboard, in my office, instead of actually going out to meet with people.

A public thank you to Jackie Danicki for help and encouragement in my fledgling career as a blogger, and for pointing out some of the positive aspects of being a CEO blogger.

Store and Forward

Email is what they call a "store and forward" technology. You don't have to be online to receive it.

The problem is with the forward part: it doesn't. You have to go get it. This is what they call "polling". Computer scientists usually discourage polling because it's a waste of resources; constantly going out and looking for things that might be happening. A better mechanism is notification. Operating systems use notifications, deep down inside their inner workings. Cell phones do this. Telephones do this: your phone does not touch base with the central office every 5 seconds to see if there are any incoming phone calls.

Email used to actually use forwarding, back in the days of UUCP (which stands for Unix-to-Unix-CoPy). Usenet is still (mostly) store-and-forward. A system would dial another system on the modem when there was mail to be delivered. It worked great.

Nowadays POP and IMAP protocols use polling (Check New Mail...), and web mail uses an even more primitive form of polling: human beings, who need to actually browse their way to a web site.

This is becoming more and more important (despite the spam epidemic) as people manage their online and offline states, use IM software, travel across time zones, etc. The question of whether or not "you have new mail" has become an obsessive cultural diversion.

If this issue interests you, check out our software, InterComm. We use groups, and people communicate with sets of people, online or not. Messages are actually stored in the group, and they're actually forwarded to you if you're not online—through email, yes, or through text messaging on your phone or handheld, which truly is a forwarding technology. It's refreshing, and amazing, at the same time.

LOL! ROTFLMAO!

Do you know what LOL means when somebody types it in an email or an IM?

It's okay to say "no". Everybody had to learn it somewhere along the way. I have asked my niece, a high school senior, many such questions (it means laughing out loud. I'll let you ask your niece what ROTFLMAO means. I'll give a hint: the L is for "laughing".

In the old days, teenagers asked their parents about the meaning of life, and words, and concepts. Now it's the other way around: we ask our teenagers what words mean, and to explain various social phenomena.

Honey, what's blogging?

Writing stuff on your web log, Dad; now quit bugging me, I'm on the phone.

I recently was interviewed by an influential journalist (who will remain unnamed here), and we completed part of our conversation through instant messaging, since deadlines, either editorially-imposed or software-imposed, often require intermittent conversations, some on the phone, some through email, some through IM.

So my conversation with this (funny, engaging) journalist became peppered with "lol" as we discussed the industry at large and a few things that are ridiculous, or perplexing, as observations were made on one side or the other of the conversation. Hopefully some of them won't end up in print, but it's okay if they do, because I generally stand by all my remarks.

Anyway, the point is that lol doesn't really mean "laugh out loud" for most people any more (among those who use this lingo at all, of course). It has become iconic, a way to smile electronically, a broader smile than the venerable :-) emoticon.

This is a fascinating social trend. You can't smile on the telephone, but there are audible cues as to what the other person might be thinking, or feeling; you can hear someone's tone, or chuckling, and pick up on the irony or humor. This is much harder to do in text-based conversations. You've all read the admonitions to "tone it down" on email because it's so easy to be misunderstood.

In this world of high bandwidth, multimedia, videoconferencing, and real-time communication, people still love to send text messages. Michael Tchong came by our offices yesterday, and we were talking about instant messaging and emoticons. His contention is that people prefer text communication, especially IM, for a number of reasons. I think I agree, because you can say things you wouldn't face-to-face, there's no embarrassment of timing (those long pauses on the phone) or bad hair (video conferencing). It's direct, yet you can think for a few seconds before replying, and edit your reply if you need to. And it's silent (to co-workers or parents) who may think you're working very hard, at the rate the keyboard is clacking.

It's just hard to laugh out loud silently, so someone miles away can hear you.

"There are Updates; Do You Want to Install Them Now?"

Does it annoy you when software "nags" you?

I used to think it annoyed me, but I'm finding that I like it. Would I really remember to install the Windows Updates if it didn't bug me to do it? And that handy little popup that lets me postpone the nagging by an amount that feels comfortable to me—what a great idea.

And though I hate SPAM and will never, ever buy anything that anybody SPAMs me about, there are those mailing lists that I inexplicably sign up for, willingly, like the Hanna Andersson online catalog (they make great kid's clothes). I got an email tonight with the subject Our Best-Ever Playdress is Still Twirling After All These Years and I actually clicked on the link, browsed around on their site for a while, and almost bought a little sleeper for my one-year-old, before I came to my senses and remembered I was going to write something in my blog tonight.

But it got me thinking that nagging software can be useful, even appreciated, in this busy, interrupt-driven world—if done right.

Not all nagging software is done right. In fact, most isn't, though it's getting better. Some of it still irritates me. Shareware, for example, is the cornerstone of nagware. Some apps do a great job; I can remember a shareware app that displayed the usual you haven't paid me yet dialog but grayed out the OK button for some number of seconds, that increased the more often you used the program in a given day. I eventually bought a license, as I always do if I find the software genuinely useful. But others are annoying in their approach, so I delete the software, rather than pay the authors.

Let me know your thoughts about this—the nagging that works for you, the nagging that is irritating, and whether you like the increasingly common check box that says, Don't show this dialog again.

"Real Time" : My Time or Your Time?

The bathtub was invented in 1842. The telephone was invented in 1876. That means you could have sat in the bathtub for 34 years without the phone ringing.

The telephone was perhaps the first kind of real-time communication the world has ever known. And the ringing of the telephone is the insistent reminder that someone else's choice of a time to talk is being imposed upon you, on the receiving end: "hey, I want to talk to you, RIGHT NOW!". And, by convention, you have about 15 seconds to make up your mind about whether or not to answer the phone. That phenomenon has caused a lot of anxiety of the past hundred years, I'm quite sure of it.

Given that it took roughly 100 years for regular people to have answering machines and they weren't even invented until 1942, there was no respite from ringing phones for a very long time. My mother still can't resist the sound of a ringing telephone, answering machine or not [why is it that technical people always use their mothers as examples?]

There is a deep issue rooted in all of this: availability. Up until roughly the 1970's, if the phone rang, you had to answer it, or you would never know what you might have missed out on. The answering machine was a revolution, and to this day you can't watch a movie, futuristic or not, without somebody screening calls on an answering machine (ever notice how no on-screen actors ever seem to have voice mail? it's because you can't screen calls, an important plot twist in almost all movies).

Caller ID was another, smaller revolution in the telephone availability game: now you can consider whether or not to answer a call based on who it is that's calling.

These are not small things. They fundamentally shifted the balance of power from the caller back to the person being called. It saved the telephone from the scrap-heap of history, in my opinion, because without operators and administrative assistants (which few people carry on their belts along with their cell phones) it just isn't good use of time to answer the phone unless you know who's calling you.

This broadens into a much more interesting issue when you take it into the realm of other real-time communications vehicles -- like instant messaging. The only difference between email and instant messaging (for the most part) is that IM is considered to be real-time. Yet part of the power of email is that people can respond to email up to three days after it is sent and still considered socially acceptable.

So which is better? And why? The title of this blog, and the underlying rhetorical question, is who's time is it? mine, or yours?

People guard their time more jealously than perhaps anything else, as we've been taught that Time is Money, and we never have enough of it. So technologies that boast "real-time" components absolutely must consider whose time it is, and how they'd like to manage it. This goes for instant messaging, collaboration, meeting scheduling, the whole gamut.

A phrase that hasn't gotten much press but is absolutely critical for efficiency in our global 24/7 economy is time shifting. This is the idea that you can move things around in time but still keep them conceptually the same. Email is the best example: it is the same as instant messaging, except the sending and responding can be time-shifted. They're not in real time. They can be, if both parties are sitting at their desks and hitting the Send button; email uses the same transport as IM and, give or take the polling of POP and IMAP servers, just as fast. But the point is that choice of timing is up to the participants. Which is as it should be.

In my view, the technologies that succeed in the long run will be those that enable information workers to manage their time as they choose, on their terms -- time shifting. This is in direct opposition to the notion of "real-time", which, to me, is a lot like the phone ringing while you're in the bathtub: it's real-time when you're calling, and it's a compelling nuisance when you're the one being called.

Giving Birth

Today our little company, Five Across, gave birth to our 1.0 product, InterComm. It is am important day for all of us, and especially so for me, as the little darling was conceived in me, which I guess makes me its natural mother.

My friends Paul and Anita Towner just gave birth to a real baby girl a short few days/weeks ago. My own daughter Roxanne just turned 1, and Georgia turns 8 this Friday.

And so the circle of life, and software, continues. I have shipped at lot of products at this point in my career. I've stopped counting, but major versions of major products from major companies number around 20, I would say, and that doesn't even count minor products from teenie little startup companies.

I've been here before. It feels the same. It's scary. I hope the product is good, and serves the users well. I know we put a lot of work into it, and shipping it is kind of like the beginning of a human life: we've prepped and eaten right and worked hard to give birth to the product, but now we have to feed it and care for it and teach it a few things. And so we will.

If you stumble upon this blog and have no idea what I'm talking about, and have still read this far into it, please look on our home page, www.fiveacross.com to see what it's all about. Unless you found this through a search engine time warp and it's several months or years later, in which case I can't tell you what you'll find on the home page -- maybe version 4.0 of InterComm, our darling little baby in high school already.

Forgive the sentimental nature of this post. Just go download the software and try it out...

Software Design: Ease of Use vs. Discoverability

Almost every product you pick up, whether it's a hot glue gun or a $1000 impossibly complex piece of software, says this on it somewhere: "Easy to Use!"

But many products aren't so easy to use, as we all know. So this term has almost lost its meaning, like "intuitive" or "all natural". So what do you say about your product if it truly is easy to use? And what does that mean, anyway?

I want to make a distinction between ease of use, and ease of learning or discoverability.

Here's a simple example in software products: drag and drop. It may be easy to use, but how the heck do you discover that certain areas of certain windows can have things dropped on them? And just what kinds of things can you drop on them? The inverse of this is the File/Open menu item, which brings up an open panel in which you hunt around your hard drive in a tiny little modal window. That functionality is easy to discover (it's right there in the menu) but very tedious to use, particularly if you have a lot of files, in different places.

Another example is the use of styles in programs like InDesign and Word. They're really easy to figure out what they're supposed to do, and really hard to use. The problems range from scope (what in the heck will change when you click Apply) to the tedium of repeatedly selecting text then going back to the palette to click the style. NeXT Computer innovated in this area, it's now in many MacOS X apps, and still nobody has noticed: "Copy Style" and "Paste Style". You can load up the style you want to use and then, with one hand, select text; with the other, you "Paste Style" with the menu key equivalent. It's amazingly efficient and easy to accomplish. Why isn't this idea all over the place, in every product? Or Adobe Illustrator's "Transform Again" menu commmand. Brilliant.

In my view, the right choice is "easy to use, hard to discover", with some way to make it more discoverable. Tool tips, horrible as they are, were invented for this reason, to help you discover stuff that you might not otherwise have noticed. The dreaded "Tips" that pop up, with the handy check box, "Don't show me this again", are actually a really good idea. If they're telling you something you already know, at least you won't have to suffer through it again; and if you didn't know whatever it is they're telling you, often it's truly helpful. Microsoft really pioneered this approach, and, other than overdoing it with dancing paperclips and puppies, did a very good job of integrating it into their products. Their only mistake, I think, was having 38 small opt out preferences, rather than one big giant "leave me alone!" preference (I'm thinking of Word here, with all its helpful grammar checkers, date suggesters, "You seem to be writing a letter; want some help?" and stuff like that).

Ease of use boils down to this: can you remember, a month after you last used something, how to use it efficiently?

Discoverability is a bit different: can you figure out most of the functionality of a program within the first 10 minutes, "cruising the menus"?

I think one of the best (simple) ideas of all time in this category is, I believe, Microsoft's. It's the Recent Documents menu. It does exactly what you want 99% of the time, bringing back the documents you were most recently working on, regardless of where on your computer they might be living—and it is obvious how the feature works.

Why Big Teams Don't Work

I read somewhere that Microsoft has a 24-hour system for software development with automated builds going on in the night and literally hundreds of programmers on their bigger projects.

The obvious question, then, is why isn't their software dozens of times better than everyone else's? It's not only "not as good" much of the time, or "marginally better" occasionally, but it's full of bugs, expensive, and, well, just not that great. Microsoft has more money than anyone else on the planet. They're doing what they think is best. They have not bought too many copies of The Mythical Man Month, or read them.

So what's on the other end of the spectrum? Probably shareware, which typically has a single author and is a labor of love. There's lots of really good shareware in the world, some of it, frankly, rivals Microsoft's offerings.

So why is it that small teams work better than large ones, or at least anecdotally appear to?

I have a lot of theories, and for the record, I am a proponent of small teams and have never run a software project with more than 5 engineers, including myself.

My principle theory is simply that projects involve human beings, and as a species we don't handle complexity very well. We are wired to simplify: vision simplifies what is really there, recognizing patterns; socially we simplify: you're either Good, or you're Bad, Guilty or Innocent; intellectually we simplify: the scientific method is based on reducing an experiment down to as few variables as possible so you can "control" for them and measure the one you're interested in. Humans can support up to 3 simultaneously contradictory thoughts at once, before melting down into indecision and confusion.

So what happens when you put 400 programmers on one project and try to run it?

The first thing that happens is you need at least 50 managers and project managers and coordinators and cross-functional liaisons and whatever else, just to try to "communicate" about the project. Right, like that's going to help.

The second thing that happens is nobody can really get work done any more. You try to edit a file, make some changes, add a new parameter to an API somewhere. You can't just check the file into CVS (or SourceSafe, in the Microsoft case). You have to find all the people who are using the API and let them know. You have to figure out if anybody else is modifying the same file, for different reasons. You have to stop working, and talk about working instead. God forbid it turns into 3 or 4 meetings, a few specifications, and, conservatively, about 50 email messages.

I am a programmer, among other things. I've changed API's many times. With a good search-and-replace tool and a thorough understanding of all the places an API is used, you can make a sweeping, and I mean sweeping change, without any errors, fully validated and tested, in a couple of hours.

So efficiency is part of it. Confusion, cross-currents, communication, and all the things that fall out from that: backlash, politics, sandbagging, employee turnover, morale problems, managers on a tirade trying to "fix" it; you may have seen some of this. It's preventable, believe it or not.

Just use small teams. Small teams are how the best work in the world gets done. Even if it's a "big project". How many people do you think it took to build the Golden Gate Bridge? I don't know, unfortunately, but I bet you it was at most a couple hundred. If Microsoft built the Golden Gate, do you think they'd put fewer than 2,000 people on it? Do you think it would be on schedule?

I don't mean to pick on Microsoft, though they're the biggest, most resource-heavy example of large-scale product development on Earth. They're certainly not unique when it comes to large-team molasses-style development.

Maybe this is why "outsourcing" is becoming popular. Hey, maybe if we abdicate this project completely and give it to a team in Russia (translation: 1 or 2 really smart people) it will come in on time and under budget?!

Here's a suggestion: outsource it to your 2 best engineers instead. Set them up in Marin with no phone lines. They'll get it done, I promise.

File Sharing through Email

So I'm working on a spreadsheet and I email it to 10 people. I fix a formula, widen a column, and send another revision around. One more change, and ... maybe I'd better send it to only the 4 people who ever actually open it and give me any feedback, until it's done. You send an IM to one of them: "Did you get the updated file I emailed you?"

You've been there. You do a few more revs, and you rename the file, "Final 1", "Final 2", "Final 3". And finally you're done. You send one more email out to the group of 10, "Final 5.xls".

A week goes by. You start getting email from some of those 10 people. "Do I have the latest version?" or "Can you send me that spread sheet you're working on?"

This is how most people share documents and work on them as a group. The above scenario generates 54 (fifty-four) copies of the spreadsheet (including the 5 final and one draft revisions I kept on my machine), and distributes it over at least 11 computers.

No wonder we need 200GB disk drives.

There is a better way. It's called centralized file sharing. The problem is, nobody uses it, because it's too much of a hassle, another password to remember, somebody else has to set it up, maintain it, back it up, etc. It just doesn't really work, does it?

"I sent you the final version yesterday, Final 6.xls; did you get it?"

Putting the File Cabinet Next to the Water Cooler

There is a lot of software out there in the world. Much of it falls into three categories, as I see it:

1. Document-Centric Apps: This category of software includes spreadsheets, word processors, Photoshop, CAD/CAM, and a host of other applications.
   
   
2. Communication: Email, chat, conferencing, even phones.
   
   
3. Web-based: This has become a category in itself, and is not quite "software" in the traditional sense, but replaces some kinds of traditional software. Its distinguishing characteristic is that there is a server in the sky that is where things live, and you upload things to it (blog text, for example, or photo files, or form data) or, more frequently, download things from it (news, information, weather reports, dictionary entries, dance steps, and just about everything else that has existed throughout history).
   

Occasionally software in one category attempts to take on some of the functionality of the others. Email has evolved "attachments" to carry a payload, Word attempts to do web publishing, Fractal Design's Painter had a mostly useless "NetPainter" feature added onto the side of it. Web sites, originally all "download", have been adding "upload" capabilities bit by bit. Even document creation, to a small degree. Blogging software is, at the end of the day, just an HTML authoring tool that makes it easy to create/edit/upload a bit of text. It's not all that different from HTML editors that have gone before, other than being web-based. As I type this, I'm manually typing <li><b> tags and hitting the Preview button in blogger.com's posting window to see what it's going to look like. What happened to WYSIWYG editing?

These are, for the most part, evolutionary cul-de-sacs. They suggest the missing functionality in the application category, but don't really move the software into a different category.

The next revolution is to truly integrate these disparate kinds of technology. I like to think of it as putting the file cabinet next to the water cooler. So you're communicating--emailing, chatting, maybe authoring documents as well, but all in different places, with different kinds of software. What you really want is to have your communication built around your documents, and keep them in a global place where you can refer to them, revise them, share them, and there is just one definitive version of the document, not 13 revisions with names like "Budget 02 final-1.xls" and "Budget 02 final-3-Glenn.xls".

This requires a new breed of software altogether. A new network. A new protocol. A mini-revolution. HTML and web servers created a revolution by simply adding a little structure to file transfer. I think there is another revolution brewing by adding two-way communication and real-time aspects to the model, throwing in peer-to-peer capabilities, and seasoning to taste.

Yahoo and AOL: out of business

Both Yahoo and AOL recently announced their exit from the "enterprise instant messaging" category of software. This comes as no surprise to some of us; they were never really in it to begin with.

But not everyone saw this coming, and many are at a loss for a business instant messaging solution. I personally see this as a big opportunity, because we offer Workgroup Instant Messaging, a dramatic improvement upon simple text messages back and forth. It's group-based, and it has built-in file sharing.

But it's more a sign of a regime change. Instant Messaging is huge, but it's a victim of its own success. AOL and Yahoo are losing money every day supporting vast networks of people chit-chatting on their IM networks. You'd think that this would drive them toward business users, but their products and company DNA just don't support that.

YIM and AIM and MSN are consumer apps. Perhaps even "teenager apps" or "young-adult apps". The feature set reflects that. They're even launching things like love.com and yahoo personals and various flavors of dating services, thinking perhaps that people might actually pay for those services. Did I mention checkers? I don't know anybody above the age of 8 who plays checkers. It's just not that interesting a game. Do we really need to play checkers over the internet now? What exactly are they thinking?

Meanwhile, for people who are just trying to get work done and communicate with people, what to do?

I say embrace the future and look around for something new and better. We hope you'll consider our software, of course, but this is an evolving world and it does get a lot better than YIM and AIM. If nothing else, you won't miss the advertising.

How do you say goodbye?

I use Instant Messengers, several of them, even though I don't like shortcuts and acronyms by nature. Luckily, I type fast.

But there are some funny social aspects to it that suggest that it's a technology in its infancy. Take the issue of "saying goodbye".... There is no convention for this yet on IM. I do it differently with each individual, as you probably do as well.

"See ya."
"OK. Bye."
"Have a good evening."
"Thanks, you too."
"Talk to you tomorrow."
"Definitely."
"Thanks for IM'ing me."
"Glad you were there."
"Bye."
"ttfn"

And still both of you leave the window open, pushed to the side a little, to avoid the dreaded "Glenn has left the chat", which seems a little cold and almost insulting.

Imagine a telephone call where neither party is quite sure when the conversation is over. You say your goodbyes, listen a little to see if the other person is really done, say goodbye a few more times, then gently lay the phone down on your table and wait for a half hour or so, and if it stays quiet, you hang it up.

That's what IM is like, and it's just weird. One friend of mine draws a horizontal line with dashes ------------------ as if to say "don't you dare type past this line." Another friend writes "VCD" (for 'via con dios'). Doesn't that mean "goodbye forever?" I'm not quite sure :)

So we fumble along, inventing our own solutions. If you have a suggestion for how this is supposed to be done, or if you think this is already solved and I'm just missing something, add a comment....

The Interconnected World

I started Five Across because I thought that Instant Messaging was a very primitive technology with a lot of promise, and I saw a way to dramatically improve it. In just six months I have learned an amazing amount about the interconnected world we live in, which is exploding like the first galaxies, at an incredible rate of speed, headed in every direction at the same time.

Blogs are part of it. Messaging is part of it. Email is part of it. Even FTP and SSH are part of it. The internet is here to stay, and the wires now are everywhere, in all of our homes, in our collective consciousness. Even the African subcontintent is blossoming with bloggers, as a Stanford Fellow friend from South Africa is helping to make it happen.

We at Five Across intend to change the world, or at least part of it. I had a hand in changing the world at Apple Computer, where I was the driving force behind iMovie and iPhoto. Those applications are personal, consumer-oriented media tools, but their purpose is to share your life with friends and family, and when we added the Share tab to iPhoto, it changed everything.

People live and work in teams, in groups, and we're building that right into the core of the Five Across network. It isn't just a menu item, it's an architecture, and it's incredibly powerful. We hope you'll check it out, use it, love it, and recommend it to your friends and co-workers.