A OUTRA ESTRADA À FRENTE
OriginalSetembro de 2001
(Este artigo explica por que grande parte da próxima geração de software pode ser baseada em servidor, o que isso significará para os programadores e por que esse novo tipo de software é uma grande oportunidade para startups. É derivado de uma palestra no BBN Labs.)
No verão de 1995, meu amigo Robert Morris e eu decidimos começar uma startup. A campanha de relações públicas que antecedeu o IPO da Netscape estava a todo vapor na época, e havia muito talk na imprensa sobre comércio online. Naquele momento, poderia haver trinta lojas reais na Web, todas feitas à mão. Se houvesse muitas lojas online, seria necessário ter software para criá-las, então decidimos escrever um.
Na primeira semana, pretendíamos fazer disso um aplicativo de desktop comum. Então, um dia, tivemos a ideia de fazer o software rodar em nosso servidor Web, usando o navegador como interface. Tentamos reescrever o software para funcionar pela Web, e ficou claro que esse era o caminho a seguir. Se escrevêssemos nosso software para rodar no servidor, seria muito mais fácil para os usuários e para nós também.
Isso se revelou um bom plano. Agora, como Yahoo Store, esse software é o construtor de lojas online mais popular, com cerca de 14.000 usuários.
Quando começamos a Viaweb, quase ninguém entendia o que queríamos dizer quando dizíamos que o software rodava no servidor. Não foi até que o Hotmail foi lançado um ano depois que as pessoas começaram a entender. Agora todos sabem que essa é uma abordagem válida. Agora há um nome para o que éramos: um Provedor de Serviços de Aplicação, ou ASP.
Acho que grande parte da próxima geração de software será escrita nesse modelo. Até a Microsoft, que tem mais a perder, parece ver a inevitabilidade de mover algumas coisas para fora da área de trabalho. Se o software se mover da área de trabalho para os servidores, isso significará um mundo muito diferente para os desenvolvedores. Este artigo descreve as coisas surpreendentes que vimos, como alguns dos primeiros visitantes deste novo mundo. Na medida em que o software se mover para os servidores, o que estou descrevendo aqui é o futuro.
A Próxima Coisa?
Quando olhamos para trás na era do software de desktop, acho que vamos nos maravilhar com os inconvenientes que as pessoas suportavam, assim como nos maravilhamos agora com o que os primeiros proprietários de carros suportavam. Durante os primeiros vinte ou trinta anos, você tinha que ser um especialista em carros para possuir um carro. Mas os carros eram uma grande vitória, então muitas pessoas que não eram especialistas em carros também queriam tê-los.
Os computadores estão nessa fase agora. Quando você possui um computador de desktop, acaba aprendendo muito mais do que gostaria sobre o que está acontecendo dentro dele. Mas mais da metade dos lares nos EUA possui um. Minha mãe tem um computador que usa para e-mail e para manter contas. Cerca de um ano atrás, ela ficou alarmada ao receber uma carta da Apple, oferecendo um desconto em uma nova versão do sistema operacional. Há algo errado quando uma mulher de sessenta e cinco anos que quer usar um computador para e-mail e contas tem que pensar em instalar novos sistemas operacionais. Usuários comuns não deveriam nem saber as palavras "sistema operacional", muito menos "driver de dispositivo" ou "patch".
Agora há outra maneira de entregar software que salvará os usuários de se tornarem administradores de sistema. Aplicativos baseados na Web são programas que rodam em servidores Web e usam páginas da Web como interface do usuário. Para o usuário médio, esse novo tipo de software será mais fácil, mais barato, mais móvel, mais confiável e muitas vezes mais poderoso do que o software de desktop.
Com software baseado na Web, a maioria dos usuários não precisará pensar em nada além dos aplicativos que usam. Todas as coisas bagunçadas e em mudança estarão em um servidor em algum lugar, mantidas pelo tipo de pessoas que são boas nesse tipo de coisa. E assim, você não precisará normalmente de um computador, por si só, para usar o software. Tudo o que você precisará será de algo com um teclado, uma tela e um navegador da Web. Talvez tenha acesso à Internet sem fio. Talvez também seja seu celular. Seja o que for, será eletrônica de consumo: algo que custa cerca de $200, e que as pessoas escolhem principalmente com base em como o case parece. Você pagará mais pelos serviços de Internet do que pelo hardware, assim como faz agora com os telefones. [1]
Levará cerca de um décimo de segundo para um clique chegar ao servidor e voltar, então usuários de software altamente interativo, como o Photoshop, ainda quererão que os cálculos aconteçam na área de trabalho. Mas se você olhar para o tipo de coisas que a maioria das pessoas usa computadores, uma latência de um décimo de segundo não seria um problema. Minha mãe realmente não precisa de um computador de desktop, e há muitas pessoas como ela.
A Vantagem para os Usuários
Perto da minha casa, há um carro com um adesivo que diz "morte antes do inconveniente". A maioria das pessoas, na maior parte do tempo, escolherá a opção que requer menos trabalho. Se o software baseado na Web vencer, será porque é mais conveniente. E parece que será, tanto para usuários quanto para desenvolvedores.
Para usar um aplicativo puramente baseado na Web, tudo o que você precisa é de um navegador conectado à Internet. Assim, você pode usar um aplicativo baseado na Web em qualquer lugar. Quando você instala software em seu computador de desktop, só pode usá-lo naquele computador. Pior ainda, seus arquivos ficam presos naquele computador. O inconveniente desse modelo se torna cada vez mais evidente à medida que as pessoas se acostumam com redes.
A ponta do iceberg aqui foi o e-mail baseado na Web. Milhões de pessoas agora percebem que você deve ter acesso a mensagens de e-mail, não importa onde esteja. E se você pode ver seu e-mail, por que não seu calendário? Se você pode discutir um documento com seus colegas, por que não pode editá-lo? Por que qualquer um dos seus dados deve estar preso em algum computador em uma mesa distante?
Toda a ideia de "seu computador" está desaparecendo, sendo substituída por "seus dados". Você deve ser capaz de acessar seus dados de qualquer computador. Ou melhor, qualquer cliente, e um cliente não precisa ser um computador.
Os clientes não devem armazenar dados; eles devem ser como telefones. Na verdade, eles podem se tornar telefones, ou vice-versa. E à medida que os clientes ficam menores, você tem mais um motivo para não manter seus dados neles: algo que você carrega pode ser perdido ou roubado. Deixar seu PDA em um táxi é como uma falha de disco, exceto que seus dados são entregues a outra pessoa em vez de serem vaporizar.
Com software puramente baseado na Web, nem seus dados nem os aplicativos são mantidos no cliente. Assim, você não precisa instalar nada para usá-lo. E quando não há instalação, você não precisa se preocupar com a instalação dando errado. Não pode haver incompatibilidades entre o aplicativo e seu sistema operacional, porque o software não roda em seu sistema operacional.
Como não precisa de instalação, será fácil e comum experimentar software baseado na Web antes de "comprá-lo". Você deve esperar poder testar qualquer aplicativo baseado na Web gratuitamente, apenas acessando o site onde ele é oferecido. Na Viaweb, nosso site inteiro era como uma grande seta apontando os usuários para o test drive.
Depois de experimentar a demonstração, inscrever-se para o serviço deve exigir nada mais do que preencher um breve formulário (quanto mais breve, melhor). E isso deve ser o último trabalho que o usuário tem que fazer. Com software baseado na Web, você deve receber novas versões sem pagar a mais, ou fazer qualquer trabalho, ou possivelmente até mesmo saber sobre isso.
As atualizações não serão os grandes choques que são agora. Com o tempo, os aplicativos crescerão silenciosamente mais poderosos. Isso exigirá algum esforço por parte dos desenvolvedores. Eles terão que projetar o software para que possa ser atualizado sem confundir os usuários. Esse é um novo problema, mas há maneiras de resolvê-lo.
Com aplicativos baseados na Web, todos usam a mesma versão, e os bugs podem ser corrigidos assim que forem descobertos. Assim, o software baseado na Web deve ter muito menos bugs do que o software de desktop. Na Viaweb, duvido que tivéssemos dez bugs conhecidos em qualquer momento. Isso é ordens de magnitude melhor do que o software de desktop.
Aplicativos baseados na Web podem ser usados por várias pessoas ao mesmo tempo. Essa é uma vitória óbvia para aplicativos colaborativos, mas aposto que os usuários começarão a querer isso na maioria dos aplicativos assim que perceberem que é possível. Muitas vezes será útil permitir que duas pessoas editem o mesmo documento, por exemplo. A Viaweb permitia que vários usuários editassem um site simultaneamente, mais porque essa era a maneira certa de escrever o software do que porque esperávamos que os usuários quisessem, mas acabou que muitos queriam.
Quando você usa um aplicativo baseado na Web, seus dados estarão mais seguros. Falhas de disco não serão coisa do passado, mas os usuários não ouvirão mais sobre elas. Elas acontecerão dentro de fazendas de servidores. E as empresas que oferecem aplicativos baseados na Web realmente farão backups—não apenas porque terão administradores de sistema reais preocupados com essas coisas, mas porque um ASP que perder os dados das pessoas estará em grandes, grandes problemas. Quando as pessoas perdem seus próprios dados em uma falha de disco, elas não podem ficar tão bravas, porque só têm a si mesmas para ficar bravas. Quando uma empresa perde os dados delas, elas ficarão muito mais bravas.
Finalmente, o software baseado na Web deve ser menos vulnerável a vírus. Se o cliente não roda nada além de um navegador, há menos chance de rodar vírus, e nenhum dado local para danificar. E um programa que atacasse os servidores em si deve encontrá-los muito bem defendidos. [2]
Para os usuários, o software baseado na Web será menos estressante. Acho que se você olhasse dentro do usuário médio do Windows, encontraria um enorme e praticamente inexplorado desejo por software que atenda a essa descrição. Liberado, isso poderia ser uma força poderosa.
Cidade de Código
Para os desenvolvedores, a diferença mais conspícua entre software baseado na Web e software de desktop é que um aplicativo baseado na Web não é um único pedaço de código. Ele será uma coleção de programas de diferentes tipos, em vez de um único grande binário. E assim, projetar software baseado na Web é como projetar uma cidade em vez de um edifício: além de edifícios, você precisa de estradas, placas de sinalização, utilidades, departamentos de polícia e bombeiros, e planos para crescimento e vários tipos de desastres.
Na Viaweb, o software incluía aplicativos bastante grandes com os quais os usuários interagiam diretamente, programas que esses programas usavam, programas que rodavam constantemente em segundo plano procurando problemas, programas que tentavam reiniciar as coisas se quebrassem, programas que rodavam ocasionalmente para compilar estatísticas ou construir índices para buscas, programas que executávamos explicitamente para coletar recursos ou mover ou restaurar dados, programas que fingiam ser usuários (para medir desempenho ou expor bugs), programas para diagnosticar problemas de rede, programas para fazer backups, interfaces para serviços externos, software que controlava uma impressionante coleção de mostradores exibindo estatísticas de servidor em tempo real (um sucesso com os visitantes, mas indispensável para nós também), modificações (incluindo correções de bugs) em software de código aberto, e uma grande quantidade de arquivos de configuração e configurações. Trevor Blackwell escreveu um programa espetacular para mover lojas para novos servidores em todo o país, sem desligá-las, depois que fomos comprados pela Yahoo. Programas nos paginavam, enviavam faxes e e-mails para os usuários, conduziam transações com processadores de cartão de crédito e conversavam entre si através de sockets, pipes, requisições http, ssh, pacotes udp, memória compartilhada e arquivos. Parte da Viaweb consistia até na ausência de programas, já que uma das chaves para a segurança do Unix é não rodar utilitários desnecessários que as pessoas possam usar para invadir seus servidores.
Não terminou com software. Passamos muito tempo pensando sobre configurações de servidores. Construímos os servidores nós mesmos, a partir de componentes—em parte para economizar dinheiro, e em parte para obter exatamente o que queríamos. Tivemos que pensar se nosso ISP upstream tinha conexões rápidas o suficiente com todos os backbones. Datamos fornecedores de RAID em série.
Mas hardware não é apenas algo com que se preocupar. Quando você o controla, pode fazer mais pelos usuários. Com um aplicativo de desktop, você pode especificar certos requisitos mínimos de hardware, mas não pode adicionar mais. Se você administra os servidores, pode em um passo habilitar todos os seus usuários a paginar pessoas, ou enviar faxes, ou enviar comandos por telefone, ou processar cartões de crédito, etc., apenas instalando o hardware relevante. Sempre procuramos novas maneiras de adicionar recursos com hardware, não apenas porque agradava os usuários, mas também como uma forma de nos distinguir de concorrentes que (ou porque vendiam software de desktop, ou revendiam aplicativos baseados na Web através de ISPs) não tinham controle direto sobre o hardware.
Como o software em um aplicativo baseado na Web será uma coleção de programas em vez de um único binário, ele pode ser escrito em qualquer número de linguagens diferentes. Quando você está escrevendo software de desktop, é praticamente forçado a escrever o aplicativo na mesma linguagem que o sistema operacional subjacente—significando C e C++. E assim, essas linguagens (especialmente entre pessoas não técnicas como gerentes e VCs) passaram a ser consideradas as linguagens para desenvolvimento de software "sério". Mas isso era apenas um artefato da maneira como o software de desktop tinha que ser entregue. Para software baseado em servidor, você pode usar qualquer linguagem que quiser. [3] Hoje, muitos dos melhores hackers estão usando linguagens muito distantes de C e C++: Perl, Python e até Lisp.
Com software baseado em servidor, ninguém pode lhe dizer qual linguagem usar, porque você controla todo o sistema, até o hardware. Diferentes linguagens são boas para diferentes tarefas. Você pode usar a que for melhor para cada uma. E quando você tem concorrentes, "você pode" significa "você deve" (voltaremos a isso mais tarde), porque se você não aproveitar essa possibilidade, seus concorrentes o farão.
A maioria de nossos concorrentes usava C e C++, e isso tornava seu software visivelmente inferior porque (entre outras coisas), eles não tinham como contornar a falta de estado dos scripts CGI. Se você fosse mudar algo, todas as mudanças teriam que acontecer em uma página, com um botão de Atualizar na parte inferior. Como escrevi em outro lugar, ao usar Lisp, que muitas pessoas ainda consideram uma linguagem de pesquisa, conseguimos fazer o editor da Viaweb se comportar mais como software de desktop.
Lançamentos
Uma das mudanças mais importantes neste novo mundo é a maneira como você faz lançamentos. No negócio de software de desktop, fazer um lançamento é um grande trauma, no qual toda a empresa sua e se esforça para lançar um único e gigante pedaço de código. Comparações óbvias se sugerem, tanto para o processo quanto para o produto resultante.
Com software baseado em servidor, você pode fazer mudanças quase como faria em um programa que estava escrevendo para si mesmo. Você libera software como uma série de mudanças incrementais em vez de uma grande explosão ocasional. Uma típica empresa de software de desktop pode fazer um ou dois lançamentos por ano. Na Viaweb, frequentemente fazíamos de três a cinco lançamentos por dia.
Quando você muda para esse novo modelo, percebe o quanto o desenvolvimento de software é afetado pela maneira como é lançado. Muitos dos problemas mais desagradáveis que você vê no negócio de software de desktop são devido à natureza catastrófica dos lançamentos.
Quando você lança apenas uma nova versão por ano, tende a lidar com bugs em grande escala. Algum tempo antes da data de lançamento, você monta uma nova versão na qual metade do código foi arrancada e substituída, introduzindo incontáveis bugs. Então, uma equipe de QA entra e começa a contá-los, e os programadores trabalham na lista, corrigindo-os. Eles geralmente não chegam ao final da lista, e de fato, ninguém tem certeza de onde está o final. É como pescar entulho de um lago. Você nunca realmente sabe o que está acontecendo dentro do software. Na melhor das hipóteses, você acaba com uma espécie de correção estatística.
Com software baseado em servidor, a maior parte da mudança é pequena e incremental. Isso por si só é menos provável de introduzir bugs. Também significa que você sabe o que testar com mais cuidado quando está prestes a liberar software: a última coisa que você mudou. Você acaba tendo um controle muito mais firme sobre o código. Como regra geral, você sabe o que está acontecendo dentro dele. Você não tem o código-fonte memorizado, é claro, mas quando lê o código-fonte, faz isso como um piloto escaneando o painel de instrumentos, não como um detetive tentando desvendar algum mistério.
O software de desktop gera um certo fatalismo sobre bugs. Você sabe que está enviando algo carregado de bugs, e até mesmo configurou mecanismos para compensar isso (por exemplo, lançamentos de patches). Então, por que se preocupar com alguns a mais? Logo você está lançando recursos inteiros que sabe que estão quebrados. Apple fez isso no início deste ano. Eles se sentiram pressionados a lançar seu novo sistema operacional, cuja data de lançamento já havia sido adiada quatro vezes, mas parte do software (suporte para CDs e DVDs) não estava pronta. A solução? Eles lançaram o sistema operacional sem as partes inacabadas, e os usuários terão que instalá-las mais tarde.
Com software baseado na Web, você nunca precisa lançar software antes que funcione, e pode liberá-lo assim que funcionar.
O veterano da indústria pode estar pensando, é uma ideia que soa bem dizer que você nunca precisa lançar software antes que funcione, mas o que acontece quando você prometeu entregar uma nova versão do seu software até uma certa data? Com software baseado na Web, você não faria tal promessa, porque não há versões. Seu software muda gradualmente e continuamente. Algumas mudanças podem ser maiores que outras, mas a ideia de versões simplesmente não se encaixa naturalmente no software baseado na Web.
Se alguém se lembra da Viaweb, isso pode soar estranho, porque estávamos sempre anunciando novas versões. Isso foi feito inteiramente para fins de PR. A imprensa especializada, aprendemos, pensa em números de versão. Eles lhe darão uma cobertura significativa para um lançamento importante, significando um novo primeiro dígito no número da versão, e geralmente um parágrafo no máximo para um lançamento pontual, significando um novo dígito após o ponto decimal.
Alguns de nossos concorrentes estavam oferecendo software de desktop e realmente tinham números de versão. E para esses lançamentos, o mero fato de que isso parecia para nós uma evidência de sua retrogradação, eles recebiam todo tipo de publicidade. Não queríamos perder essa oportunidade, então começamos a dar números de versão ao nosso software também. Quando queríamos alguma publicidade, fazíamos uma lista de todos os recursos que havíamos adicionado desde o último "lançamento", colocávamos um novo número de versão no software e emitíamos um comunicado à imprensa dizendo que a nova versão estava disponível imediatamente. Incrivelmente, ninguém nunca nos questionou sobre isso.
Quando fomos comprados, já havíamos feito isso três vezes, então estávamos na Versão 4. Versão 4.1 se não me engano. Depois que a Viaweb se tornou Yahoo Store, não havia mais uma necessidade tão desesperada por publicidade, então, embora o software continuasse a evoluir, toda a ideia de números de versão foi silenciosamente abandonada.
Bugs
A outra grande vantagem técnica do software baseado na Web é que você pode reproduzir a maioria dos bugs. Você tem os dados dos usuários bem ali no seu disco. Se alguém quebra seu software, você não precisa tentar adivinhar o que está acontecendo, como faria com software de desktop: você deve ser capaz de reproduzir o erro enquanto eles estão ao telefone com você. Você pode até já saber sobre isso, se tiver código para notar erros embutido em seu aplicativo.
O software baseado na Web é usado 24 horas por dia, então tudo o que você faz é imediatamente colocado à prova. Bugs aparecem rapidamente.
As empresas de software às vezes são acusadas de deixar os usuários depurarem seu software. E isso é exatamente o que estou defendendo. Para software baseado na Web, é na verdade um bom plano, porque os bugs são menos e transitórios. Quando você libera software gradualmente, obtém muito menos bugs para começar. E quando você pode reproduzir erros e liberar mudanças instantaneamente, pode encontrar e corrigir a maioria dos bugs assim que aparecem. Nunca tivemos bugs suficientes em qualquer momento para nos preocuparmos com um sistema formal de rastreamento de bugs.
Você deve testar mudanças antes de liberá-las, é claro, então nenhum grande bug deve ser liberado. Aqueles poucos que inevitavelmente escapam envolverão casos limítrofes e afetarão apenas os poucos usuários que os encontrarem antes que alguém ligue para reclamar. Desde que você conserte os bugs imediatamente, o efeito líquido, para o usuário médio, é muito menos bugs. Duvido que o usuário médio da Viaweb tenha visto um bug.
Consertar bugs novos é mais fácil do que consertar os antigos. Geralmente é bastante rápido encontrar um bug em um código que você acabou de escrever. Quando ele aparece, você muitas vezes sabe o que está errado antes mesmo de olhar para o código-fonte, porque já estava se preocupando com isso subconscientemente. Corrigir um bug em algo que você escreveu há seis meses (o caso médio se você lançar uma vez por ano) é muito mais trabalho. E como você não entende o código tão bem, é mais provável que o conserte de uma maneira feia, ou até introduza mais bugs. [4]
Quando você pega bugs cedo, também obtém menos bugs compostos. Bugs compostos são dois bugs separados que interagem: você tropeça ao descer as escadas, e quando alcança o corrimão, ele se solta na sua mão. Em software, esse tipo de bug é o mais difícil de encontrar e também tende a ter as piores consequências. [5] A abordagem tradicional de "quebrar tudo e depois filtrar os bugs" gera inerentemente muitos bugs compostos. E software que é liberado em uma série de pequenas mudanças tende a não ter. Os andares estão constantemente sendo varridos de qualquer objeto solto que possa depois ficar preso em algo.
Ajuda se você usar uma técnica chamada programação funcional. Programação funcional significa evitar efeitos colaterais. É algo que você é mais provável de ver em artigos de pesquisa do que em software comercial, mas para aplicativos baseados na Web, acaba sendo realmente útil. É difícil escrever programas inteiros como código puramente funcional, mas você pode escrever partes substanciais dessa forma. Isso torna essas partes do seu software mais fáceis de testar, porque não têm estado, e isso é muito conveniente em uma situação onde você está constantemente fazendo e testando pequenas modificações. Eu escrevi grande parte do editor da Viaweb nesse estilo, e fizemos nossa linguagem de script, RTML, uma linguagem puramente funcional.
Pessoas do negócio de software de desktop acharão isso difícil de acreditar, mas na Viaweb, bugs se tornaram quase um jogo. Como a maioria dos bugs liberados envolvia casos limítrofes, os usuários que os encontravam eram mais propensos a ser usuários avançados, empurrando os limites. Usuários avançados são mais tolerantes a bugs, especialmente porque você provavelmente os introduziu no curso de adicionar algum recurso que eles estavam pedindo. De fato, como os bugs eram raros e você tinha que estar fazendo coisas sofisticadas para vê-los, os usuários avançados muitas vezes se sentiam orgulhosos de pegar um. Eles ligavam para o suporte em um espírito mais de triunfo do que de raiva, como se tivessem marcado pontos contra nós.
Suporte
Quando você pode reproduzir erros, isso muda sua abordagem ao suporte ao cliente. Na maioria das empresas de software, o suporte é oferecido como uma forma de fazer os clientes se sentirem melhor. Eles estão ligando para você sobre um bug conhecido, ou estão apenas fazendo algo errado e você tem que descobrir o que. Em qualquer um dos casos, não há muito que você possa aprender com eles. E assim, você tende a ver as chamadas de suporte como uma dor de cabeça que deseja isolar de seus desenvolvedores o máximo possível.
Não era assim que as coisas funcionavam na Viaweb. Na Viaweb, o suporte era gratuito, porque queríamos ouvir os clientes. Se alguém tivesse um problema, queríamos saber sobre isso imediatamente para que pudéssemos reproduzir o erro e liberar uma correção.
Assim, na Viaweb, os desenvolvedores estavam sempre em contato próximo com o suporte. As pessoas de suporte ao cliente estavam a cerca de dez metros dos programadores e sabiam que poderiam sempre interromper qualquer coisa com um relato de um bug genuíno. Nós deixaríamos uma reunião de diretoria para corrigir um bug sério.
Nossa abordagem ao suporte deixou todos mais felizes. Os clientes estavam encantados. Imagine como seria ligar para uma linha de suporte e ser tratado como alguém trazendo notícias importantes. As pessoas de suporte ao cliente gostavam disso porque significava que podiam ajudar os usuários, em vez de ler roteiros para eles. E os programadores gostavam disso porque podiam reproduzir bugs em vez de apenas ouvir relatos vagos de segunda mão sobre eles.
Nossa política de corrigir bugs em tempo real mudou a relação entre as pessoas de suporte ao cliente e os hackers. Na maioria das empresas de software, as pessoas de suporte são escudos humanos mal pagos, e os hackers são pequenas cópias de Deus Pai, criadores do mundo. Seja qual for o procedimento para relatar bugs, é provável que seja unidirecional: as pessoas de suporte que ouvem sobre bugs preenchem algum formulário que eventualmente é passado (possivelmente via QA) para os programadores, que o colocam em sua lista de coisas a fazer. Era muito diferente na Viaweb. Dentro de um minuto de ouvir sobre um bug de um cliente, as pessoas de suporte poderiam estar ao lado de um programador ouvindo-o dizer "Droga, você está certo, é um bug." Isso encantava as pessoas de suporte ouvir que "você está certo" dos hackers. Elas costumavam nos trazer bugs com o mesmo ar expectante de um gato trazendo um rato que acabou de matar. Isso também as tornava mais cuidadosas ao julgar a seriedade de um bug, porque agora sua honra estava em jogo.
Depois que fomos comprados pela Yahoo, as pessoas de suporte ao cliente foram afastadas dos programadores. Foi só então que percebemos que elas eram efetivamente QA e, até certo ponto, marketing também. Além de pegar bugs, elas eram as guardiãs do conhecimento de coisas mais vagas, semelhantes a bugs, como recursos que confundiam os usuários. [6] Elas também eram uma espécie de grupo focal proxy; podíamos perguntar a elas qual de dois novos recursos os usuários queriam mais, e elas estavam sempre certas.
Moral
Ser capaz de liberar software imediatamente é um grande motivador. Muitas vezes, enquanto caminhava para o trabalho, pensava em alguma mudança que queria fazer no software e a fazia naquele dia. Isso funcionava para recursos maiores também. Mesmo que algo fosse levar duas semanas para escrever (poucos projetos levavam mais), eu sabia que poderia ver o efeito no software assim que estivesse pronto.
Se eu tivesse que esperar um ano pelo próximo lançamento, teria arquivado a maioria dessas ideias, por um tempo pelo menos. A questão sobre ideias, no entanto, é que elas levam a mais ideias. Você já notou que quando se senta para escrever algo, metade das ideias que acabam nele são aquelas que você pensou enquanto o escrevia? A mesma coisa acontece com software. Trabalhar para implementar uma ideia lhe dá mais ideias. Portanto, arquivar uma ideia custa não apenas aquele atraso na implementação, mas também todas as ideias que a implementação teria gerado. De fato, arquivar uma ideia provavelmente até inibe novas ideias: à medida que você começa a pensar em algum novo recurso, você avista a prateleira e pensa "mas eu já tenho muitas coisas novas que quero fazer para o próximo lançamento."
O que as grandes empresas fazem em vez de implementar recursos é planejar. Na Viaweb, às vezes nos metíamos em problemas por causa disso. Investidores e analistas nos perguntavam o que tínhamos planejado para o futuro. A resposta verdadeira teria sido que não tínhamos planos. Tínhamos ideias gerais sobre coisas que queríamos melhorar, mas se soubéssemos como, já teríamos feito. O que íamos fazer nos próximos seis meses? O que parecesse a maior vitória. Não sei se alguma vez ousei dar essa resposta, mas essa era a verdade. Planos são apenas outra palavra para ideias na prateleira. Quando pensávamos em boas ideias, as implementávamos.
Na Viaweb, como em muitas empresas de software, a maior parte do código tinha um proprietário definido. Mas quando você possuía algo, realmente o possuía: ninguém além do proprietário de um pedaço de software precisava aprovar (ou mesmo saber sobre) um lançamento. Não havia proteção contra quebras, exceto o medo de parecer um idiota para seus pares, e isso era mais do que suficiente. Posso ter dado a impressão de que apenas avançávamos alegremente escrevendo código. Fomos rápidos, mas pensávamos muito cuidadosamente antes de liberar software nesses servidores. E prestar atenção é mais importante para a confiabilidade do que se mover lentamente. Porque ele presta atenção de perto, um piloto da Marinha pode pousar uma aeronave de 40.000 lb a 140 milhas por hora em um convés de porta-aviões em movimento, à noite, mais seguramente do que o adolescente médio pode cortar um bagel.
Essa maneira de escrever software é uma espada de dois gumes, é claro. Funciona muito melhor para uma pequena equipe de bons programadores de confiança do que funcionaria para uma grande empresa de programadores medianos, onde ideias ruins são capturadas por comitês em vez de pelas pessoas que as tiveram.
Brooks ao Contrário
Felizmente, o software baseado na Web requer menos programadores. Uma vez trabalhei para uma empresa de software de desktop de médio porte que tinha mais de 100 pessoas trabalhando em engenharia como um todo. Apenas 13 delas estavam em desenvolvimento de produtos. Todas as outras estavam trabalhando em lançamentos, portos, e assim por diante. Com software baseado na Web, tudo o que você precisa (no máximo) são as 13 pessoas, porque não há lançamentos, portos, e assim por diante.
A Viaweb foi escrita por apenas três pessoas. [7] Eu estava sempre sob pressão para contratar mais, porque queríamos ser comprados, e sabíamos que os compradores teriam dificuldade em pagar um preço alto por uma empresa com apenas três programadores. (Solução: contratamos mais, mas criamos novos projetos para eles.)
Quando você pode escrever software com menos programadores, isso economiza mais do que dinheiro. Como Fred Brooks apontou em The Mythical Man-Month, adicionar pessoas a um projeto tende a desacelerá-lo. O número de conexões possíveis entre desenvolvedores cresce exponencialmente com o tamanho do grupo. Quanto maior o grupo, mais tempo eles gastarão em reuniões negociando como seu software funcionará em conjunto, e mais bugs eles terão de interações imprevistas. Felizmente, esse processo também funciona ao contrário: à medida que os grupos ficam menores, o desenvolvimento de software se torna exponencialmente mais eficiente. Não consigo me lembrar de os programadores da Viaweb terem alguma vez tido uma reunião real. Nunca tivemos mais a dizer em um único momento do que podíamos dizer enquanto caminhávamos para o almoço.
Se há um lado negativo aqui, é que todos os programadores têm que ser, até certo ponto, administradores de sistema também. Quando você está hospedando software, alguém precisa estar observando os servidores, e na prática, as únicas pessoas que podem fazer isso corretamente são aquelas que escreveram o software. Na Viaweb, nosso sistema tinha tantos componentes e mudava com tanta frequência que não havia uma fronteira definida entre software e infraestrutura. Declarar arbitrariamente tal fronteira teria restringido nossas escolhas de design. E assim, embora estivéssemos constantemente esperando que um dia ("em alguns meses") tudo estivesse estável o suficiente para que pudéssemos contratar alguém cujo trabalho fosse apenas se preocupar com os servidores, isso nunca aconteceu.
Não acho que poderia ser de outra forma, enquanto você ainda estiver desenvolvendo ativamente o produto. O software baseado na Web nunca será algo que você escreve, registra e vai para casa. É uma coisa viva, rodando em seus servidores agora mesmo. Um bug ruim pode não apenas travar o processo de um usuário; pode travar todos eles. Se um bug em seu código corrompe alguns dados no disco, você precisa consertá-lo. E assim por diante. Descobrimos que você não precisa observar os servidores a cada minuto (depois do primeiro ano ou mais), mas definitivamente quer manter um olho nas coisas que você mudou recentemente. Você não libera código tarde da noite e depois vai para casa.
Observando os Usuários
Com software baseado em servidor, você está em contato mais próximo com seu código. Você também pode estar em contato mais próximo com seus usuários. A Intuit é famosa por se apresentar aos clientes em lojas de varejo e pedir para segui-los para casa. Se você já assistiu alguém usar seu software pela primeira vez, sabe quais surpresas devem ter aguardado por eles.
O software deve fazer o que os usuários acham que fará. Mas você não pode ter ideia do que os usuários estarão pensando, acredite em mim, até que os observe. E o software baseado na Web lhe dá informações sem precedentes sobre seu comportamento. Você não está limitado a pequenos grupos focais artificiais. Você pode ver cada clique feito por cada usuário. Você precisa considerar cuidadosamente o que vai observar, porque não quer violar a privacidade dos usuários, mas até mesmo a amostragem estatística mais geral pode ser muito útil.
Quando você tem os usuários em seu servidor, não precisa confiar em benchmarks, por exemplo. Benchmarks são usuários simulados. Com software baseado na Web, você pode observar usuários reais. Para decidir o que otimizar, basta entrar em um servidor e ver o que está consumindo toda a CPU. E você sabe quando parar de otimizar também: eventualmente conseguimos levar o editor da Viaweb ao ponto em que estava limitado pela memória em vez de pela CPU, e como não havia nada que pudéssemos fazer para diminuir o tamanho dos dados dos usuários (bem, nada fácil), sabíamos que poderíamos parar por ali.
A eficiência importa para software baseado na Web, porque você está pagando pelo hardware. O número de usuários que você pode suportar por servidor é o divisor de seu custo de capital, então, se você puder tornar seu software muito eficiente, poderá vender a preços mais baixos que os concorrentes e ainda assim obter lucro. Na Viaweb, conseguimos reduzir o custo de capital por usuário para cerca de $5. Seria menos agora, provavelmente menos do que o custo de enviar a eles a fatura do primeiro mês. O hardware é gratuito agora, se seu software for razoavelmente eficiente.
Observar os usuários pode guiá-lo no design, bem como na otimização. A Viaweb tinha uma linguagem de script chamada RTML que permitia que usuários avançados definissem seus próprios estilos de página. Descobrimos que o RTML se tornou uma espécie de caixa de sugestões, porque os usuários só a usavam quando os estilos de página predefinidos não podiam fazer o que eles queriam. Originalmente, o editor colocava barras de botões na página, por exemplo, mas depois que vários usuários usaram o RTML para colocar botões na lateral esquerda, fizemos disso uma opção (de fato, o padrão) nos estilos de página predefinidos.
Finalmente, ao observar os usuários, você pode muitas vezes dizer quando eles estão em apuros. E como o cliente está sempre certo, isso é um sinal de algo que você precisa corrigir. Na Viaweb, a chave para conseguir usuários era o test drive online. Não era apenas uma série de slides construídos por pessoas de marketing. Em nosso test drive, os usuários realmente usavam o software. Levava cerca de cinco minutos, e no final, eles haviam construído uma loja real e funcional.
O test drive foi a maneira como conseguimos quase todos os nossos novos usuários. Acho que será o mesmo para a maioria dos aplicativos baseados na Web. Se os usuários conseguirem passar por um test drive com sucesso, eles gostarão do produto. Se ficarem confusos ou entediados, não gostarão. Portanto, qualquer coisa que pudéssemos fazer para fazer mais pessoas passarem pelo test drive aumentaria nossa taxa de crescimento.
Estudei os rastros de cliques de pessoas fazendo o test drive e descobri que em uma certa etapa elas ficavam confusas e clicavam no botão Voltar do navegador. (Se você tentar escrever aplicações baseadas na Web, descobrirá que o botão Voltar se torna um dos seus problemas filosóficos mais interessantes.) Então, adicionei uma mensagem naquele ponto, dizendo aos usuários que eles estavam quase terminando e lembrando-os para não clicarem no botão Voltar. Outra grande coisa sobre software baseado na Web é que você recebe feedback instantâneo das mudanças: o número de pessoas completando o test drive subiu imediatamente de 60% para 90%. E como o número de novos usuários era uma função do número de test drives completados, nosso crescimento de receita aumentou em 50%, apenas com essa mudança.
Dinheiro
No início dos anos 1990, li um artigo em que alguém dizia que software era um negócio de assinatura. A princípio, isso parecia uma afirmação muito cínica. Mas depois percebi que reflete a realidade: o desenvolvimento de software é um processo contínuo. Acho que é mais limpo se você cobrar abertamente taxas de assinatura, em vez de forçar as pessoas a continuarem comprando e instalando novas versões para que elas continuem pagando você. E, felizmente, assinaturas são a maneira natural de faturar por aplicações baseadas na Web.
Hospedar aplicações é uma área onde as empresas desempenharão um papel que provavelmente não será preenchido por freeware. Hospedar aplicações é muito estressante e tem despesas reais. Ninguém vai querer fazer isso de graça.
Para as empresas, aplicações baseadas na Web são uma fonte ideal de receita. Em vez de começar cada trimestre com uma folha em branco, você tem um fluxo de receita recorrente. Como seu software evolui gradualmente, você não precisa se preocupar que um novo modelo falhe; nunca precisa haver um novo modelo, por si só, e se você fizer algo no software que os usuários odeiam, saberá imediatamente. Você não tem problemas com contas incobráveis; se alguém não pagar, você pode simplesmente desligar o serviço. E não há possibilidade de pirataria.
Essa última "vantagem" pode acabar se tornando um problema. Uma certa quantidade de pirataria é vantajosa para as empresas de software. Se algum usuário realmente não teria comprado seu software a qualquer preço, você não perdeu nada se ele usar uma cópia pirata. Na verdade, você ganha, porque ele é mais um usuário ajudando a tornar seu software o padrão—ou que pode comprar uma cópia mais tarde, quando se formar no ensino médio.
Quando podem, as empresas gostam de fazer algo chamado discriminação de preços, que significa cobrar de cada cliente o quanto eles podem pagar. [8] O software é particularmente adequado para discriminação de preços, porque o custo marginal é próximo de zero. É por isso que alguns softwares custam mais para rodar em Suns do que em máquinas Intel: uma empresa que usa Suns não está interessada em economizar dinheiro e pode ser cobrada mais. A pirataria é efetivamente o nível mais baixo de discriminação de preços. Acho que as empresas de software entendem isso e deliberadamente fecham os olhos para alguns tipos de pirataria. [9] Com software baseado em servidor, elas terão que encontrar alguma outra solução.
Software baseado na Web vende bem, especialmente em comparação com software de desktop, porque é fácil de comprar. Você pode pensar que as pessoas decidem comprar algo e depois compram, como se fossem dois passos separados. Era isso que eu pensava antes do Viaweb, na medida em que pensava sobre a questão. Na verdade, o segundo passo pode se propagar de volta para o primeiro: se algo é difícil de comprar, as pessoas mudarão de ideia sobre se realmente o queriam. E vice-versa: você venderá mais de algo quando for fácil de comprar. Eu compro mais livros porque a Amazon existe. Software baseado na Web é quase a coisa mais fácil do mundo para se comprar, especialmente se você acabou de fazer uma demonstração online. Os usuários não deveriam ter que fazer muito mais do que inserir um número de cartão de crédito. (Faça-os fazer mais por sua conta e risco.)
Às vezes, software baseado na Web é oferecido através de ISPs atuando como revendedores. Essa é uma má ideia. Você precisa estar administrando os servidores, porque precisa estar constantemente melhorando tanto o hardware quanto o software. Se você abrir mão do controle direto dos servidores, abrirá mão da maioria das vantagens de desenvolver aplicações baseadas na Web.
Vários de nossos concorrentes se prejudicaram dessa forma—geralmente, acho, porque foram dominados por executivos que estavam empolgados com esse enorme canal potencial e não perceberam que isso arruinaria o produto que esperavam vender através dele. Vender software baseado na Web através de ISPs é como vender sushi através de máquinas de venda automática.
Clientes
Quem serão os clientes? No Viaweb, eles eram inicialmente indivíduos e pequenas empresas, e acho que essa será a regra com aplicações baseadas na Web. Esses são os usuários que estão prontos para experimentar coisas novas, em parte porque são mais flexíveis, e em parte porque querem os custos mais baixos da nova tecnologia.
Aplicações baseadas na Web muitas vezes serão a melhor coisa para grandes empresas também (embora elas demorem a perceber isso). A melhor intranet é a Internet. Se uma empresa usa verdadeiras aplicações baseadas na Web, o software funcionará melhor, os servidores serão melhor administrados e os funcionários terão acesso ao sistema de qualquer lugar.
O argumento contra essa abordagem geralmente gira em torno da segurança: se o acesso é mais fácil para os funcionários, será para os bandidos também. Alguns comerciantes maiores estavam relutantes em usar o Viaweb porque achavam que as informações do cartão de crédito dos clientes estariam mais seguras em seus próprios servidores. Não foi fácil fazer esse ponto diplomaticamente, mas, na verdade, os dados estavam quase certamente mais seguros em nossas mãos do que nas deles. Quem pode contratar pessoas melhores para gerenciar a segurança, uma startup de tecnologia cujo negócio é rodar servidores, ou um varejista de roupas? Não só tínhamos pessoas melhores preocupadas com a segurança, como nos preocupávamos mais com isso. Se alguém invadisse os servidores do varejista de roupas, isso afetaria no máximo um comerciante, poderia provavelmente ser abafado e, no pior dos casos, poderia fazer uma pessoa ser demitida. Se alguém invadisse os nossos, isso poderia afetar milhares de comerciantes, provavelmente acabaria como notícia no CNet e poderia nos colocar fora do negócio.
Se você quer manter seu dinheiro seguro, você o mantém debaixo do seu colchão em casa ou o coloca em um banco? Esse argumento se aplica a todos os aspectos da administração de servidores: não apenas segurança, mas tempo de atividade, largura de banda, gerenciamento de carga, backups, etc. Nossa existência dependia de fazer essas coisas corretamente. Problemas de servidor eram o grande não-não para nós, como um brinquedo perigoso seria para um fabricante de brinquedos, ou um surto de salmonela para um processador de alimentos.
Uma grande empresa que usa aplicações baseadas na Web está, até certo ponto, terceirizando TI. Drástico como parece, acho que isso é geralmente uma boa ideia. As empresas provavelmente receberão um serviço melhor dessa forma do que teriam de administradores de sistemas internos. Administradores de sistemas podem se tornar rabugentos e não responsivos porque não estão diretamente expostos à pressão competitiva: um vendedor tem que lidar com clientes, e um desenvolvedor tem que lidar com o software dos concorrentes, mas um administrador de sistemas, como um velho solteirão, tem poucas forças externas para mantê-lo na linha. [10] No Viaweb, tínhamos forças externas em abundância para nos manter na linha. As pessoas que nos ligavam eram clientes, não apenas colegas de trabalho. Se um servidor travasse, nós pulávamos; só de pensar nisso me dá um jolt de adrenalina, anos depois.
Portanto, aplicações baseadas na Web normalmente serão a resposta certa para grandes empresas também. Elas serão as últimas a perceber isso, no entanto, assim como foram com computadores de mesa. E em parte pela mesma razão: valerá muito dinheiro convencer grandes empresas de que elas precisam de algo mais caro.
Sempre há uma tendência para clientes ricos comprarem soluções caras, mesmo quando soluções baratas são melhores, porque as pessoas que oferecem soluções caras podem gastar mais para vendê-las. No Viaweb, sempre enfrentamos isso. Perdemos vários comerciantes de alto nível para empresas de consultoria em Web que os convenceram de que estariam melhor se pagassem quinhentos mil dólares por uma loja online personalizada em seu próprio servidor. Eles não estavam, como mais de um descobriu quando a temporada de compras de Natal chegou e as cargas aumentaram em seus servidores. O Viaweb era muito mais sofisticado do que o que a maioria desses comerciantes obteve, mas não podíamos nos dar ao luxo de dizer isso. A $300 por mês, não podíamos nos dar ao luxo de enviar uma equipe de pessoas bem vestidas e com uma aparência autoritária para fazer apresentações para os clientes.
Uma grande parte do que as grandes empresas pagam a mais é o custo de vender coisas caras para elas. (Se o Departamento de Defesa paga mil dólares por assentos de vaso sanitário, é em parte porque custa muito vender assentos de vaso sanitário por mil dólares.) E essa é uma das razões pelas quais o software intranet continuará a prosperar, mesmo que provavelmente seja uma má ideia. É simplesmente mais caro. Não há nada que você possa fazer sobre esse enigma, então o melhor plano é ir atrás dos clientes menores primeiro. O resto virá com o tempo.
Filho do Servidor
Executar software no servidor não é nada novo. Na verdade, é o modelo antigo: aplicações de mainframe são todas baseadas em servidor. Se software baseado em servidor é uma boa ideia, por que perdeu da última vez? Por que os computadores de mesa eclipsaram os mainframes?
A princípio, os computadores de mesa não pareciam uma grande ameaça. Os primeiros usuários eram todos hackers—ou hobbyistas, como eram chamados na época. Eles gostavam de microcomputadores porque eram baratos. Pela primeira vez, você poderia ter seu próprio computador. A expressão "computador pessoal" faz parte da linguagem agora, mas quando foi usada pela primeira vez tinha um som deliberadamente audacioso, como a expressão "satélite pessoal" teria hoje.
Por que os computadores de mesa dominaram? Acho que foi porque tinham software melhor. E acho que a razão pela qual o software de microcomputador era melhor é que podia ser escrito por pequenas empresas.
Não acho que muitas pessoas percebam quão frágeis e tentativas são as startups em seu estágio mais inicial. Muitas startups começam quase por acidente—como um casal de caras, seja com empregos diurnos ou na escola, escrevendo um protótipo de algo que pode, se parecer promissor, se transformar em uma empresa. Nesse estágio larval, qualquer obstáculo significativo pode parar a startup em seu caminho. Escrever software de mainframe exigia muito compromisso desde o início. As máquinas de desenvolvimento eram caras, e como os clientes seriam grandes empresas, você precisaria de uma força de vendas impressionante para vendê-lo a elas. Começar uma startup para escrever software de mainframe seria um empreendimento muito mais sério do que apenas juntar algo no seu Apple II à noite. E assim você não tinha muitas startups escrevendo aplicações de mainframe.
A chegada dos computadores de mesa inspirou muito novo software, porque escrever aplicações para eles parecia um objetivo alcançável para startups larvais. O desenvolvimento era barato, e os clientes seriam pessoas individuais que você poderia alcançar através de lojas de informática ou até mesmo por correio.
A aplicação que empurrou os computadores de mesa para o mainstream foi o VisiCalc, a primeira planilha. Foi escrita por dois caras trabalhando em um sótão, e ainda assim fazia coisas que nenhum software de mainframe poderia fazer. [11] O VisiCalc foi um avanço tão grande, em seu tempo, que as pessoas compraram Apple IIs apenas para executá-lo. E esse foi o começo de uma tendência: os computadores de mesa venceram porque startups escreveram software para eles.
Parece que o software baseado em servidor será bom desta vez, porque startups o escreverão. Os computadores estão tão baratos agora que você pode começar, como nós fizemos, usando um computador de mesa como servidor. Processadores baratos devoraram o mercado de estações de trabalho (você raramente ouve a palavra agora) e estão quase dominando o mercado de servidores; os servidores do Yahoo, que lidam com cargas tão altas quanto qualquer uma na Internet, têm todos os mesmos processadores Intel baratos que você tem em sua máquina de mesa. E uma vez que você escreveu o software, tudo que você precisa para vendê-lo é um site. Quase todos os nossos usuários vieram diretamente para nosso site através do boca a boca e referências na imprensa. [12]
O Viaweb era uma típica startup larval. Estávamos aterrorizados em começar uma empresa e, nos primeiros meses, nos confortávamos tratando tudo como um experimento que poderíamos cancelar a qualquer momento. Felizmente, havia poucos obstáculos, exceto os técnicos. Enquanto estávamos escrevendo o software, nosso servidor Web era a mesma máquina de mesa que usávamos para desenvolvimento, conectada ao mundo exterior por uma linha discada. Nossas únicas despesas nessa fase eram comida e aluguel.
Há ainda mais razões para startups escreverem software baseado na Web agora, porque escrever software de desktop se tornou muito menos divertido. Se você quiser escrever software de desktop agora, você o faz nos termos da Microsoft, chamando suas APIs e contornando seu sistema operacional cheio de bugs. E se você conseguir escrever algo que decole, pode descobrir que estava apenas fazendo pesquisa de mercado para a Microsoft.
Se uma empresa quer criar uma plataforma na qual as startups possam construir, precisa torná-la algo que os hackers que a criaram queiram usar. Isso significa que precisa ser barato e bem projetado. O Mac era popular entre os hackers quando foi lançado, e muitos deles escreveram software para ele. [13] Você vê isso menos com o Windows, porque os hackers não o usam. O tipo de pessoas que são boas em escrever software tendem a estar rodando Linux ou FreeBSD agora.
Não acho que teríamos começado uma startup para escrever software de desktop, porque o software de desktop tem que rodar no Windows, e antes de podermos escrever software para Windows, teríamos que usá-lo. A Web nos permitiu contornar o Windows e entregar software rodando em Unix diretamente aos usuários através do navegador. Essa é uma perspectiva libertadora, muito parecida com a chegada dos PCs há vinte e cinco anos.
Microsoft
Quando os computadores de mesa chegaram, a IBM era o gigante do qual todos tinham medo. É difícil imaginar agora, mas lembro-me muito bem da sensação. Agora o gigante assustador é a Microsoft, e não acho que eles estejam tão cegos para a ameaça que enfrentam quanto a IBM estava. Afinal, a Microsoft construiu deliberadamente seu negócio no ponto cego da IBM.
Mencionei anteriormente que minha mãe realmente não precisa de um computador de mesa. A maioria dos usuários provavelmente não precisa. Isso é um problema para a Microsoft, e eles sabem disso. Se as aplicações rodarem em servidores remotos, ninguém precisa do Windows. O que a Microsoft fará? Eles conseguirão usar seu controle sobre a área de trabalho para prevenir ou restringir essa nova geração de software?
Meu palpite é que a Microsoft desenvolverá algum tipo de híbrido servidor/desktop, onde o sistema operacional trabalha em conjunto com servidores que eles controlam. No mínimo, os arquivos estarão centralmente disponíveis para usuários que desejam isso. Não espero que a Microsoft vá até o extremo de fazer os cálculos no servidor, com apenas um navegador como cliente, se puder evitá-lo. Se você só precisa de um navegador como cliente, não precisa da Microsoft no cliente, e se a Microsoft não controla o cliente, não pode empurrar os usuários em direção a suas aplicações baseadas em servidor.
Acho que a Microsoft terá dificuldades para manter o gênio na garrafa. Haverá muitos tipos diferentes de clientes para eles controlarem todos. E se as aplicações da Microsoft só funcionarem com alguns clientes, os concorrentes poderão superá-los oferecendo aplicações que funcionam de qualquer cliente. [14]
Em um mundo de aplicações baseadas na Web, não há um lugar automático para a Microsoft. Eles podem ter sucesso em se fazer um lugar, mas não acho que dominarão esse novo mundo como dominaram o mundo das aplicações de desktop.
Não é tanto que um concorrente os derrubará, mas sim que eles tropeçarão em si mesmos. Com a ascensão do software baseado na Web, eles enfrentarão não apenas problemas técnicos, mas também seu próprio pensamento otimista. O que eles precisam fazer é canibalizar seu negócio existente, e não consigo vê-los enfrentando isso. A mesma determinação que os trouxe até aqui agora trabalhará contra eles. A IBM estava exatamente na mesma situação, e não conseguiu dominá-la. A IBM fez uma entrada tardia e desinteressada no negócio de microcomputadores porque estava ambivalente sobre ameaçar sua vaca leiteira, a computação de mainframe. A Microsoft também será prejudicada por querer salvar a área de trabalho. Uma vaca leiteira pode ser um peso muito pesado nas suas costas.
Não estou dizendo que ninguém dominará aplicações baseadas em servidor. Alguém provavelmente o fará eventualmente. Mas acho que haverá um bom longo período de caos alegre, assim como houve nos primeiros dias dos microcomputadores. Aquela foi uma boa época para startups. Muitas pequenas empresas prosperaram e fizeram isso criando coisas legais.
Startups, mas Mais
A startup clássica é rápida e informal, com poucas pessoas e pouco dinheiro. Essas poucas pessoas trabalham muito, e a tecnologia amplifica o efeito das decisões que tomam. Se ganham, ganham muito.
Em uma startup escrevendo aplicações baseadas na Web, tudo o que você associa a startups é levado ao extremo. Você pode escrever e lançar um produto com ainda menos pessoas e ainda menos dinheiro. Você precisa ser ainda mais rápido, e pode se dar ao luxo de ser mais informal. Você pode literalmente lançar seu produto como três caras sentados na sala de estar de um apartamento, e um servidor colocalizado em um ISP. Nós fizemos.
Com o tempo, as equipes se tornaram menores, mais rápidas e mais informais. Em 1960, o desenvolvimento de software significava uma sala cheia de homens com óculos de aro e gravatas pretas estreitas, escrevendo industriosamente dez linhas de código por dia em formulários de codificação da IBM. Em 1980, era uma equipe de oito a dez pessoas vestindo jeans para o escritório e digitando em vt100s. Agora é um casal de caras sentados em uma sala de estar com laptops. (E jeans não são a última palavra em informalidade.)
Startups são estressantes, e isso, infelizmente, também é levado ao extremo com aplicações baseadas na Web. Muitas empresas de software, especialmente no início, têm períodos em que os desenvolvedores dormem debaixo de suas mesas e assim por diante. A coisa alarmante sobre software baseado na Web é que não há nada para impedir que isso se torne o padrão. As histórias sobre dormir debaixo das mesas geralmente terminam: então finalmente o enviamos e todos fomos para casa e dormimos por uma semana. O software baseado na Web nunca é enviado. Você pode trabalhar 16 horas por dia pelo tempo que quiser. E porque você pode, e seus concorrentes também podem, você tende a ser forçado a isso. Você pode, então deve. É a Lei de Parkinson funcionando ao contrário.
A pior coisa não são as horas, mas a responsabilidade. Programadores e administradores de sistemas tradicionalmente têm suas próprias preocupações separadas. Programadores têm que se preocupar com bugs, e administradores de sistemas têm que se preocupar com infraestrutura. Programadores podem passar um longo dia até os cotovelos em código-fonte, mas em algum momento eles podem ir para casa e esquecer disso. Administradores de sistemas nunca deixam o trabalho para trás, mas quando são chamados às 4:00 da manhã, geralmente não precisam fazer nada muito complicado. Com aplicações baseadas na Web, esses dois tipos de estresse se combinam. Os programadores se tornam administradores de sistemas, mas sem os limites bem definidos que normalmente tornam o trabalho suportável.
No Viaweb, passamos os primeiros seis meses apenas escrevendo software. Trabalhamos as longas horas habituais de uma startup inicial. Em uma empresa de software de desktop, essa teria sido a parte em que estávamos trabalhando duro, mas parecia uma férias em comparação com a próxima fase, quando trouxemos usuários para nosso servidor. O segundo maior benefício de vender o Viaweb para o Yahoo (depois do dinheiro) foi poder despejar a responsabilidade final por tudo isso nas costas de uma grande empresa.
Software de desktop força os usuários a se tornarem administradores de sistemas. Software baseado na Web força os programadores a isso. Há menos estresse no total, mas mais para os programadores. Isso não é necessariamente uma má notícia. Se você é uma startup competindo com uma grande empresa, é uma boa notícia. [15] Aplicações baseadas na Web oferecem uma maneira direta de trabalhar mais do que seus concorrentes. Nenhuma startup pede mais.
Apenas Bom o Suficiente
Uma coisa que pode desencorajá-lo a escrever aplicações baseadas na Web é a fraqueza das páginas da Web como uma interface de usuário. Isso é um problema, admito. Havia algumas coisas que realmente gostaríamos de adicionar ao HTML e ao HTTP. O que importa, no entanto, é que as páginas da Web são apenas boas o suficiente.
Há um paralelo aqui com os primeiros microcomputadores. Os processadores nessas máquinas não foram realmente projetados para serem as CPUs dos computadores. Eles foram projetados para serem usados em coisas como semáforos. Mas caras como Ed Roberts, que projetou o Altair, perceberam que eram apenas bons o suficiente. Você poderia combinar um desses chips com alguma memória (256 bytes no primeiro Altair) e interruptores no painel frontal, e teria um computador funcionando. Poder ter seu próprio computador era tão empolgante que havia muitas pessoas que queriam comprá-los, por mais limitados que fossem.
As páginas da Web não foram projetadas para serem uma interface de usuário para aplicações, mas são apenas boas o suficiente. E para um número significativo de usuários, software que você pode usar de qualquer navegador será uma vitória suficiente em si para superar qualquer awkwardness na interface do usuário. Talvez você não consiga escrever a planilha mais bonita usando HTML, mas pode escrever uma planilha que várias pessoas possam usar simultaneamente de diferentes locais sem software cliente especial, ou que possa incorporar feeds de dados ao vivo, ou que possa te avisar quando certas condições forem acionadas. Mais importante, você pode escrever novos tipos de aplicações que ainda não têm nomes. O VisiCalc não era apenas uma versão de microcomputador de uma aplicação de mainframe, afinal—era um novo tipo de aplicação.
Claro, aplicações baseadas em servidor não precisam ser baseadas na Web. Você poderia ter algum outro tipo de cliente. Mas tenho certeza de que isso é uma má ideia. Seria muito conveniente se você pudesse assumir que todos instalariam seu cliente—tão conveniente que você poderia facilmente se convencer de que todos o fariam—mas se não o fizerem, você está ferrado. Porque software baseado na Web não assume nada sobre o cliente, funcionará em qualquer lugar que a Web funcione. Essa já é uma grande vantagem, e a vantagem crescerá à medida que novos dispositivos Web proliferarem. Os usuários gostarão de você porque seu software simplesmente funciona, e sua vida será mais fácil porque você não terá que ajustá-lo para cada novo cliente. [16]
Sinto que assisti à evolução da Web tão de perto quanto qualquer um, e não posso prever o que acontecerá com os clientes. A convergência provavelmente está chegando, mas onde? Não consigo escolher um vencedor. Uma coisa que posso prever é conflito entre AOL e Microsoft. Seja o que for que o .NET da Microsoft se torne, provavelmente envolverá conectar a área de trabalho a servidores. A menos que a AOL reaja, eles serão empurrados para o lado ou transformados em um tubo entre o software cliente e servidor da Microsoft. Se a Microsoft e a AOL entrarem em uma guerra de clientes, a única coisa que certamente funcionará em ambas será navegar na Web, significando que aplicações baseadas na Web serão o único tipo que funcionará em todos os lugares.
Como tudo isso se desenrolará? Não sei. E você não precisa saber se apostar em aplicações baseadas na Web. Ninguém pode quebrar isso sem quebrar a navegação. A Web pode não ser a única maneira de entregar software, mas é uma que funciona agora e continuará a funcionar por muito tempo. Aplicações baseadas na Web são baratas de desenvolver e fáceis para até mesmo a menor startup entregar. Elas exigem muito trabalho, e de um tipo particularmente estressante, mas isso apenas melhora as chances para as startups.
Por Que Não?
E. B. White ficou divertido ao saber de um amigo fazendeiro que muitas cercas eletrificadas não têm corrente passando por elas. As vacas aparentemente aprendem a ficar longe delas, e depois disso você não precisa da corrente. "Levantem-se, vacas!" ele escreveu, "Tomem sua liberdade enquanto os déspotas roncam!"
Se você é um hacker que já pensou em um dia começar uma startup, provavelmente há duas coisas que o impedem de fazê-lo. Uma é que você não sabe nada sobre negócios. A outra é que você tem medo da concorrência. Nenhuma dessas cercas tem corrente.
Há apenas duas coisas que você precisa saber sobre negócios: construa algo que os usuários amem e gaste menos do que ganha. Se você acertar essas duas, estará à frente da maioria das startups. Você pode descobrir o resto ao longo do caminho.
Você pode não fazer mais do que gasta a princípio, mas enquanto a diferença estiver diminuindo rápido o suficiente, você estará bem. Se você começar subfinanciado, isso pelo menos incentivará um hábito de frugalidade. Quanto menos você gastar, mais fácil será ganhar mais do que gasta. Felizmente, pode ser muito barato lançar uma aplicação baseada na Web. Nós lançamos com menos de $10.000, e seria ainda mais barato hoje. Tivemos que gastar milhares em um servidor e milhares mais para obter SSL. (A única empresa vendendo software SSL na época era a Netscape.) Agora você pode alugar um servidor muito mais poderoso, com SSL incluído, por menos do que pagamos apenas pela largura de banda. Você poderia lançar uma aplicação baseada na Web agora por menos do que o custo de uma cadeira de escritório chique.
Quanto a construir algo que os usuários amem, aqui estão algumas dicas gerais. Comece fazendo algo limpo e simples que você mesmo gostaria de usar. Lance uma versão 1.0 rapidamente, depois continue a melhorar o software, ouvindo atentamente os usuários enquanto faz isso. O cliente está sempre certo, mas clientes diferentes estão certos sobre coisas diferentes; os usuários menos sofisticados mostram o que você precisa simplificar e esclarecer, e os mais sofisticados dizem quais recursos você precisa adicionar. A melhor coisa que o software pode ser é fácil, mas a maneira de fazer isso é acertar os padrões, não limitar as escolhas dos usuários. Não fique complacente se o software de seus concorrentes for fraco; o padrão para comparar seu software é o que ele poderia ser, não o que seus concorrentes atuais têm. Use seu software você mesmo, o tempo todo. O Viaweb deveria ser um construtor de lojas online, mas nós o usamos para fazer nosso próprio site também. Não ouça pessoas de marketing ou designers ou gerentes de produto apenas por causa de seus títulos de trabalho. Se eles tiverem boas ideias, use-as, mas cabe a você decidir; o software deve ser projetado por hackers que entendem design, não por designers que sabem um pouco sobre software. Se você não consegue projetar software tão bem quanto implementá-lo, não comece uma startup.
Agora vamos falar sobre concorrência. O que você teme não são presumivelmente grupos de hackers como você, mas empresas reais, com escritórios e planos de negócios e vendedores e assim por diante, certo? Bem, eles têm mais medo de você do que você deles, e eles estão certos. É muito mais fácil para um casal de hackers descobrir como alugar espaço de escritório ou contratar vendedores do que para uma empresa de qualquer tamanho conseguir que o software seja escrito. Estive dos dois lados, e sei. Quando o Viaweb foi comprado pelo Yahoo, de repente me vi trabalhando para uma grande empresa, e foi como tentar correr através de água na altura da cintura.
Não quero menosprezar o Yahoo. Eles tinham alguns bons hackers, e a alta administração era realmente eficaz. Para uma grande empresa, eles eram excepcionais. Mas ainda eram apenas cerca de um décimo tão produtivos quanto uma pequena startup. Nenhuma grande empresa pode fazer muito melhor do que isso. O que é assustador sobre a Microsoft é que uma empresa tão grande pode desenvolver software. Eles são como uma montanha que pode andar.
Não se intimide. Você pode fazer tanto que a Microsoft não pode quanto eles podem fazer que você não pode. E ninguém pode te parar. Você não precisa pedir permissão a ninguém para desenvolver aplicações baseadas na Web. Você não precisa fazer acordos de licenciamento, ou conseguir espaço nas prateleiras em lojas de varejo, ou se humilhar para ter sua aplicação incluída com o sistema operacional. Você pode entregar software diretamente ao navegador, e ninguém pode se colocar entre você e os usuários potenciais sem impedir que eles naveguem na Web.
Você pode não acreditar, mas prometo que a Microsoft está com medo de você. Os gerentes de médio escalão complacentes podem não estar, mas Bill está, porque ele já foi você uma vez, em 1975, a última vez que uma nova maneira de entregar software apareceu.
Notas
[1] Percebendo que muito do dinheiro está nos serviços, empresas que constroem clientes leves geralmente tentaram combinar o hardware com um serviço online. Essa abordagem não funcionou bem, em parte porque você precisa de dois tipos diferentes de empresas para construir eletrônicos de consumo e para rodar um serviço online, e em parte porque os usuários odeiam a ideia. Dar a lâmina de graça e ganhar dinheiro com as lâminas pode funcionar para a Gillette, mas uma lâmina é um compromisso muito menor do que um terminal Web. Fabricantes de celulares estão satisfeitos em vender hardware sem tentar capturar a receita do serviço também. Esse provavelmente deveria ser o modelo para clientes da Internet também. Se alguém simplesmente vendesse uma caixinha bonitinha com um navegador Web que você pudesse usar para se conectar através de qualquer ISP, todos os tecnofóbicos do país comprariam uma.
[2] A segurança sempre depende mais de não errar do que de qualquer decisão de design, mas a natureza do software baseado em servidor fará com que os desenvolvedores prestem mais atenção para não errar. Comprometer um servidor poderia causar danos tão grandes que ASPs (que querem continuar no negócio) provavelmente serão cuidadosos com a segurança.
[3] Em 1995, quando começamos o Viaweb, applets Java deveriam ser a tecnologia que todos usariam para desenvolver aplicações baseadas em servidor. Applets nos pareciam uma ideia antiquada. Baixar programas para rodar no cliente? Mais simples ir até o fim e rodar os programas no servidor. Perdemos pouco tempo com applets, mas incontáveis outras startups devem ter sido atraídas para esse atoleiro. Poucas conseguiram escapar vivas, ou a Microsoft não teria conseguido se safar ao deixar o Java na versão mais recente do Explorer.
[4] Este ponto é devido a Trevor Blackwell, que acrescenta "o custo de escrever software aumenta mais do que linearmente com seu tamanho. Talvez isso se deva principalmente a consertar bugs antigos, e o custo pode ser mais linear se todos os bugs forem encontrados rapidamente."
[5] O tipo mais difícil de bug a ser encontrado pode ser uma variante de bug composto onde um bug acaba compensando outro. Quando você conserta um bug, o outro se torna visível. Mas parecerá que a correção é a culpada, já que essa foi a última coisa que você mudou.
[6] Dentro do Viaweb, uma vez tivemos um concurso para descrever a pior coisa sobre nosso software. Duas pessoas de suporte ao cliente empataram em primeiro lugar com entradas que ainda me fazem tremer ao recordar. Corrigimos ambos os problemas imediatamente.
[7] Robert Morris escreveu o sistema de pedidos, que os compradores usavam para fazer pedidos. Trevor Blackwell escreveu o gerador de imagens e o gerenciador, que os comerciantes usavam para recuperar pedidos, visualizar estatísticas e configurar nomes de domínio, etc. Eu escrevi o editor, que os comerciantes usavam para construir seus sites. O sistema de pedidos e o gerador de imagens foram escritos em C e C++, o gerenciador principalmente em Perl, e o editor em Lisp.
[8] A discriminação de preços é tão abrangente (com que frequência você ouviu um varejista afirmar que seu poder de compra significava preços mais baixos para você?) que fiquei surpreso ao descobrir que era ilegal nos EUA pela Lei Robinson-Patman de 1936. Essa lei não parece ser rigorosamente aplicada.
[9] Em No Logo, Naomi Klein diz que marcas de roupas favorecidas por "jovens urbanos" não tentam muito evitar o furto, porque em seu mercado-alvo os ladrões também são os líderes de moda.
[10] As empresas costumam se perguntar o que terceirizar e o que não terceirizar. Uma possível resposta: terceirize qualquer trabalho que não esteja diretamente exposto à pressão competitiva, porque terceirizá-lo o exporá à pressão competitiva.
[11] Os dois caras eram Dan Bricklin e Bob Frankston. Dan escreveu um protótipo em Basic em alguns dias, e depois, ao longo do ano seguinte, eles trabalharam juntos (principalmente à noite) para fazer uma versão mais poderosa escrita em linguagem de máquina 6502. Dan estava na Harvard Business School na época e Bob nominalmente tinha um emprego diurno escrevendo software. "Não havia grande risco em fazer um negócio," Bob escreveu, "Se falhasse, falhou. Sem problemas."
[12] Não é tão fácil quanto faço parecer. Levou um tempo dolorosamente longo para o boca a boca começar, e não começamos a receber muita cobertura da imprensa até contratarmos uma empresa de relações públicas (admitidamente a melhor do ramo) por $16.000 por mês. No entanto, era verdade que o único canal significativo era nosso próprio site.
[13] Se o Mac era tão ótimo, por que perdeu? Custo, novamente. A Microsoft concentrou-se no negócio de software e liberou um enxame de fornecedores de componentes baratos sobre o hardware da Apple. Também não ajudou que executivos assumissem durante um período crítico.
[14] Uma coisa que ajudaria aplicações baseadas na Web, e ajudaria a manter a próxima geração de software de ser ofuscada pela Microsoft, seria um bom navegador de código aberto. O Mozilla é de código aberto, mas parece ter sofrido por ter sido software corporativo por tanto tempo. Um navegador pequeno e rápido que fosse mantido ativamente seria uma grande coisa em si, e provavelmente também encorajaria empresas a construir pequenos aparelhos Web.
Entre outras coisas, um navegador de código aberto adequado faria com que HTTP e HTML continuassem a evoluir (como por exemplo o Perl fez). Ajudaria muito aplicações baseadas na Web poder distinguir entre selecionar um link e segui-lo; tudo o que você precisaria para isso seria uma melhoria trivial do HTTP, para permitir múltiplos URLs em uma solicitação. Menus em cascata também seriam bons.
Se você quer mudar o mundo, escreva um novo Mosaic. Acha que é tarde demais? Em 1998, muitas pessoas achavam que era tarde demais para lançar um novo motor de busca, mas o Google provou que estavam erradas. Sempre há espaço para algo novo se as opções atuais forem ruins o suficiente. Certifique-se de que funcione em todos os sistemas operacionais gratuitos primeiro—novas coisas começam com seus usuários.
[15] Trevor Blackwell, que provavelmente sabe mais sobre isso por experiência pessoal do que qualquer um, escreve:
"Eu iria mais longe ao dizer que, porque software baseado em servidor é tão difícil para os programadores, causa uma mudança econômica fundamental para longe de grandes empresas. Exige o tipo de intensidade e dedicação dos programadores que eles só estarão dispostos a fornecer quando for sua própria empresa. Empresas de software podem contratar pessoas habilidosas para trabalhar em um ambiente não muito exigente, e podem contratar pessoas não habilidosas para suportar dificuldades, mas não podem contratar pessoas altamente habilidosas para se esforçarem. Como o capital não é mais necessário, grandes empresas têm pouco a trazer para a mesa."
[16] Na versão original deste ensaio, eu aconselhei a evitar Javascript. Esse era um bom plano em 2001, mas o Javascript agora funciona.
Agradecimentos a Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson e Dan Giffin por lerem rascunhos deste artigo; a Dan Bricklin e Bob Frankston por informações sobre o VisiCalc; e novamente a Ken Anderson por me convidar a falar no BBN.
Você encontrará este ensaio e outros 14 em Hackers & Painters.