It's Charisma, Stupid
November 2004, corrected June 2006
Occam's razor says we should prefer the simpler of two explanations.
I begin by reminding readers of this principle because I'm about
to propose a theory that will offend both liberals and conservatives.
But Occam's razor means, in effect, that if you want to disagree
with it, you have a hell of a coincidence to explain.
Theory: In US presidential elections, the more
charismatic candidate wins.
People who write about politics, whether on the left or the right,
have a consistent bias: they take politics seriously.  When one
candidate beats another they look for political explanations.  The
country is shifting to the left, or the right.  And that sort of
shift can certainly be the result of a presidential election, which
makes it easy to believe it was the cause.
But when I think about why I voted for Clinton over the first George
Bush, it wasn't because I was shifting to the left.  Clinton just
seemed more dynamic.  He seemed to want the job more.  Bush seemed
old and tired.  I suspect it was the same for a lot of voters.
Clinton didn't represent any national shift leftward.
[
1
]
He was
just more charismatic than George Bush or (God help us) Bob Dole.
In 2000 we practically got a controlled experiment to prove it:
Gore had Clinton's policies, but not his charisma, and he suffered
proportionally.
[
2
]
Same story in 2004. Kerry was smarter and more
articulate than Bush, but rather a stiff.  And Kerry lost.
As I looked further back, I kept finding the same pattern.
Pundits said Carter beat Ford
because the country distrusted the Republicans after Watergate.
And yet it also happened that Carter was famous for his big grin
and folksy ways, and Ford for being a boring klutz.  Four years
later, pundits said the country had lurched to the right.  But
Reagan, a former actor, also happened to be even more charismatic
than Carter (whose grin was somewhat less cheery after four stressful
years in office).  In 1984 the charisma gap between Reagan and
Mondale was like that between Clinton and Dole, with similar results.
The first George Bush managed to win in 1988, though he would later
be vanquished by one of the most charismatic presidents ever, because
in 1988 he was up against the notoriously uncharismatic
Michael Dukakis.
These are the elections I remember personally, but apparently the
same pattern played out in 1964 and 1972.  The most recent
counterexample appears to be 1968, when Nixon beat the more charismatic Hubert
Humphrey.  But when you examine that election, it tends to support
the charisma theory more than contradict it.  As Joe McGinnis
recounts in his famous book
The Selling of the President 1968
,
Nixon knew he had less charisma than Humphrey, and thus simply
refused to debate him on TV.  He knew he couldn't afford to let the
two of them be seen side by side.
Now a candidate probably couldn't get away with refusing to debate.
But in 1968 the custom of televised debates was still evolving.  In
effect, Nixon won in 1968 because voters were never allowed to see
the real Nixon.  All they saw were carefully scripted campaign
spots.
Oddly enough, the most recent true counterexample is probably 1960.
Though this election is usually given as an example of the power
of TV, Kennedy apparently would not have won without fraud by party
machines in Illinois and Texas.  But TV was still young in 1960;
only 87% of households had it.
[
3
]
Undoubtedly TV helped Kennedy,
so historians are correct in regarding this election as a
watershed.  TV required a new kind of candidate. There would be no
more Calvin Coolidges.
The charisma theory may also explain why Democrats tend to lose
presidential elections.  The core of the Democrats' ideology seems
to be a belief in government.  Perhaps this tends to attract people
who are earnest, but dull.  Dukakis, Gore, and Kerry were so similar
in that respect that they might have been brothers.  Good thing for
the Democrats that their screen lets through an occasional Clinton,
even if some scandal results.
[
4
]
One would like to believe elections are won and lost on issues, if
only fake ones like Willie Horton.  And yet, if they are, we have
a remarkable coincidence to explain.  In every presidential election
since TV became widespread, the apparently more charismatic candidate
has won.  Surprising, isn't it, that voters' opinions on the issues
have lined up with charisma for 11 elections in a row?
The political commentators who come up with shifts to the left or
right in their morning-after analyses are like the financial reporters
stuck writing stories day after day about the random fluctuations
of the stock market.  Day ends, market closes up or down, reporter
looks for good or bad news respectively, and writes that the market
was up on news of Intel's earnings, or down on fears of instability
in the Middle East.  Suppose we could somehow feed these reporters
false information about market closes, but give them all the other
news intact.  Does anyone believe they would notice the anomaly,
and not simply write that stocks were up (or down) on whatever good
(or bad) news there was that day?  That they would say, hey, wait
a minute, how can stocks be up with all this unrest in the Middle
East?
I'm not saying that issues don't matter to voters.  Of course they
do.  But the major parties know so well which issues matter how
much to how many voters, and adjust their message so precisely in
response, that they tend to split the difference on the issues,
leaving the election to be decided by the one factor they can't
control: charisma.
If the Democrats had been running a candidate as charismatic as
Clinton in the 2004 election, he'd have won.  And we'd be reading
that the election was a referendum on the war in Iraq, instead of
that the Democrats are out of touch with evangelical Christians in
middle America.
During the 1992 election, the Clinton campaign staff had a big sign
in their office saying "It's the economy, stupid." Perhaps it was
even simpler than they thought.
Postscript
Opinions seem to be divided about the charisma theory.  Some say
it's impossible, others say it's obvious.  This seems a good sign.
Perhaps it's in the sweet spot midway between.
As for it being impossible, I reply: here's the data; here's the
theory; theory explains data 100%.   To a scientist, at least, that
means it deserves attention, however implausible it seems.
You can't believe voters are so superficial that they just choose
the most charismatic guy?  My theory doesn't require that.  I'm not
proposing that charisma is the only factor, just that it's the only
one
left
after the efforts of the two parties cancel one
another out.
As for the theory being obvious, as far as I know, no one has
proposed it before.  Election forecasters are proud when they can
achieve the same results with much more complicated models.
Finally, to the people who say that the theory is probably true,
but rather depressing: it's not so bad as it seems.  The phenomenon
is like a pricing anomaly; once people realize it's there, it will
disappear.  Once both parties realize it's a waste of time to
nominate uncharismatic candidates, they'll tend to nominate only
the most charismatic ones.  And if the candidates are equally
charismatic, charisma will cancel out, and elections will be decided
on issues, as political commentators like to think they are now.
Notes
[
1
]
As Clinton himself discovered to his surprise when, in one of
his first acts as president, he tried to shift the military leftward.
After a bruising fight he escaped with a face-saving compromise.
[
2
]
True, Gore won the popular vote. But politicians know the electoral
vote decides the election, so that's what they campaign for. If Bush
had been campaigning for the popular vote he would presumably have
got more of it. (Thanks to judgmentalist for this point.)
[
3
]
Source: Nielsen Media Research.  Of the remaining 13%, 11 didn't
have TV because they couldn't afford it.  I'd argue that the missing
11% were probably also the 11% most susceptible to charisma.
[
4
]
One implication of this theory is that parties shouldn't be too
quick to reject candidates with skeletons in their closets.
Charismatic candidates will tend to have more skeletons than squeaky
clean dullards, but in practice that doesn't seem to lose elections.
The current Bush, for example, probably did more drugs in his
twenties than any preceding president, and yet managed to get elected
with a base of evangelical Christians.  All you have to do is say
you've reformed, and stonewall about the details.
Thanks
to Trevor Blackwell, Maria Daniels, Jessica Livingston,
Jackie McDonough, and Robert Morris for reading drafts of this, and
to Eric Raymond for pointing out that I was wrong about 1968.
Comment
on this essay.
What Charisma Is
Politics and the Art of Acting
Japanese Translation


@mattyglesias The fact that DOGE didn't find it doesn't mean it's not there.

If you're looking for startup ideas, here are some that YC partners want to fund.

@JimPethokoukis The real source of the difference between the two graphs has little to do with regulation. It's the two entwined facts that (a) that the chip industry originated in the US, and (b) startups in the modern sense originated in the US.

@JimPethokoukis It's a startling graph, and it's true that Europe is too focused on regulation, but the latter is not the cause of the former. The reason the US has Microsoft and Apple and Europe doesn't is not that Europe in the 1970s was too focused in regulation.

@plzaccelerate I'm not talking about whether we're in an AI bubble. This video is from a talk long before the AI boom started.

@slimjimmy You should use lists to represent source code because this makes it natural to write programs that operate on it.

@pitdesi Apparently in the 1930s mobsters all started to copy the way mobsters acted in movies.

@quirkyllama Is there any limit to what you would consider justified to do to children because of this?

@0xshei Interesting question. Maybe if you're already making lots  of money and your weekly growth rate has been consistently good for 4 or 5 months, you already have all the connections you need, and you're not making something you want to sell to YC cos.

"They should be ashamed of their silence." This is not a bunch of student protestors. This is the editorial board of the Financial Times. https://t.co/V2cyhJW2i5


@paultoo One feature would be something like the assistants politicians have, who whisper to them the names and bios of people they're meeting.

@colin_fraser If you're right, then game theory and indigenous maths should yield similar numbers of new insights. I'm pretty sure they don't. But you probably already knew that, which means you're deliberately mistaken, aka intellectually dishonest.

@colin_fraser You compared this class to a class on game theory, and implied, I think dishonestly, that anyone disparaging it was doing the equivalent of disparaging game theory.

@colin_fraser Can you give us a few examples of new theorems that the study of "indigenous maths" has yielded that in your opinion are comparable to the most important results in game theory?

@mbateman @Gena_I_Gorlin I notice you deliberately hung art at kid height. I did that too!

@AnechoicMedia_ It wasn't what got them into this trouble, but these are not the first regulators who've targeted them.

@BillyM2k Actually some of the people mad at me for talking about Palestine have brains, but have just temporarily suspended their use due to rage and grief. The people who think blocking traffic is a good idea are all just idiots though.

@ahistoryinart Not bad. They're all over the place, but that painting could go for about that.

@dened21 @andrewtalbot That particular storm bothered me comparatively little in proportion to its size, because the things people were saying were so absurd.

@animated_memory Oooh, that is such a clever trick. Do you remember his name?


I have to keep explaining this to people from universities who want to teach students about "entrepreneurship." You can't actually teach them to be founders, or they stop being students.

What universities should do instead is help students build the foundation of knowledge that startup ideas grow out of. They're good at that. But this is the last thing some dean in charge of "entrepreneurship" wants to hear. He wants to do something about startups!

Founders in trouble are often dismayed by how fast corp dev people can sense their desperation. You'll be less surprised if you remember this is all they *can* sense. They can't judge technology or talent. All they can judge is your eagerness. So of course they're good at it.

When advising founders in such situations, I don't tell them to hide their desperation. I tell them to actually be less desperate. This is usually possible. There's usually room to panic less than inexperienced founders.

Something I told 13 yo: Many if not most philosophical controversies are artifacts of trying to using natural language at a higher resolution than it will support.

"Kircher was largely neglected until the late 20th century. One writer attributes his rediscovery to the similarities between his eclectic approach and postmodernism."

— Wikipedia on Athanasius Kircher. Not exactly a recommendation.

An unexpected benefit of needing reading glasses: I often misinterpret things at first glance, and the misinterpretations are sometimes more interesting than reality.

https://t.co/FJZidRewmn

A reminder, since we've practically forgotten, of what real confidence looks like.

If you want proof of what a good deal YC is for founders, I just told a UK startup I've invested several million pounds in that I'd be happy if they wanted to do YC. I'd get diluted alongside them, but I know we'd all be net ahead.

This is one of the cleverest stories in startups. For years we'd been worrying about how to finance the airliner. Then Boom realized that if they could build jet engines, they could build gas turbines, and fund the airliner with the profits.


@barryeisler It depends how your power is obtained. If it comes from sucking up to an authoritarian leader, definitely not.

@levie Or: AI delivers schlock that looks good enough to the customers, and they just use that instead of hiring designers.

@AkhandPratap_ @garrytan So you don't think the problem is important enough that you're willing to do anything about it yourself, and yet you want me to?

@TolkienWonder Do you know what he is writing in this picture?

@sama Lots of people need to be awake when load is high?

Did he get the job based on merit?

BOOM

I've seen a lot of these graphs and this is among the best I've seen. This is what it looks like when a startup works.

@AkhandPratap_ @garrytan Why don't you, if you think that's an important problem?

@nileshghai That's why the "net".

@0x506c61746f Startup ideas have little monetary value. That's a different sense of idea and a different kind of value.


So if you're interested in programming, go ahead and focus on it. And if you're not, don't. Just as with every other subject.

Hard to say if it will be this extreme, but if you average this together with the people saying that all the programming jobs will disappear, you have a reasonable estimate of what we know for sure about the future of programming as a career: nothing.

@odinsbadeye No, it is not.

https://t.co/3UyY0wztiL

@KevinHenrikson You're conflating two separate companies, Artix (the failed builder of sites for galleries) and Viaweb (the most popular online store software of its time). Viaweb made lots of money. That was what Yahoo bought.

Banning facial coverings in public places is a little too obviously cultural warfare. You know they're not going to be arresting brides wearing veils, or people with scarves wrapped around their faces on cold days.

@elgindy_ I don't think they do, actually. If they did, the massive lobbying effort wouldn't be necessary.

@archaeologyart That binding is by Zaehnsdorf apparently.

@Scholars_Stage Will anyone be our era's Homer?

Possible heuristic for deciding what to do this year: what do you wish you'd done last year?

@billclerico What are the forces at work that will produce this weirdness?


@LouisLebbos Yes, the light from the windows was reflecting off my screen.

@tracewoodgrains This has always been possible. It's often used by spammers.

This is what the other half of it looks like. https://t.co/id2Rhs0ldi

My flight was delayed so I cleaned up my office. https://t.co/TwtixGNzMu

@Liv_Boeree These people are simply insane. They were always out there; we just couldn't see it before. But if you could read people's minds as you walked down the street, it would look like this all the time.

@Rob_Pointon @Middleport_Pot Looks familiar. Is that the same canal?

Whoah, one other Covid change that stuck was staying home. https://t.co/PBfPRGXSAp

@waitbutwhy I don't think you need to say anything. You are actually giving them something in return, though it's implicit: you will now owe them a favor.

@michael_nielsen It's related to the fact that in paintings of the Last Judgment, the heavens are so boring compared to the hells.

In fact, we'll be able to use this as heuristic to show where wokeness still has the upper hand. Wherever they haven't put the statues back is where we need to focus on changing things.


Disconnecting Distraction
Note: The strategy described at the end of this essay didn't work.
It would work for a while, and then I'd gradually find myself
using the Internet on my work computer.  I'm trying other
strategies now, but I think this time I'll wait till I'm sure
they work before writing about them.
May 2008
Procrastination feeds on distractions.  Most people find it
uncomfortable just to sit and do nothing; you avoid work by doing
something else.
So one way to beat procrastination is to starve it of distractions.
But that's not as straightforward as it sounds, because there are
people working hard to distract you.  Distraction is not a static
obstacle that you avoid like you might avoid a rock in the road.
Distraction seeks you out.
Chesterfield described dirt as matter out of place.  Distracting
is, similarly, desirable at the wrong time.  And technology is
continually being refined to produce more and more desirable things.
Which means that as we learn to avoid one class of distractions,
new ones constantly appear, like drug-resistant bacteria.
Television, for example, has after 50 years of refinement reached
the point where it's like visual crack.  I realized when I was 13
that TV was addictive, so I stopped watching it.  But I read recently
 that the average American watches
4 hours
of TV a day.  A quarter
of their life.
TV is in decline now, but only because people have found even more
addictive ways of wasting time.  And what's especially dangerous
is that many happen at your computer.  This is no accident.  An
ever larger percentage of office workers sit in front of computers
connected to the Internet, and distractions always evolve toward
the procrastinators.
I remember when computers were, for me at least, exclusively for
work.  I might occasionally dial up a server to get mail or ftp
files, but most of the time I was offline.  All I could do was write
and program.  Now I feel as if someone snuck a television onto my
desk.  Terribly addictive things are just a click away.  Run into
an obstacle in what you're working on?  Hmm, I wonder what's new
online.  Better check.
After years of carefully avoiding classic time sinks like TV, games,
and Usenet, I still managed to fall prey to distraction, because
I didn't realize that it evolves.  Something that used to be safe,
using the Internet, gradually became more and more dangerous.  Some
days I'd wake up, get a cup of tea and check the news, then check
email, then check the news again, then answer a few emails, then
suddenly notice it was almost lunchtime and I hadn't gotten any real
work done.  And this started to happen more and more often.
It took me surprisingly long to realize how distracting the Internet
had become, because the problem was intermittent.  I ignored it the
way you let yourself ignore a bug that only appears intermittently.  When
I was in the middle of a project, distractions weren't really a
problem.  It was when I'd finished one project and was deciding
what to do next that they always bit me.
Another reason it was hard to notice the danger of this new type
of distraction was that social customs hadn't yet caught up with
it.  If I'd spent a whole morning sitting on a sofa watching TV,
I'd have noticed very quickly.  That's a known danger sign, like
drinking alone.  But using the Internet still looked and felt a
lot like work.
Eventually, though, it became clear that the Internet had become so much
more distracting that I had to start treating it differently.
Basically, I had to add a new application to my list of known time
sinks: Firefox.
* * *
The problem is a hard one to solve because most people still need
the Internet for some things.  If you drink too much, you can solve
that problem by stopping entirely.  But you can't solve the problem
of overeating by stopping eating.  I couldn't simply avoid the
Internet entirely, as I'd done with previous time sinks.
At first I tried rules.  For example, I'd tell myself I was only
going to use the Internet twice a day.  But these schemes never
worked for long.  Eventually something would come up that required
me to use it more than that.  And then I'd gradually slip back
into my old ways.
Addictive things have to be treated as if they were sentient
adversaries—as if there were a little man in your head always
cooking up the most plausible arguments for doing whatever you're
trying to stop doing.  If you leave a path to it, he'll find it.
The key seems to be visibility.  The biggest ingredient in most bad habits
is denial.  So you have to make it so that you can't merely
slip
into doing the thing you're trying to avoid.  It has to set off
alarms.
Maybe in the long term the right answer for dealing with Internet
distractions will be
software
that watches and controls them.  But
in the meantime I've found a more drastic solution that definitely
works: to set up a separate computer for using the Internet.
I now leave wifi turned off on my main computer except when I need
to transfer a file or edit a web page, and I have a separate laptop
on the other side
of the room that I use to check mail or browse the web.  (Irony of
ironies, it's the computer Steve Huffman wrote Reddit on.  When
Steve and Alexis auctioned off their old laptops for charity, I
bought them for the Y Combinator museum.)
My rule is that I can spend as much time online as I want, as long
as I do it on that computer.  And this turns out to be enough.  When
I have to sit on the other side of the room to check email or browse
the web, I become much more aware of it.  Sufficiently aware, in
my case at least, that it's hard to spend more than about an hour
a day online.
And my main computer is now freed for work.  If you try this trick,
you'll probably be struck by how different it feels when your
computer is disconnected from the Internet.  It was alarming to me
how foreign it felt to sit in front of a computer that could
only be used for work, because that showed how much time I must
have been wasting.
Wow.  All I can do at this computer is work.  Ok, I better work
then.
That's the good part.  Your old bad habits now help you to work.
You're used to sitting in front of that computer for hours at a
time.   But you can't browse the web or check email now.  What are
you going to do?  You can't just sit there.  So you start working.
Good and Bad Procrastination
Spanish Translation
Arabic Translation
Catalan Translation
Russian Translation
Spanish Translation


@elonmusk VotingWorks's voting machines are open source, offline, use paper ballots, and have been proven in real elections.

https://t.co/YRvckYntG5

Between 2000 and 2020, Americans became gradually less willing to express their beliefs publicly. I wouldn't be surprised if that has changed recently though. https://t.co/OGys0isD0c

"Stirring unrest" is the most weaselly expression I've heard in a long time. What does that even mean? What it means is that this guy can't find anything specific to accuse Elon of.

@jonatanpallesen @eyeslasho Turns out I already had him blocked.

@burgessdryan None of the startups I've met recently feel that way.

@bobbyfijan I would capture it for use as an office.

This would actually be a good way to monitor the security of devices.

@MandelsonC No. But I'm good at Lisp macros.

For sure there will be individual companies that tank, and branches of research that fail. There always are. But this thing is real. If anything, alarmingly real.

I was just talking with a friend who's been investing in startups for about 20 years, and we both agreed that one of the weirdest things about the AI boom is seeing journalists writing their usual contrarian stories about how it's a bubble about to burst.


The Other Road Ahead
September 2001
(This article explains why much of the next generation of software
may be server-based, what that will mean for programmers,
and why this new kind of software is a great opportunity for startups.
It's derived from a talk at BBN Labs.)
In the summer of 1995, my friend Robert Morris and I decided to
start a startup.  The PR campaign leading up to Netscape's IPO was
running full blast then, and there was a lot of talk in the press
about online commerce.  At the time there might have been thirty
actual stores on the Web, all made by hand.  If there were going
to be a lot of online stores, there would need to be software for making
them, so we decided to write some.
For the first week or so we intended to make this an ordinary
desktop application.  Then one day we had the idea of making the
software run on our Web server, using the browser as an
interface.  We tried rewriting the software to work over
the Web, and it was clear that this was the way to go.
If we wrote our software to run on the server, it would be a lot easier
for the users and for us as well.
This turned out to be a good plan.  Now, as
Yahoo Store
, this
software is the most popular online store builder, with
about 14,000 users.
When we started Viaweb, hardly anyone understood what we meant when
we said that the software ran on the server.  It was not until
Hotmail was launched a year later that people started to get it.
Now everyone knows that this is a valid approach.  There is
a name now for what we were: an Application Service Provider,
or ASP.
I think that a lot of the next generation of software will be
written on this model.  Even Microsoft, who have the most to
lose, seem to see the inevitablity of moving some things off
the desktop. If software moves
off the desktop and onto servers, it will mean a very different
world for developers.  This article describes the surprising
things we saw, as some of the first visitors to this new world.
To the extent software does move onto
servers, what I'm describing here is the future.
The Next Thing?
When we look back on the desktop software era, I think we'll marvel
at the inconveniences people put up with, just as we marvel now at
what early car owners put up with.  For the first twenty or thirty
years, you had to be a car expert to own a car.  But cars were such
a big win that lots of people who weren't car experts wanted to
have them as well.
Computers are in this phase now.  When you own a desktop computer,
you end up learning a lot more than you wanted to know about what's
happening inside it.  But more than half the households in the US
own one.  My mother has a computer that she uses for email and for
keeping accounts.  About a year ago she was alarmed to receive a
letter from Apple, offering her a discount on a new version of the
operating system.  There's something wrong when a sixty-five year
old woman who wants to use a computer for email and accounts has
to think about installing new operating systems.  Ordinary users
shouldn't even know the words "operating system," much less "device
driver" or "patch."
There is now another way to deliver software that will save users
from becoming system administrators.  Web-based applications are
programs that run on Web servers and use Web pages as the user
interface.  For the average user this new kind of software will be
easier, cheaper, more mobile, more reliable, and often more powerful
than desktop software.
With Web-based software, most users won't have to think about
anything except the applications they use.  All the messy, changing
stuff will be sitting on a server somewhere, maintained by the kind
of people who are good at that kind of thing.  And so you won't
ordinarily need a computer, per se, to use software.  All you'll
need will be something with a keyboard, a screen, and a Web browser.
Maybe it will have wireless Internet access.  Maybe it will also
be your cell phone.  Whatever it is, it will be consumer electronics:
something that costs about $200, and that people choose mostly
based on how the case looks.  You'll pay more for Internet services
than you do for the hardware, just as you do now with telephones. [1]
It will take about a tenth of a second for a click to get to the
server and back, so users of heavily interactive software, like
Photoshop, will still want to have the computations happening on
the desktop.  But if you look at the kind of things most people
use computers for, a tenth of a second latency would not be a
problem.  My mother doesn't really need a desktop computer, and
there are a lot of people like her.
The Win for Users
Near my house there is a car with a bumper sticker that reads "death
before inconvenience."  Most people, most of the time, will take
whatever choice requires least work.  If Web-based software wins,
it will be because it's more convenient.  And it looks as if it
will be, for users and developers both.
To use a purely Web-based application, all you need is a browser
connected to the Internet.  So you can use a Web-based application
anywhere.  When you install software on your desktop computer, you
can only use it on that computer.  Worse still, your files are
trapped on that computer.  The inconvenience of this model becomes
more and more evident as people get used to networks.
The thin end of the wedge here was Web-based email.  Millions of
people now realize that you should have access to email messages
no matter where you are.  And if you can see your email, why not
your calendar?
If you can discuss a document with your colleagues,
why can't you edit it?  Why should any of your data be trapped on
some computer sitting on a faraway desk?
The whole idea of "your computer" is going away, and being replaced
with "your data."  You should be able to get at your data from any
computer.  Or rather, any client, and a client doesn't have to be
a computer.
Clients shouldn't store data; they should be like telephones.  In
fact they may become telephones, or vice versa.  And as clients
get smaller, you have another reason not to keep your data on them:
something you carry around with you can be lost or stolen.   Leaving
your PDA in a taxi is like a disk crash, except that your data is
handed to
someone else
instead of being vaporized.
With purely Web-based software, neither your data nor the applications
are kept on the client.  So you don't have to install anything to
use it.  And when there's no installation, you don't have to worry
about installation going wrong.  There can't be incompatibilities
between the application and your operating system, because the
software doesn't run on your operating system.
Because it needs no installation, it will be easy, and common, to
try Web-based software before you "buy" it.  You should expect to
be able to test-drive any Web-based application for free, just by
going to the site where it's offered.  At Viaweb our whole site
was like a big arrow pointing users to the test drive.
After trying the demo, signing up for the service should require
nothing more than filling out a brief form (the briefer the better).
And that should be the last work the user has to do.  With Web-based
software, you should get new releases without paying extra, or
doing any work, or possibly even knowing about it.
Upgrades won't be the big shocks they are now.  Over time applications
will quietly grow more powerful.  This will take some effort on
the part of the developers.  They will have to design software so
that it can be updated without confusing the users.  That's a new
problem, but there are ways to solve it.
With Web-based applications, everyone uses the same version, and
bugs can be fixed as soon as they're discovered.  So Web-based
software should have far fewer bugs than desktop software.  At
Viaweb, I doubt we ever had ten known bugs at any one time.  That's
orders of magnitude better than desktop software.
Web-based applications can be used by several people at the same
time.  This is an obvious win for collaborative applications, but
I bet users will start to want this in most applications once they
realize it's possible.  It will often be useful to let two people
edit the same document, for example.  Viaweb let multiple users
edit a site simultaneously, more because that was the right way to
write the software than because we expected users to want to, but
it turned out that many did.
When you use a Web-based application, your data will be safer.
Disk crashes won't be a thing of the past, but users won't hear
about them anymore.  They'll happen within server farms.  And
companies offering Web-based applications will actually do backups--
not only because they'll have real system administrators worrying
about such things, but because an ASP that does lose people's data
will be in big, big trouble.  When people lose their own data in
a disk crash, they can't get that mad, because they only have
themselves to be mad at.  When a company loses their data for them,
they'll get a lot madder.
Finally, Web-based software should be less vulnerable to viruses.
If the client doesn't run anything except a browser, there's less
chance of running viruses, and no data locally to damage.  And a
program that attacked the servers themselves should find them very
well defended. [2]
For users, Web-based software will be
less stressful.
I think if
you looked inside the average Windows user you'd find a huge and
pretty much untapped desire for software meeting that description.
Unleashed, it could be a powerful force.
City of Code
To developers, the most conspicuous difference between Web-based
and desktop software is that a Web-based application is not a single
piece of code.  It will be a collection of programs of different
types rather than a single big binary.  And so designing Web-based
software is like desiging a city rather than a building: as well
as buildings you need roads, street signs, utilities, police and
fire departments, and plans for both growth and various kinds of
disasters.
At Viaweb, software included fairly big applications that users
talked to directly, programs that those programs used, programs
that ran constantly in the background looking for problems, programs
that tried to restart things if they broke, programs that ran
occasionally to compile statistics or build indexes for searches,
programs we ran explicitly to garbage-collect resources or to move
or restore data, programs that pretended to be users (to measure
performance or expose bugs), programs for diagnosing network
troubles, programs for doing backups, interfaces to outside services,
software that drove an impressive collection of dials displaying
real-time server statistics (a hit with visitors, but indispensable
for us too), modifications (including bug fixes) to open-source
software, and a great many configuration files and settings.  Trevor
Blackwell wrote a spectacular program for moving stores to new
servers across the country, without shutting them down, after we
were bought by Yahoo. Programs paged us, sent faxes and email to
users, conducted transactions with credit card processors, and
talked to one another through sockets, pipes, http requests, ssh,
udp packets, shared memory, and files.  Some of Viaweb even consisted
of the absence of programs, since one of the keys to Unix security
is not to run unnecessary utilities that people might use to break
into your servers.
It did not end with software.  We spent a lot of time thinking
about server configurations.  We built the servers ourselves, from
components-- partly to save money, and partly to get exactly what
we wanted.  We had to think about whether our upstream ISP had fast
enough connections to all the backbones.  We serially
dated
RAID suppliers.
But hardware is not just something to worry about.  When you control
it you can do more for users.  With a desktop application, you can
specify certain minimum hardware, but you can't add more.  If you
administer the servers, you can in one step enable all your users
to page people, or send faxes, or send commands by phone, or process
credit cards, etc, just by installing the relevant hardware.  We
always looked for new ways to add features with hardware, not just
because it pleased users, but also as a way to distinguish ourselves
from competitors who (either because they sold desktop software,
or resold Web-based applications through ISPs) didn't have direct
control over the hardware.
Because the software in a Web-based application will be a collection
of programs rather than a single binary, it can be written in any
number of different languages.  When you're writing desktop software,
you're practically forced to write the application in the same
language as the underlying operating system-- meaning C and C++.
And so these languages (especially among nontechnical people like
managers and VCs) got to be considered as the languages for "serious"
software development.  But that was just an artifact of the way
desktop software had to be delivered.  For server-based software
you can use any language you want. [3]  Today a lot of the top
hackers are using languages far removed from C and C++:  Perl,
Python, and even Lisp.
With server-based software, no one can tell you what language to
use, because you control the whole system, right down to the
hardware.  Different languages are good for different tasks.  You
can use whichever is best for each.  And when you have competitors,
"you can" means "you must" (we'll return to this later), because
if you don't take advantage of this possibility, your competitors
will.
Most of our competitors used C and C++, and this made their software
visibly inferior because (among other things), they had no way
around the statelessness of CGI scripts.  If you were going to
change something, all the changes had to happen on one page, with
an Update button at the bottom.  As I've written elsewhere, by
using
Lisp
, which many people still consider
a research language,
we could make the Viaweb editor behave more like desktop software.
Releases
One of the most important changes in this new world is the way you
do releases. In the desktop software business, doing a release is
a huge trauma, in which the whole company sweats and strains to
push out a single, giant piece of code.  Obvious comparisons suggest
themselves, both to the process and the resulting product.
With server-based software, you can make changes almost as you
would in a program you were writing for yourself.  You release
software as a series of incremental changes instead of an occasional
big explosion. A typical desktop software company might do one or
two releases a year.  At Viaweb we often did three to five releases
a day.
When you switch to this new model, you realize how much software
development is affected by the way it is released.  Many of the
nastiest problems you see in the desktop software business are due
to catastrophic nature of releases.
When you release only one new version a year, you tend to deal with
bugs wholesale.  Some time before the release date you assemble a
new version in which half the code has been torn out and replaced,
introducing countless bugs.  Then a squad of QA people step in and
start counting them, and the programmers work down the list, fixing
them.  They do not generally get to the end of the list, and indeed,
no one is sure where the end is.  It's like fishing rubble out of
a pond.  You never really know what's happening inside the software.
At best you end up with a statistical sort of correctness.
With server-based software, most of the change is small and
incremental.  That in itself is less likely to introduce bugs.  It
also means you know what to test most carefully when you're about
to release software: the last thing you changed.  You end up with
a much firmer grip on the code.  As a general rule, you do know
what's happening inside it.  You don't have the source code memorized,
of course, but when you read the source you do it like a pilot
scanning the instrument panel, not like a detective trying to
unravel some mystery.
Desktop software breeds a certain fatalism about bugs.  You know
that you're shipping something loaded with bugs, and you've even
set up mechanisms to compensate for it (e.g. patch releases).  So
why worry about a few more?  Soon you're releasing whole features
you know are broken.
Apple
did this earlier this year.  They felt
under pressure to release their new OS, whose release date had
already slipped four times, but some of the software (support for
CDs and DVDs) wasn't ready. The solution?  They released the OS
without the unfinished parts, and users will have to install them
later.
With Web-based software, you never have to release software before
it works, and you can release it as soon as it does work.
The industry veteran may be thinking, it's a fine-sounding idea to
say that you never have to release software before it works, but
what happens when you've promised to deliver a new version of your
software by a certain date?  With Web-based software, you wouldn't
make such a promise, because there are no versions.  Your software
changes gradually and continuously.  Some changes might be bigger
than others, but the idea of versions just doesn't naturally fit
onto Web-based software.
If anyone remembers Viaweb this might sound odd, because we were
always announcing new versions.  This was done entirely for PR
purposes.  The trade press, we learned, thinks in version numbers.
They will give you major coverage for a major release, meaning a
new first digit on the version number, and generally a paragraph
at most for a point release, meaning a new digit after the decimal
point.
Some of our competitors were offering desktop software and actually
had version numbers.  And for these releases, the mere fact of
which seemed to us evidence of their backwardness, they would get
all kinds of publicity.  We didn't want to miss out, so we started
giving version numbers to our software too.  When we wanted some
publicity, we'd make a list of all the features we'd added since
the last "release," stick a new version number on the software,
and issue a press release saying that the new version was available
immediately.  Amazingly, no one ever called us on it.
By the time we were bought, we had done this three times, so we
were on Version 4.  Version 4.1 if I remember correctly.  After
Viaweb became Yahoo Store, there was no longer such a desperate
need for publicity, so although the software continued to evolve,
the whole idea of version numbers was quietly dropped.
Bugs
The other major technical advantage of Web-based software is that
you can reproduce most bugs.  You have the users' data right there
on your disk.  If someone breaks your software, you don't have to
try to guess what's going on, as you would with desktop software:
you should be able to reproduce the error while they're on the
phone with you.  You might even know about it already, if you have
code for noticing errors built into your application.
Web-based software gets used round the clock, so everything you do
is immediately put through the wringer.  Bugs turn up quickly.
Software companies are sometimes accused of letting the users debug
their software.  And that is just what I'm advocating.  For Web-based
software it's actually a good plan, because the bugs are fewer and
transient.  When you release software gradually you get far fewer
bugs to start with.  And when you can reproduce errors and release
changes instantly, you can find and fix most bugs as soon as they
appear.  We never had enough bugs at any one time to bother with
a formal bug-tracking system.
You should test changes before you release them, of course, so no
major bugs should get released.  Those few that inevitably slip
through will involve borderline cases and will only affect the few
users that encounter them before someone calls in to complain.  As
long as you fix bugs right away, the net effect, for the average
user, is far fewer bugs.  I doubt the average Viaweb user ever saw
a bug.
Fixing fresh bugs is easier than fixing old ones.  It's usually
fairly quick to find a bug in code you just wrote.  When it turns
up you often know what's wrong before you even look at the source,
because you were already worrying about it subconsciously. Fixing
a bug in something you wrote six months ago (the average case if
you release once a year) is a lot more work.  And since you don't
understand the code as well, you're more likely to fix it in an
ugly way, or even introduce more bugs. [4]
When you catch bugs early, you also get fewer compound bugs.
Compound bugs are two separate bugs that interact:  you trip going
downstairs, and when you reach for the handrail it comes off in
your hand.  In software this kind of bug is the hardest to find,
and also tends to have the worst consequences. [5]  The traditional
"break everything and then filter out the bugs" approach inherently
yields a lot of compound bugs.  And software that's released in a
series of small changes inherently tends not to. The floors are
constantly being swept clean of any loose objects that might later
get stuck in something.
It helps if you use a technique called functional programming.
Functional programming means avoiding side-effects.  It's something
you're more likely to see in research papers than commercial
software, but for Web-based applications it turns out to be really
useful.  It's hard to write entire programs as purely functional
code, but you can write substantial chunks this way.  It makes
those parts of your software easier to test, because they have no
state, and that is very convenient in a situation where you are
constantly making and testing small modifications.  I wrote much
of Viaweb's editor in this style, and we made our scripting language,
RTML
,
a purely functional language.
People from the desktop software business will find this hard to
credit, but at Viaweb bugs became almost a game.  Since most released
bugs involved borderline cases, the users who encountered them were
likely to be advanced users, pushing the envelope.  Advanced users
are more forgiving about bugs, especially since you probably
introduced them in the course of adding some feature they were
asking for.  In fact, because bugs were rare and you had to be
doing sophisticated things to see them, advanced users were often
proud to catch one.  They would call support in a spirit more of
triumph than anger, as if they had scored points off us.
Support
When you can reproduce errors, it changes your approach to customer
support.  At most software companies, support is offered as a way
to make customers feel better.  They're either calling you about
a known bug, or they're just doing something wrong and you have to
figure out what.  In either case there's not much you can learn
from them.  And so you tend to view support calls as a pain in the
ass that you want to isolate from your developers as much as
possible.
This was not how things worked at Viaweb.  At Viaweb, support was
free, because we wanted to hear from customers.  If someone had a
problem, we wanted to know about it right away so that we could
reproduce the error and release a fix.
So at Viaweb the developers were always in close contact with
support.  The customer support people were about thirty feet away
from the programmers, and knew that they could always interrupt
anything with a report of a genuine bug.  We would leave a board
meeting to fix a serious bug.
Our approach to support made everyone happier.  The customers were
delighted.  Just imagine how it would feel to call a support line
and be treated as someone bringing important news.  The customer
support people liked it because it meant they could help the users,
instead of reading scripts to them.  And the programmers liked it
because they could reproduce bugs instead of just hearing vague
second-hand reports about them.
Our policy of fixing bugs on the fly changed the relationship
between customer support people and hackers.  At most software
companies, support people are underpaid human shields, and hackers
are little copies of God the Father, creators of the world.  Whatever
the procedure for reporting bugs, it is likely to be one-directional:
support people who hear about bugs fill out some form that eventually
gets passed on (possibly via QA) to programmers, who put it on
their list of things to do.  It was very different at Viaweb.
Within a minute of hearing about a bug from a customer, the support
people could be standing next to a programmer hearing him say "Shit,
you're right, it's a bug." It delighted the support people to hear
that "you're right" from the hackers.  They used to bring us bugs
with the same expectant air as a cat bringing you a mouse it has
just killed.   It also made them more careful in judging the
seriousness of a bug, because now their honor was on the line.
After we were bought by Yahoo, the customer support people were
moved far away from the programmers.  It was only then that we
realized that they were effectively QA and to some extent marketing
as well.  In addition to catching bugs, they were the keepers of
the knowledge of vaguer, buglike things, like features that confused
users. [6]  They were also a kind of proxy focus group; we could
ask them which of two new features users wanted more, and they were
always right.
Morale
Being able to release software immediately is a big motivator.
Often as I was walking to work I would think of some change I wanted
to make to the software, and do it that day.  This worked for bigger
features as well.  Even if something was going to take two weeks
to write (few projects took longer), I knew I could see the effect
in the software as soon as it was done.
If I'd had to wait a year for the next release, I would have shelved
most of these ideas, for a while at least.  The thing about ideas,
though, is that they lead to more ideas.  Have you ever noticed
that when you sit down to write something, half the ideas that end
up in it are ones you thought of while writing it?  The same thing
happens with software.  Working to implement one idea gives you
more ideas.  So shelving an idea costs you not only that delay in
implementing it, but also all the ideas that implementing it would
have led to.  In fact, shelving an idea probably even inhibits new
ideas: as you start to think of some new feature, you catch sight
of the shelf and think "but I already have a lot of new things I
want to do for the next release."
What big companies do instead of implementing features is plan
them.  At Viaweb we sometimes ran into trouble on this account.
Investors and analysts would ask us what we had planned for the
future.  The truthful answer would have been, we didn't have any
plans.  We had general ideas about things we wanted to improve,
but if we knew how we would have done it already.  What were we
going to do in the next six months? Whatever looked like the biggest
win.  I don't know if I ever dared give this answer, but that was
the truth.  Plans are just another word for ideas on the shelf.
When we thought of good ideas, we implemented them.
At Viaweb, as at many software companies, most code had one definite
owner.  But when you owned something you really owned it: no one
except the owner of a piece of software had to approve (or even
know about) a release.  There was no protection against breakage
except the fear of looking like an idiot to one's peers, and that
was more than enough.  I may have given the impression that we just
blithely plowed forward writing code.  We did go fast, but we
thought very carefully before we released software onto those
servers.  And paying attention is more important to reliability
than moving slowly.  Because he pays close attention, a Navy pilot
can land a 40,000 lb. aircraft at 140 miles per hour on a pitching
carrier deck, at night, more safely than the average teenager can
cut a bagel.
This way of writing software is a double-edged sword of course.
It works a lot better for a small team of good, trusted programmers
than it would for a big company of mediocre ones, where bad ideas
are caught by committees instead of the people that had them.
Brooks in Reverse
Fortunately, Web-based software does require fewer programmers.
I once worked for a medium-sized desktop software company that had
over 100 people working in engineering as a whole.  Only 13 of
these were in product development.  All the rest were working on
releases, ports, and so on.  With Web-based software, all you need
(at most) are the 13 people, because there are no releases, ports,
and so on.
Viaweb was written by just three people. [7]  I was always under
pressure to hire more, because we wanted to get bought, and we knew
that buyers would have a hard time paying a high price for a company
with only three programmers.  (Solution:  we hired more, but created
new projects for them.)
When you can write software with fewer programmers, it saves you
more than money.  As Fred Brooks pointed out in
The Mythical
Man-Month,
adding people to a project tends to slow it down.  The
number of possible connections between developers grows exponentially
with the size of the group.  The larger the group, the more time
they'll spend in meetings negotiating how their software will work
together, and the more bugs they'll get from unforeseen interactions.
Fortunately, this process also works in reverse: as groups get
smaller, software development gets exponentially more efficient.
I can't remember the programmers at Viaweb ever having an actual
meeting.  We never had more to say at any one time than we could
say as we were walking to lunch.
If there is a downside here, it is that all the programmers have
to be to some degree system administrators as well.  When you're
hosting software, someone has to be watching the servers, and in
practice the only people who can do this properly are the ones who
wrote the software.  At Viaweb our system had so many components
and changed so frequently that there was no definite border between
software and infrastructure.  Arbitrarily declaring such a border
would have constrained our design choices.  And so although we were
constantly hoping that one day ("in a couple months") everything
would be stable enough that we could hire someone whose job was
just to worry about the servers, it never happened.
I don't think it could be any other way, as long as you're still
actively developing the product.  Web-based software is never going
to be something you write, check in, and go home.  It's a live
thing, running on your servers right now.  A bad bug might not just
crash one user's process; it could crash them all.  If a bug in
your code corrupts some data on disk, you have to fix it.  And so
on.  We found that you don't have to watch the servers every minute
(after the first year or so), but you definitely want to keep an
eye on things you've changed recently.  You don't release code late
at night and then go home.
Watching Users
With server-based software, you're in closer touch with your code.
You can also be in closer touch with your users.  Intuit is famous
for introducing themselves to customers at retail stores and asking
to follow them home.  If you've ever watched someone use your
software for the first time, you know what surprises must have
awaited them.
Software should do what users think it will.  But you can't have
any idea what users will be thinking, believe me, until you watch
them.  And server-based software gives you unprecedented information
about their behavior.  You're not limited to small, artificial
focus groups.  You can see every click made by every user.  You
have to consider carefully what you're going to look at, because
you don't want to violate users' privacy, but even the most general
statistical sampling can be very useful.
When you have the users on your server, you don't have to rely on
benchmarks, for example.  Benchmarks are simulated users.  With
server-based software, you can watch actual users.  To decide what
to optimize, just log into a server and see what's consuming all
the CPU.  And you know when to stop optimizing too: we eventually
got the Viaweb editor to the point where it was memory-bound rather
than CPU-bound, and since there was nothing we could do to decrease
the size of users' data (well, nothing easy), we knew we might as
well stop there.
Efficiency matters for server-based software, because you're paying
for the hardware.  The number of users you can support per server
is the divisor of your capital cost, so if you can make your software
very efficient you can undersell competitors and still make a
profit.  At Viaweb we got the capital cost per user down to about
$5.  It would be less now, probably less than the cost of sending
them the first month's bill.  Hardware is free now, if your software
is reasonably efficient.
Watching users can guide you in design as well as optimization.
Viaweb had a scripting language called RTML that let advanced users
define their own page styles.  We found that RTML became a kind of
suggestion box, because users only used it when the predefined page
styles couldn't do what they wanted.  Originally the editor put
button bars across the page, for example, but after a number of
users used RTML to put buttons down the left
side
,
we made that an
option (in fact the default) in the predefined page styles.
Finally, by watching users you can often tell when they're in
trouble.  And since the customer is always right, that's a sign of
something you need to fix.  At Viaweb the key to getting users was
the online test drive.  It was not just a series of slides built
by marketing people.  In our test drive, users actually used the
software.  It took about five minutes, and at the end of it they
had built a real, working store.
The test drive was the way we got nearly all our new users.  I
think it will be the same for most Web-based applications.   If
users can get through a test drive successfully, they'll like the
product.  If they get confused or bored, they won't.  So anything
we could do to get more people through the test drive would increase
our growth rate.
I studied click trails of people taking the test drive and found
that at a certain step they would get confused and click on the
browser's Back button.  (If you try writing Web-based applications,
you'll find that the Back button becomes one of your most interesting
philosophical problems.) So I added a message at that point, telling
users that they were nearly finished, and reminding them not to
click on the Back button.  Another great thing about Web-based
software is that you get instant feedback from changes:  the number
of people completing the test drive rose immediately from 60% to
90%.  And since the number of new users was a function of the number
of completed test drives, our revenue growth increased by 50%, just
from that change.
Money
In the early 1990s I read an article in which someone said that
software was a subscription business.  At first this seemed a very
cynical statement.  But later I realized that it reflects reality:
software development is an ongoing process.  I think it's cleaner
if you openly charge subscription fees, instead of forcing people
to keep buying and installing new versions so that they'll keep
paying you.  And fortunately, subscriptions are the natural way to
bill for Web-based applications.
Hosting applications is an area where companies will play a role
that is not likely to be filled by freeware.  Hosting applications
is a lot of stress, and has real expenses.  No one is going to want
to do it for free.
For companies, Web-based applications are an ideal source of revenue.
Instead of starting each quarter with a blank slate, you have a
recurring revenue stream.  Because your software evolves gradually,
you don't have to worry that a new model will flop; there never
need be a new model, per se, and if you do something to the software
that users hate, you'll know right away.  You have no trouble with
uncollectable bills; if someone won't pay you can just turn off
the service.  And there is no possibility of piracy.
That last "advantage" may turn out to be a problem.  Some amount
of piracy is to the advantage of software companies.  If some user
really would not have bought your software at any price, you haven't
lost anything if he uses a pirated copy.  In fact you gain, because
he is one more user helping to make your software the standard--
or who might buy a copy later, when he graduates from high school.
When they can, companies like to do something called price
discrimination, which means charging each customer as much as they
can afford. [8] Software is particularly suitable for price
discrimination, because the marginal cost is close to zero.  This
is why some software costs more to run on Suns than on Intel boxes:
a company that uses Suns is not interested in saving money and can
safely be charged more.  Piracy is effectively the lowest tier of
price discrimination.  I think that software companies understand
this and deliberately turn a blind eye to some kinds of piracy. [9]
With server-based software they are going to have to come up with
some other solution.
Web-based software sells well, especially in comparison to desktop
software, because it's easy to buy.  You might think that people
decide to buy something, and then buy it, as two separate steps.
That's what I thought before Viaweb, to the extent I thought about
the question at all.  In fact the second step can propagate back
into the first: if something is hard to buy, people will change
their mind about whether they wanted it.  And vice versa: you'll
sell more of something when it's easy to buy.  I buy more books
because Amazon exists.  Web-based software is just about the easiest
thing in the world to buy, especially if you have just done an
online demo.  Users should not have to do much more than enter a
credit card number.  (Make them do more at your peril.)
Sometimes Web-based software is offered through ISPs acting as
resellers.  This is a bad idea.  You have to be administering the
servers, because you need to be constantly improving both hardware
and software.  If you give up direct control of the servers, you
give up most of the advantages of developing Web-based applications.
Several of our competitors shot themselves in the foot this way--
usually, I think, because they were overrun by suits who were
excited about this huge potential channel, and didn't realize that
it would ruin the product they hoped to sell through it.  Selling
Web-based software through ISPs is like selling sushi through
vending machines.
Customers
Who will the customers be?  At Viaweb they were initially individuals
and smaller companies, and I think this will be the rule with
Web-based applications.  These are the users who are ready to try
new things, partly because they're more flexible, and partly because
they want the lower costs of new technology.
Web-based applications will often be the best thing for big companies
too (though they'll be slow to realize it).  The best intranet is
the Internet.  If a company uses true Web-based applications, the
software will work better, the servers will be better administered,
and employees will have access to the system from anywhere.
The argument against this approach usually hinges on security: if
access is easier for employees, it will be for bad guys too.  Some
larger merchants were reluctant to use Viaweb because they thought
customers' credit card information would be safer on their own
servers.  It was not easy to make this point diplomatically, but
in fact the data was almost certainly safer in our hands than
theirs.  Who can hire better people to manage security, a technology
startup whose whole business is running servers, or a clothing
retailer?  Not only did we have better people worrying about
security, we worried more about it.  If someone broke into the
clothing retailer's servers, it would affect at most one merchant,
could probably be hushed up, and in the worst case might get one
person fired.  If someone broke into ours, it could affect thousands
of merchants, would probably end up as news on CNet, and could put
us out of business.
If you want to keep your money safe, do you keep it under your
mattress at home, or put it in a bank? This argument applies to
every aspect of server administration:  not just security, but
uptime, bandwidth, load management, backups, etc.  Our existence
depended on doing these things right.  Server problems were the
big no-no for us, like a dangerous toy would be for a toy maker,
or a salmonella outbreak for a food processor.
A big company that uses Web-based applications is to that extent
outsourcing IT.  Drastic as it sounds, I think this is generally
a good idea.  Companies are likely to get better service this way
than they would from in-house system administrators.  System
administrators can become cranky and unresponsive because they're
not directly exposed to competitive pressure:  a salesman has to
deal with customers, and a developer has to deal with competitors'
software, but a system administrator, like an old bachelor, has
few external forces to keep him in line. [10]  At Viaweb we had
external forces in plenty to keep us in line. The people calling
us were customers, not just co-workers.  If a server got wedged,
we jumped; just thinking about it gives me a jolt of adrenaline,
years later.
So Web-based applications will ordinarily be the right answer for
big companies too.  They will be the last to realize it, however,
just as they were with desktop computers.  And partly for the same
reason: it will be worth a lot of money to convince big companies
that they need something more expensive.
There is always a tendency for rich customers to buy expensive
solutions, even when cheap solutions are better, because the people
offering expensive solutions can spend more to sell them.  At Viaweb
we were always up against this.  We lost several high-end merchants
to Web consulting firms who convinced them they'd be better off if
they paid half a million dollars for a custom-made online store on
their own server.  They were, as a rule, not better off, as more
than one discovered when Christmas shopping season came around and
loads rose on their server.  Viaweb was a lot more sophisticated
than what most of these merchants got, but we couldn't afford to
tell them.  At $300 a month, we couldn't afford to send a team of
well-dressed and authoritative-sounding people to make presentations
to customers.
A large part of what big companies pay extra for is the cost of
selling expensive things to them.  (If the Defense Department pays
a thousand dollars for toilet seats, it's partly because it costs
a lot to sell toilet seats for a thousand dollars.)  And this is
one reason intranet software will continue to thrive, even though
it is probably a bad idea.  It's simply more expensive.  There is
nothing you can do about this conundrum, so the best plan is to go
for the smaller customers first.  The rest will come in time.
Son of Server
Running software on the server is nothing new.  In fact it's the
old model: mainframe applications are all server-based.  If
server-based software is such a good idea, why did it lose last
time?  Why did desktop computers eclipse mainframes?
At first desktop computers didn't look like much of a threat.  The
first users were all hackers-- or hobbyists, as they were called
then.  They liked microcomputers because they were cheap.  For the
first time, you could have your own computer.  The phrase "personal
computer" is part of the language now, but when it was first used
it had a deliberately audacious sound, like the phrase "personal
satellite" would today.
Why did desktop computers take over? I think it was because they
had better software.  And I think the reason microcomputer software
was better was that it could be written by small companies.
I don't think many people realize how fragile and tentative startups
are in the earliest stage.  Many startups begin almost by accident--
as a couple guys, either with day jobs or in school, writing a
prototype of something that might, if it looks promising, turn into
a company. At this larval stage, any significant obstacle will stop
the startup dead in its tracks.  Writing mainframe software required
too much commitment up front.  Development machines were expensive,
and because the customers would be big companies, you'd need an
impressive-looking sales force to sell it to them.  Starting a
startup to write mainframe software would be a much more serious
undertaking than just hacking something together on your Apple II
in the evenings.  And so you didn't get a lot of startups writing
mainframe applications.
The arrival of desktop computers inspired a lot of new software,
because writing applications for them seemed an attainable goal to
larval startups.  Development was cheap, and the customers would
be individual people that you could reach through computer stores
or even by mail-order.
The application that pushed desktop computers out into the mainstream
was
VisiCalc
, the
first spreadsheet.  It was written by two guys
working in an attic, and yet did things no mainframe software could
do. [11]  VisiCalc was such an advance, in its time, that people
bought Apple IIs just to run it.  And this was the beginning of a
trend: desktop computers won because startups wrote software for
them.
It looks as if server-based software will be good this time around,
because startups will write it.  Computers are so cheap now that
you can get started, as we did, using a desktop computer as a
server.  Inexpensive processors have eaten the workstation market
(you rarely even hear the word now) and are most of the way through
the server market; Yahoo's servers, which deal with loads as high
as any on the Internet, all have the same inexpensive Intel processors
that you have in your desktop machine.  And once you've written
the software, all you need to sell it is a Web site.  Nearly all
our users came direct to our site through word of mouth and references
in the press. [12]
Viaweb was a typical larval startup.  We were terrified of starting
a company, and for the first few months comforted ourselves by
treating the whole thing as an experiment that we might call off
at any moment.  Fortunately, there were few obstacles except
technical ones.  While we were writing the software, our Web server
was the same desktop machine we used for development, connected to
the outside world by a dialup line.  Our only expenses in that
phase were food and rent.
There is all the more reason for startups to write Web-based software
now, because writing desktop software has become a lot less fun.
If you want to write desktop software now you do it on Microsoft's
terms, calling their APIs and working around their buggy OS.  And
if you manage to write something that takes off, you may find that
you were merely doing market research for Microsoft.
If a company wants to make a platform that startups will build on,
they have to make it something that hackers themselves will want
to use.   That means it has to be inexpensive and well-designed.
The Mac was popular with hackers when it first came out, and a lot
of them wrote software for it. [13] You see this less with Windows,
because hackers don't use it.  The kind of people who are good at
writing software tend to be running Linux or FreeBSD now.
I don't think we would have started a startup to write desktop
software, because desktop software has to run on Windows, and before
we could write software for Windows we'd have to use it.  The Web
let us do an end-run around Windows, and deliver software running
on Unix direct to users through the browser.  That is a liberating
prospect, a lot like the arrival of PCs twenty-five years ago.
Microsoft
Back when desktop computers arrived, IBM was the giant that everyone
was afraid of.  It's hard to imagine now, but I remember the feeling
very well.  Now the frightening giant is Microsoft, and I don't
think they are as blind to the threat facing them as IBM was.
After all, Microsoft deliberately built their business in IBM's
blind spot.
I mentioned earlier that my mother doesn't really need a desktop
computer.  Most users probably don't.  That's a problem for Microsoft,
and they know it.  If applications run on remote servers, no one
needs Windows.  What will Microsoft do?  Will they be able to use
their control of the desktop to prevent, or constrain, this new
generation of software?
My guess is that Microsoft will develop some kind of server/desktop
hybrid, where the operating system works together with servers they
control.  At a minimum, files will be centrally available for users
who want that.  I don't expect Microsoft to go all the way to the
extreme of doing the computations on the server, with only a browser
for a client, if they can avoid it. If you only need a browser for
a client, you don't need Microsoft on the client, and if Microsoft
doesn't control the client, they can't push users towards their
server-based applications.
I think Microsoft will have a hard time keeping the genie in the
bottle.  There will be too many different types of clients for them
to control them all.  And if Microsoft's applications only work
with some clients, competitors will be able to trump them by offering
applications that work from any client. [14]
In a world of Web-based applications, there is no automatic place
for Microsoft.  They may succeed in making themselves a place, but
I don't think they'll dominate this new world as they did the world
of desktop applications.
It's not so much that a competitor will trip them up as that they
will trip over themselves.  With the rise of Web-based software,
they will be facing not just technical problems but their own
wishful thinking.  What they need to do is cannibalize their existing
business, and I can't see them facing that.  The same single-mindedness
that has brought them this far will now be working against them.
IBM was in exactly the same situation, and they could not master
it.  IBM made a late and half-hearted entry into the microcomputer
business because they were ambivalent about threatening their cash
cow, mainframe computing.  Microsoft will likewise be hampered by
wanting to save the desktop.  A cash cow can be a damned heavy
monkey on your back.
I'm not saying that no one will dominate server-based applications.
Someone probably will eventually.  But I think that there will be
a good long period of cheerful chaos, just as there was in the
early days of microcomputers.  That was a good time for startups.
Lots of small companies flourished, and did it by making cool
things.
Startups but More So
The classic startup is fast and informal, with few people and little
money.  Those few people work very hard, and technology magnifies
the effect of the decisions they make.  If they win, they win big.
In a startup writing Web-based applications, everything you associate
with startups is taken to an extreme.  You can write and launch a
product with even fewer people and even less money.  You have to
be even faster, and you can get away with being more informal.
You can literally launch your product as three guys sitting in the
living room of an apartment, and a server collocated at an ISP.
We did.
Over time the teams have gotten smaller, faster, and more informal.
In 1960, software development meant a roomful of men with horn
rimmed glasses and narrow black neckties, industriously writing
ten lines of code a day on IBM coding forms.  In 1980, it was a
team of eight to ten people wearing jeans to the office and typing
into vt100s.  Now it's a couple of guys sitting in a living room
with laptops.  (And jeans turn out not to be the last word in
informality.)
Startups are stressful, and this, unfortunately, is also taken to
an extreme with Web-based applications.
Many software companies, especially at the beginning, have periods
where the developers slept under their desks and so on.  The alarming
thing about Web-based software is that there is nothing to prevent
this becoming the default.  The stories about sleeping under desks
usually end:  then at last we shipped it and we all went home and
slept for a week.  Web-based software never ships.  You can work
16-hour days for as long as you want to.  And because you can, and
your competitors can, you tend to be forced to.  You can, so you
must.  It's Parkinson's Law running in reverse.
The worst thing is not the hours but the responsibility.  Programmers
and system administrators traditionally each have their own separate
worries.  Programmers have to worry about bugs, and system
administrators have to worry about infrastructure.  Programmers
may spend a long day up to their elbows in source code, but at some
point they get to go home and forget about it.  System administrators
never quite leave the job behind, but when they do get paged at
4:00 AM, they don't usually have to do anything very complicated.
With Web-based applications, these two kinds of stress get combined.
The programmers become system administrators, but without the
sharply defined limits that ordinarily make the job bearable.
At Viaweb we spent the first six months just writing software.  We
worked the usual long hours of an early startup.  In a desktop
software company, this would have been the part where we were
working hard, but it felt like a vacation compared to the next
phase, when we took users onto our server.  The second biggest
benefit of selling Viaweb to Yahoo (after the money) was to be able
to dump ultimate responsibility for the whole thing onto the
shoulders of a big company.
Desktop software forces users to become system administrators.
Web-based software forces programmers to.  There is less stress in
total, but more for the programmers.  That's not necessarily bad
news.  If you're a startup competing with a big company, it's good
news. [15]  Web-based applications offer a straightforward way to
outwork your competitors.  No startup asks for more.
Just Good Enough
One thing that might deter you from writing Web-based applications
is the lameness of Web pages as a UI.  That is a problem, I admit.
There were a few things we would have
really
liked to add to
HTML and HTTP.  What matters, though, is that Web pages are just
good enough.
There is a parallel here with the first microcomputers.  The
processors in those machines weren't actually intended to be the
CPUs of computers.  They were designed to be used in things like
traffic lights.  But guys like Ed Roberts, who designed the
Altair
,
realized that they were just good enough.  You could combine one
of these chips with some memory (256 bytes in the first Altair),
and front panel switches, and you'd have a working computer.  Being
able to have your own computer was so exciting that there were
plenty of people who wanted to buy them, however limited.
Web pages weren't designed to be a UI for applications, but they're
just good enough.  And for a significant number of users, software
that you can use from any browser will be enough of a win in itself
to outweigh any awkwardness in the UI.  Maybe you can't write the
best-looking spreadsheet using HTML, but you can write a spreadsheet
that several people can use simultaneously from different locations
without special client software, or that can incorporate live data
feeds, or that can page you when certain conditions are triggered.
More importantly, you can write new kinds of applications that
don't even have names yet.  VisiCalc was not merely a microcomputer
version of a mainframe application, after all-- it was a new type
of application.
Of course, server-based applications don't have to be Web-based.
You could have some other kind of client.  But I'm pretty sure
that's a bad idea.  It would be very convenient if you could assume
that everyone would install your client-- so convenient that you
could easily convince yourself that they all would-- but if they
don't, you're hosed.  Because Web-based software assumes nothing
about the client, it will work anywhere the Web works.  That's a
big advantage already, and the advantage will grow as new Web
devices proliferate.  Users will like you because your software
just works, and your life will be easier because you won't have to
tweak it for every new client.
[16]
I feel like I've watched the evolution of the Web as closely as
anyone, and I can't predict what's going to happen with clients.
Convergence is probably coming, but where?  I can't pick a winner.
One thing I can predict is conflict between AOL and Microsoft.
Whatever Microsoft's .NET turns out to be, it will probably involve
connecting the desktop to servers.  Unless AOL fights back, they
will either be pushed aside or turned into a pipe between Microsoft
client and server software.  If Microsoft and AOL get into a client
war, the only thing sure to work on both will be browsing the Web,
meaning Web-based applications will be the only kind that work
everywhere.
How will it all play out?  I don't know.  And you don't have to
know if you bet on Web-based applications.  No one can break that
without breaking browsing.  The Web may not be the only way to
deliver software, but it's one that works now and will continue to
work for a long time.  Web-based applications are cheap to develop,
and easy for even the smallest startup to deliver.  They're a lot
of work, and of a particularly stressful kind, but that only makes
the odds better for startups.
Why Not?
E. B. White was amused to learn from a farmer friend that many
electrified fences don't have any current running through them.
The cows apparently learn to stay away from them, and after that
you don't need the current.  "Rise up, cows!" he wrote, "Take your
liberty while despots snore!"
If you're a hacker who has thought of one day starting a startup,
there are probably two things keeping you from doing it.  One is
that you don't know anything about business.  The other is that
you're afraid of competition.  Neither of these fences have any
current in them.
There are only two things you have to know about business:  build
something users love, and make more than you spend.  If you get
these two right, you'll be ahead of most startups.  You can figure
out the rest as you go.
You may not at first make more than you spend, but as long as the
gap is closing fast enough you'll be ok.  If you start out underfunded,
it will at least encourage a habit of frugality.  The less you
spend, the easier it is to make more than you spend.  Fortunately,
it can be very cheap to launch a Web-based application.  We launched
on under $10,000, and it would be even cheaper today.  We had to
spend thousands on a server, and thousands more to get SSL.  (The
only company selling SSL software at the time was Netscape.)  Now
you can rent a much more powerful server, with SSL included, for
less than we paid for bandwidth alone.  You could launch a Web-based
application now for less than the cost of a fancy office chair.
As for building something users love, here are some general tips.
Start by making something clean and simple that you would want to
use yourself.  Get a version 1.0 out fast, then continue to improve
the software, listening closely to the users as you do.  The customer
is always right, but different customers are right about different
things; the least sophisticated users show you what you need to
simplify and clarify, and the most sophisticated tell you what
features you need to add. The best thing software can be is easy,
but the way to do this is to get the defaults right, not to limit
users' choices.  Don't get complacent if your competitors' software
is lame; the standard to compare your software to is what it could
be, not what your current competitors happen to have.  Use your
software yourself, all the time.  Viaweb was supposed to be an
online store builder, but we used it to make our own site too.
Don't listen to marketing people or designers or product managers
just because of their job titles.  If they have good ideas, use
them, but it's up to you to decide; software has to be designed by
hackers who understand design, not designers who know a little
about software.  If you can't design software as well as implement
it, don't start a startup.
Now let's talk about competition.  What you're afraid of is not
presumably groups of hackers like you, but actual companies, with
offices and business plans and salesmen and so on, right?  Well,
they are more afraid of you than you are of them, and they're right.
It's a lot easier for a couple of hackers to figure out how to rent
office space or hire sales people than it is for a company of any
size to get software written.  I've been on both sides, and I know.
When Viaweb was bought by Yahoo, I suddenly found myself working
for a big company, and it was like trying to run through waist-deep
water.
I don't mean to disparage Yahoo.  They had some good hackers, and
the top management were real butt-kickers.  For a big company, they
were exceptional.  But they were still only about a tenth as
productive as a small startup.  No big company can do much better
than that.  What's scary about Microsoft is that a company so
big can develop software at all.  They're like a mountain that
can walk.
Don't be intimidated.  You can do as much that Microsoft can't as
they can do that you can't.  And no one can stop you.  You don't
have to ask anyone's permission to develop Web-based applications.
You don't have to do licensing deals, or get shelf space in retail
stores, or grovel to have your application bundled with the OS.
You can deliver software right to the browser, and no one can get
between you and potential users without preventing them from browsing
the Web.
You may not believe it, but I promise you, Microsoft is scared of
you.  The complacent middle managers may not be, but Bill is,
because he was you once, back in 1975, the last time a new way of
delivering software appeared.
Notes
[1] Realizing that much of the money is in the services, companies
building lightweight clients have usually tried to combine the
hardware with an
online service
.
 This approach has not worked
well, partly because you need two different kinds of companies to
build consumer electronics and to run an online service, and partly
because users hate the idea.  Giving away the razor and making
money on the blades may work for Gillette, but a razor is much
smaller commitment than a Web terminal.  Cell phone handset makers
are satisfied to sell hardware without trying to capture the service
revenue as well.  That should probably be the model for Internet
clients too.  If someone just sold a nice-looking little box with
a Web browser that you could use to connect through any ISP, every
technophobe in the country would buy one.
[2] Security always depends more on not screwing up than any design
decision, but the nature of server-based software will make developers
pay more attention to not screwing up.  Compromising a server could
cause such damage that ASPs (that want to stay in business) are
likely to be careful about security.
[3] In 1995, when we started Viaweb, Java applets were supposed to
be the technology everyone was going to use to develop server-based
applications.  Applets seemed to us an old-fashioned idea.  Download
programs to run on the client? Simpler just to go all the way and
run the programs on the server.  We wasted little time
on applets, but countless other startups must have been lured into
this tar pit.  Few can have escaped alive, or Microsoft could not
have gotten away with dropping Java in the most recent version of
Explorer.
[4] This point is due to Trevor Blackwell, who adds "the cost of
writing software goes up more than linearly with its size.  Perhaps
this is mainly due to fixing old bugs, and the cost can be more
linear if all bugs are found quickly."
[5] The hardest kind of bug to find may be a variant of compound
bug where one bug happens to compensate for another.  When you fix
one bug, the other becomes visible.  But it will seem as if the
fix is at fault, since that was the last thing you changed.
[6] Within Viaweb we once had a contest to describe the worst thing
about our software.  Two customer support people tied for first
prize with entries I still shiver to recall.  We fixed both problems
immediately.
[7] Robert Morris wrote the ordering system, which shoppers used
to place orders. Trevor Blackwell wrote the image generator and
the manager, which merchants used to retrieve orders, view statistics,
and configure domain names etc.  I wrote the editor, which merchants
used to build their sites.  The ordering system and image generator
were written in C and C++, the manager mostly in Perl, and the editor
in
Lisp
.
[8] Price discrimination is so pervasive (how often have you heard
a retailer claim that their buying power meant lower prices for
you?) that I was surprised to find it was outlawed in the U.S. by
the Robinson-Patman Act of 1936.  This law does not appear to be
vigorously enforced.
[9] In
No Logo,
Naomi Klein says that clothing brands favored by
"urban youth" do not try too hard to prevent shoplifting because
in their target market the shoplifters are also the fashion leaders.
[10] Companies often wonder what to outsource and what not to.
One possible answer: outsource any job that's not directly exposed
to competitive pressure, because outsourcing it will thereby expose
it to competitive pressure.
[11] The two guys were Dan Bricklin and Bob Frankston.  Dan wrote
a prototype in Basic in a couple days, then over the course of the
next year they worked together (mostly at night) to make a more
powerful version written in 6502 machine language.  Dan was at
Harvard Business School at the time and Bob nominally had a day
job writing software.  "There was no great risk in doing a business,"
Bob wrote, "If it failed it failed. No big deal."
[12] It's not quite as easy as I make it sound.  It took a painfully
long time for word of mouth to get going, and we did not start to
get a lot of press coverage until we hired a
PR firm
(admittedly
the best in the business) for $16,000 per month.  However, it was
true that the only significant channel was our own Web site.
[13] If the Mac was so great, why did it lose?  Cost, again.
Microsoft concentrated on the software business, and unleashed a
swarm of cheap component suppliers on Apple hardware.  It did not
help, either, that suits took over during a critical period.
[14] One thing that would help Web-based applications, and help
keep the next generation of software from being overshadowed by
Microsoft, would be a good open-source browser.  Mozilla is
open-source but seems to have suffered from having been corporate
software for so long.  A small, fast browser that was actively
maintained would be a great thing in itself, and would probably
also encourage companies to build little Web appliances.
Among other things, a proper open-source browser would cause HTTP
and HTML to continue to evolve (as e.g. Perl has).  It would help
Web-based applications greatly to be able to distinguish between
selecting a link and following it; all you'd need to do this would
be a trivial enhancement of HTTP, to allow multiple urls in a
request.  Cascading menus would also be good.
If you want to change the world, write a new Mosaic.  Think it's
too late?  In 1998 a lot of people thought it was too late to launch
a new search engine, but Google proved them wrong.  There is always
room for something new if the current options suck enough.  Make
sure it works on all the free OSes first-- new things start with
their users.
[15] Trevor Blackwell, who probably knows more about this from
personal experience than anyone, writes:
"I would go farther in saying that because server-based software
is so hard on the programmers, it causes a fundamental economic
shift away from large companies. It requires the kind of intensity
and dedication from programmers that they will only be willing to
provide when it's their own company.  Software companies can hire
skilled people to work in a not-too-demanding environment, and can
hire unskilled people to endure hardships, but they can't hire
highly skilled people to bust their asses. Since capital is no
longer needed, big companies have little to bring to the table."
[16] In the original version of this essay, I advised avoiding
Javascript.  That was a good plan in 2001, but Javascript now works.
Thanks
to Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson,
and Dan Giffin for reading drafts of this paper; to Dan Bricklin and
Bob Frankston for information about VisiCalc; and again to Ken Anderson
for inviting me to speak at BBN.
You'll find this essay and 14 others in
Hackers & Painters
.
Some Technical Details
Japanese Translation
Microsoft finally agrees
Gates Email


"It has written parts of itself."

— A YC founder on their product

As someone who predicts tech outcomes for a living, I can tell you that, as a class, journalists' insights about tech have the predictive value of a coin flip.

@RaheemKassam They're surely a more trustworthy source than you.

@AndrewStilesUSA You were fooled by a fake.

https://t.co/6xe8oMk90B

@stclairashley No, they didn't. That image is fake.

https://t.co/6xe8oMk90B

@RaheemKassam No, they didn't. That image is fake.

https://t.co/6xe8oMk90B

@TheQuartering That image is fake.

https://t.co/6xe8oMk90B

@CamRoda99Lives The main reason would be if they were sure they only wanted to start a company of moderate size.

@edusncrtc @josephjojoe Sometimes by mistake, and sometimes for jobs they think don't require much intelligence.

@Austen @patrickc @DanielleFong Don't ask me. Read the study.


@holmesworcester The latter.

People just as good are alive now, but we take them for granted because they're contemporaries rather than great historical figures.

@wendyoncaffeine I tried not to, but I was outvoted.

@cperciva You can't judge much by the companies. You have to ask founders they've invested in. Ideally founders whose companies failed, because there are more ethical tests then.

This is a good example of a startup that can both make a lot of money and also make the world better, because these glasses are transformative for the deaf. So if you want to make a lot of money and make the world better, this would be a good job to apply for.

@itnevermatterz Actually I don't know who I'm talking about. A founder emailed me about this problem, but he didn't name the investor.

@LuisAndLearn Do YC. Then you'll have lots of options.

The value of that investor's magic rolodex will decrease exponentially as you work in the industry and grow your own connections. A year from now it will hardly matter. But he'll still be an asshole.

Don't take money from an investor you have moral qualms about because of valuable connections they claim to have. Being upstanding matters more in the long term than connections.

@grok @JohnStark3D2A @oprydai No it isn't. There's one essay in it that compares programmers to artists, and I used its title as the title of the book.


The stupidity of this regulation will be revealed gradually as technology evolves.

Good writing is usually about more than it seems to be. Robert Morris introduced me to this idea when he pointed out that K&R was not just about C but about how to program. Since then I've noticed example after example of this phenomenon.

It may be that the best philosophy books are not books explicitly about philosophy, but books on other topics written by such consummate experts that they can take their field's ideas all the way to the highest levels of abstraction.

Why are there no A380 freighters? Flexport explains. The 747 incidentally is exactly the opposite. Its designers thought it would soon be replaced by supersonic aircraft, and designed it to be easily converted to a freighter. That's why the cockpit is upstairs. https://t.co/tXnFGOi7ip

Every winter Jessica and her friend play tennis against 16 yo and his friend. Yesterday she played the game of her life and just managed to win 7-5, and she is really delighted. This is a pair of large, athletic boys. She only managed to beat them through cleverness.

This graph from @pablogguz_ of Spanish fiscal contributions by age demonstrates an important fact. The 40 and 50 year olds are carrying both their kids and their parents. And not just economically. This is why it's hard to be middle-aged. https://t.co/lMTTSzykP6

It's reassuring to see a Democrat and a Republican working together. I'd rather see that than see either party prevail.

As a Christmas present for those who like black beans, here's the perfect spice mix. (I didn't invent it. It's the recipe of a defunct spice company.)

49.5g sweet paprika, 9g cumin, 7.2g black pepper, 7.2g allspice, 7.2g garlic powder, 4.5g oregano, 3.6g cinnamon, 1.8g cloves.

If you keep acting like a banana republic, eventually you become one. https://t.co/E1ZddhBfLs

Fortunately the dishonest are often stupid as well.