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 RP que levou ao IPO da Netscape estava a todo vapor na época, e havia muita conversa na imprensa sobre comércio online. Na época, talvez houvesse trinta lojas reais na Web, todas feitas à mão. Se houvesse muitas lojas online, seria necessário um software para fazê-las, então decidimos escrever algumas.
Durante a primeira semana ou mais, 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 uma interface. Tentamos reescrever o software para funcionar na 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 acabou sendo um bom plano. Agora, como Yahoo Store , esse software é o construtor de loja online mais popular, com cerca de 14.000 usuários.
Quando começamos a Viaweb, quase ninguém entendeu o que queríamos dizer quando dissemos que o software rodava no servidor. Foi só quando o Hotmail foi lançado um ano depois que as pessoas começaram a entender. Agora, todo mundo sabe que essa é uma abordagem válida. Agora há um nome para o que éramos: um Application Service Provider, ou ASP.
Acho que muito da próxima geração de software será escrito neste modelo. Até mesmo a Microsoft, que tem mais a perder, parece ver a inevitabilidade de mover algumas coisas do desktop. Se o software sair do desktop e for 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 realmente se move para os servidores, o que estou descrevendo aqui é o futuro.
O próximo passo?
Quando olhamos para a era do software de desktop, acho que ficaremos maravilhados com as inconveniências que as pessoas toleravam, assim como nos maravilhamos agora com o que os primeiros donos de carros toleravam. Nos primeiros vinte ou trinta anos, você tinha que ser um especialista em carros para ter um carro. Mas os carros foram uma vitória tão grande que muitas pessoas que não eram especialistas em carros também queriam tê-los.
Os computadores estão nessa fase agora. Quando você tem um computador de mesa, acaba aprendendo muito mais do que queria saber sobre o que está acontecendo dentro dele. Mas mais da metade dos lares nos EUA tem um. Minha mãe tem um computador que ela usa para e-mail e para manter contas. Cerca de um ano atrás, ela ficou alarmada ao receber uma carta da Apple, oferecendo-lhe um desconto em uma nova versão do sistema operacional. Há algo errado quando uma mulher de 65 anos que quer usar um computador para e-mail e contas tem que pensar em instalar novos sistemas operacionais. Usuários comuns nem deveriam conhecer 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 terá que pensar em nada, exceto nos aplicativos que usam. Todas as coisas confusas e mutáveis ficarão em um servidor em algum lugar, mantidas pelo tipo de pessoa que é boa nesse tipo de coisa. E então você normalmente não precisará de um computador, por si só, para usar 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 telefone celular. Seja o que for, será um eletrônico de consumo: algo que custa cerca de US$ 200 e que as pessoas escolhem principalmente com base na aparência do gabinete. 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 ir até o servidor e voltar, então usuários de softwares altamente interativos, como o Photoshop, ainda vão querer que os cálculos aconteçam no desktop. Mas se você olhar para o tipo de coisa para a qual 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 mesa, e há muitas pessoas como ela.
A vitória para os usuários
Perto da minha casa há um carro com um adesivo no para-choque que diz "morte antes da inconveniência". A maioria das pessoas, na maioria das vezes, escolherá qualquer opção que exija 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. Então você pode usar um aplicativo baseado na Web em qualquer lugar. Quando você instala um software no seu computador desktop, você só pode usá-lo naquele computador. Pior ainda, seus arquivos ficam presos naquele computador. A inconveniência desse modelo se torna cada vez mais evidente à medida que as pessoas se acostumam com as redes.
A ponta fina da cunha aqui era 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 deveria ficar preso em algum computador em uma mesa distante?
Toda a ideia de "seu computador" está indo embora, e sendo substituída por "seus dados". Você deve conseguir obter seus dados de qualquer computador. Ou melhor, de 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 conforme os clientes ficam menores, você tem outro motivo para não manter seus dados com eles: algo que você carrega consigo pode ser perdido ou roubado. Deixar seu PDA em um táxi é como uma pane de disco, exceto que seus dados são entregues a outra pessoa em vez de serem vaporizados.
Com software puramente baseado na Web, nem seus dados nem os aplicativos são mantidos no cliente. Então 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 indo ao site onde ele é oferecido. Na Viaweb, todo o nosso site era como uma grande seta apontando os usuários para o test drive.
Depois de experimentar a demonstração, inscrever-se no serviço não deve exigir nada mais do que preencher um breve formulário (quanto mais breve, melhor). E esse deve ser o último trabalho que o usuário tem que fazer. Com software baseado na Web, você deve obter novos lançamentos sem pagar a mais, ou fazer qualquer trabalho, ou possivelmente nem mesmo saber sobre isso.
As atualizações não serão os grandes choques que são agora. Com o tempo, os aplicativos ficarão silenciosamente mais poderosos. Isso exigirá algum esforço por parte dos desenvolvedores. Eles terão que projetar o software para que ele possa ser atualizado sem confundir os usuários. Esse é um problema novo, 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 descobertos. Então, o software baseado na Web deve ter muito menos bugs do que o software de desktop. Na Viaweb, duvido que já tenhamos tido dez bugs conhecidos ao mesmo tempo. 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. Esta é uma vitória óbvia para aplicativos colaborativos, mas aposto que os usuários começarão a querer isso na maioria dos aplicativos quando perceberem que é possível. Muitas vezes será útil deixar duas pessoas editarem o mesmo documento, por exemplo. A Viaweb deixou vários usuários editarem 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 o fizeram.
Quando você usa um aplicativo baseado na Web, seus dados estarão mais seguros. Falhas de disco não serão uma 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 se preocupando com essas coisas, mas porque um ASP que perde 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 elas só têm a si mesmas para ficarem bravas. Quando uma empresa perde seus dados para elas, 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 executar nada, exceto um navegador, há menos chance de executar vírus e nenhum dado local para danificar. E um programa que atacou os próprios servidores deve encontrá-los muito bem defendidos. [2]
Para os usuários, o software baseado na Web será menos estressante. Acho que se você olhasse para dentro do usuário médio do Windows, encontraria um desejo enorme e praticamente inexplorado por software que atendesse a essa descrição. Liberado, ele poderia ser uma força poderosa.
Cidade do Código
Para os desenvolvedores, a diferença mais notável 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 então projetar software baseado na Web é como projetar uma cidade em vez de um edifício: assim como edifícios, você precisa de estradas, placas de rua, serviços públicos, departamentos de polícia e bombeiros, e planos para crescimento e vários tipos de desastres.
Na Viaweb, o software incluía aplicativos bem grandes com os quais os usuários conversavam diretamente, programas que esses programas usavam, programas que rodavam constantemente em segundo plano procurando por problemas, programas que tentavam reiniciar as coisas se quebrassem, programas que rodavam ocasionalmente para compilar estatísticas ou criar índices para pesquisas, programas que rodamos explicitamente para coletar lixo de recursos ou para mover ou restaurar dados, programas que fingiam ser usuários (para medir o desempenho ou expor bugs), programas para diagnosticar problemas de rede, programas para fazer backups, interfaces para serviços externos, software que dirigia uma coleção impressionante de mostradores exibindo estatísticas de servidor em tempo real (um sucesso entre os visitantes, mas indispensável para nós também), modificações (incluindo correções de bugs) em software de código aberto e muitos arquivos de configuração e definições. Trevor Blackwell escreveu um programa espetacular para mover lojas para novos servidores em todo o país, sem desligá-los, depois que fomos comprados pelo Yahoo. Programas nos pageavam, enviavam faxes e e-mails para usuários, conduziam transações com processadores de cartão de crédito e conversavam entre si por meio de sockets, pipes, solicitações http, ssh, pacotes udp, memória compartilhada e arquivos. Alguns da Viaweb até consistiam na ausência de programas, já que uma das chaves para a segurança do Unix é não executar utilitários desnecessários que as pessoas podem usar para invadir seus servidores.
Não terminou com o software. Passamos muito tempo pensando sobre as configurações do servidor. Nós mesmos construímos os servidores, 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 para todos os backbones. Nós datamos em série os fornecedores de RAID.
Mas hardware não é algo com que se preocupar apenas. Quando você o controla, pode fazer mais pelos usuários. Com um aplicativo de desktop, você pode especificar um hardware mínimo, mas não pode adicionar mais. Se você administra os servidores, pode, em uma etapa, habilitar todos os seus usuários a enviar mensagens de pager, fax, comandos por telefone, processar cartões de crédito, etc., apenas instalando o hardware relevante. Sempre buscamos novas maneiras de adicionar recursos com hardware, não apenas porque isso agradava aos usuários, mas também como uma maneira de nos distinguir dos concorrentes que (seja porque vendiam software de desktop ou revendiam aplicativos baseados na Web por meio 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, você é praticamente forçado a escrever o aplicativo na mesma linguagem do sistema operacional subjacente — ou seja, C e C++. E então essas linguagens (especialmente entre pessoas não técnicas como gerentes e VCs) passaram a ser consideradas como 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 principais 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 tirar vantagem dessa possibilidade, seus concorrentes tirarão.
A maioria dos nossos concorrentes usava C e C++, e isso tornava o software deles visivelmente inferior porque (entre outras coisas), eles não tinham como contornar a ausência de estado dos scripts CGI. Se você fosse mudar alguma coisa, todas as mudanças tinham que acontecer em uma página, com um botão Atualizar na parte inferior. Como escrevi em outro lugar, usando Lisp , que muitas pessoas ainda consideram uma linguagem de pesquisa, poderíamos fazer o editor Viaweb se comportar mais como um 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 para desktop, fazer um lançamento é um trauma enorme, 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 alterações quase como faria em um programa que você estivesse escrevendo para si mesmo. Você libera o software como uma série de alterações incrementais em vez de uma grande explosão ocasional. Uma empresa típica 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 forma como ele é lançado. Muitos dos problemas mais desagradáveis que você vê no negócio de software para desktop são devidos à natureza catastrófica dos lançamentos.
Quando você lança apenas uma nova versão por ano, você tende a lidar com bugs no atacado. Algum tempo antes da data de lançamento, você monta uma nova versão na qual metade do código foi arrancado e substituído, introduzindo inúmeros bugs. Então, um esquadrão de pessoas de QA entra e começa a contá-los, e os programadores trabalham na lista, corrigindo-os. Eles geralmente não chegam ao fim da lista e, de fato, ninguém tem certeza de onde é o fim. É como pescar entulho de um lago. Você nunca sabe realmente o que está acontecendo dentro do software. Na melhor das hipóteses, você acaba com um tipo de correção estatística.
Com software baseado em servidor, a maioria das mudanças é pequena e incremental. Isso por si só é menos provável de introduzir bugs. Isso também significa que você sabe o que testar com mais cuidado quando estiver prestes a lançar um software: a última coisa que você mudou. Você acaba com 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 você lê o código-fonte, você 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 mais alguns? Logo você estará lançando recursos inteiros que sabe que estão quebrados. A 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 alguns dos softwares (suporte para CDs e DVDs) não estavam prontos. 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 um software antes que ele funcione, e pode lançá-lo assim que ele começar a funcionar.
O veterano da indústria pode estar pensando, é uma ideia que soa bem dizer que você nunca precisa lançar um software antes que ele 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 gradual e continuamente. Algumas mudanças podem ser maiores do que outras, mas a ideia de versões simplesmente não se encaixa naturalmente em software baseado na Web.
Se alguém se lembra da Viaweb, isso pode soar estranho, porque estávamos sempre anunciando novas versões. Isso era feito inteiramente para fins de RP. A imprensa especializada, descobrimos, pensa em números de versão. Eles darão a você uma grande cobertura para um lançamento importante, o que significa um novo primeiro dígito no número da versão, e geralmente um parágrafo no máximo para um lançamento pontual, o que significa um novo dígito após o ponto decimal.
Alguns dos nossos concorrentes estavam oferecendo software de desktop e realmente tinham números de versão. E para esses lançamentos, o simples fato de que nos parecia evidência de seu atraso, eles recebiam todos os tipos de publicidade. Não queríamos perder, então começamos a dar números de versão para o nosso software também. Quando queríamos alguma publicidade, fazíamos uma lista de todos os recursos que adicionamos desde o último "lançamento", colocávamos um novo número de versão no software e emitimos um press release dizendo que a nova versão estava disponível imediatamente. Surpreendentemente, ninguém nunca nos chamou a atenção.
Quando fomos comprados, tínhamos feito isso três vezes, então estávamos na Versão 4. Versão 4.1, se bem me lembro. 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.
Insetos
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 quebrar seu software, você não precisa tentar adivinhar o que está acontecendo, como faria com o software de desktop: você deve ser capaz de reproduzir o erro enquanto eles estão no telefone com você. Você pode até saber sobre isso já, se tiver código para notar erros incorporado ao seu aplicativo.
Software baseado na Web é usado 24 horas por dia, então tudo o que você faz é imediatamente colocado no espremedor. Bugs aparecem rapidamente.
Às vezes, as empresas de software são acusadas de deixar os usuários depurarem seus softwares. E é exatamente isso que estou defendendo. Para software baseado na Web, na verdade é um bom plano, porque os bugs são menores e transitórios. Quando você libera software gradualmente, você tem muito menos bugs para começar. E quando você pode reproduzir erros e liberar alterações instantaneamente, você pode encontrar e corrigir a maioria dos bugs assim que eles aparecem. Nunca tivemos bugs suficientes em um momento para nos preocuparmos com um sistema formal de rastreamento de bugs.
Você deve testar as mudanças antes de liberá-las, é claro, para que nenhum bug importante seja liberado. Aqueles poucos que inevitavelmente passarem despercebidos envolverão casos limítrofes e afetarão apenas os poucos usuários que os encontrarem antes que alguém ligue para reclamar. Contanto 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 já tenha visto um bug.
Corrigir bugs novos é mais fácil do que corrigir os antigos. Geralmente é bem rápido encontrar um bug no código que você acabou de escrever. Quando ele aparece, você geralmente sabe o que está errado antes mesmo de olhar a fonte, porque você já estava se preocupando com isso inconscientemente. Corrigir um bug em algo que você escreveu há seis meses (o caso médio se você lança uma vez por ano) dá muito mais trabalho. E como você não entende o código tão bem, é mais provável que você o conserte de uma forma feia, ou até mesmo introduza mais bugs. [4]
Quando você pega os bugs cedo, você também tem menos bugs compostos. Bugs compostos são dois bugs separados que interagem: você tropeça ao descer as escadas, e quando você alcança o corrimão ele sai 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 então filtrar os bugs" inerentemente produz muitos bugs compostos. E software que é lançado em uma série de pequenas mudanças inerentemente tende a não fazê-lo. Os pisos estão constantemente sendo varridos para limpar quaisquer objetos soltos que possam mais tarde ficar presos em alguma coisa.
Ajuda se você usar uma técnica chamada programação funcional. Programação funcional significa evitar efeitos colaterais. É algo que você provavelmente verá mais 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 pedaços substanciais dessa forma. Isso torna essas partes do seu software mais fáceis de testar, porque elas não têm estado, e isso é muito conveniente em uma situação em que você está constantemente fazendo e testando pequenas modificações. Eu escrevi muito do editor da Viaweb nesse estilo, e nós fizemos nossa linguagem de script, RTML , uma linguagem puramente funcional.
Pessoas do ramo de software para desktop acharão isso difícil de acreditar, mas na Viaweb os bugs se tornaram quase um jogo. Como a maioria dos bugs lançados envolvia casos limítrofes, os usuários que os encontravam provavelmente eram usuários avançados, forçando os limites. Usuários avançados são mais tolerantes com bugs, especialmente porque você provavelmente os introduziu no curso da adição de algum recurso que eles estavam pedindo. Na verdade, como os bugs eram raros e você tinha que estar fazendo coisas sofisticadas para vê-los, os usuários avançados geralmente ficavam 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 conosco.
Apoiar
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 ambos os casos, não há muito que você possa aprender com eles. E então você tende a ver as chamadas de suporte como uma dor de cabeça que você quer 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 imediatamente para que pudéssemos reproduzir o erro e lançar uma correção.
Então, na Viaweb, os desenvolvedores estavam sempre em contato próximo com o suporte. O pessoal do suporte ao cliente estava a cerca de trinta pés de distância dos programadores e sabia que eles sempre poderiam interromper qualquer coisa com um relato de um bug genuíno. Nós saíamos de uma reunião do conselho para consertar um bug sério.
Nossa abordagem de suporte deixou todos mais felizes. Os clientes ficaram encantados. Imagine como seria ligar para uma linha de suporte e ser tratado como alguém trazendo notícias importantes. O pessoal de suporte ao cliente gostou porque significava que eles podiam ajudar os usuários, em vez de ler scripts para eles. E os programadores gostaram porque podiam reproduzir bugs em vez de apenas ouvir relatos vagos de segunda mão sobre eles.
Nossa política de consertar bugs na hora mudou o relacionamento entre o pessoal de suporte ao cliente e os hackers. Na maioria das empresas de software, o pessoal de suporte é um escudo humano mal pago, 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: o pessoal de suporte que ouve sobre bugs preenche algum formulário que eventualmente é repassado (possivelmente via QA) para os programadores, que o colocam em sua lista de coisas a fazer. Era muito diferente na Viaweb. Em um minuto após ouvir sobre um bug de um cliente, o pessoal de suporte podia estar ao lado de um programador ouvindo-o dizer "Merda, você está certo, é um bug". O pessoal de suporte ficava feliz em ouvir esse "você está certo" dos hackers. Eles costumavam nos trazer bugs com o mesmo ar de expectativa de um gato trazendo um rato que acabou de matar. Isso também os tornava mais cuidadosos ao julgar a seriedade de um bug, porque agora sua honra estava em jogo.
Depois que fomos comprados pelo Yahoo, o pessoal de suporte ao cliente foi movido para longe dos programadores. Foi só então que percebemos que eles eram efetivamente QA e, até certo ponto, marketing também. Além de capturar bugs, eles eram os guardiões do conhecimento de coisas mais vagas, parecidas com bugs, como recursos que confundiam os usuários. [6] Eles também eram uma espécie de grupo focal proxy; podíamos perguntar a eles qual dos dois novos recursos os usuários queriam mais, e eles sempre estavam certos.
Moral
Ser capaz de lançar software imediatamente é um grande motivador. Muitas vezes, enquanto eu caminhava para o trabalho, eu pensava em alguma mudança que queria fazer no software e fazia isso naquele dia. Isso funcionava para recursos maiores também. Mesmo se algo levasse duas semanas para ser escrito (poucos projetos demoravam 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, eu teria arquivado a maioria dessas ideias, pelo menos por um tempo. A questão sobre ideias, no entanto, é que elas levam a mais ideias. Você já percebeu que quando você se senta para escrever algo, metade das ideias que acabam nele são aquelas que você pensou enquanto escrevia? A mesma coisa acontece com software. Trabalhar para implementar uma ideia lhe dá mais ideias. Então arquivar uma ideia custa a você não apenas aquele atraso na implementação, mas também todas as ideias que a implementação dela teria levado. Na verdade, arquivar uma ideia provavelmente até inibe novas ideias: quando 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 é planejá-los. Na Viaweb, às vezes, tivemos problemas por conta disso. Investidores e analistas nos perguntavam o que tínhamos planejado para o futuro. A resposta verdadeira seria: 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 faríamos 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, nós as implementávamos.
Na Viaweb, como em muitas empresas de software, a maioria dos códigos tinha um dono definido. Mas quando você possuía algo, você realmente o possuía: ninguém, exceto o dono de um pedaço de software, tinha que aprovar (ou mesmo saber sobre) um lançamento. Não havia proteção contra quebra, exceto o medo de parecer um idiota para os colegas, e isso era mais do que suficiente. Posso ter dado a impressão de que apenas avançamos alegremente escrevendo código. Nós fomos rápidos, mas pensamos muito cuidadosamente antes de lançar software nesses servidores. E prestar atenção é mais importante para a confiabilidade do que se mover lentamente. Como ele presta muita atenção, um piloto da Marinha pode pousar uma aeronave de 40.000 libras a 140 milhas por hora em um convés de porta-aviões inclinado, à noite, com mais segurança do que um adolescente médio pode cortar um bagel.
Essa maneira de escrever software é uma faca de dois gumes, é claro. Funciona muito melhor para uma pequena equipe de bons e confiáveis programadores do que para uma grande empresa de medíocres, onde ideias ruins são capturadas por comitês em vez das pessoas que as tiveram.
Brooks ao contrário
Felizmente, o software baseado na Web requer menos programadores. Eu já 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. Todo o resto estava trabalhando em lançamentos, ports e assim por diante. Com o software baseado na Web, tudo o que você precisa (no máximo) são as 13 pessoas, porque não há lançamentos, ports e assim por diante.
O Viaweb foi escrito 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 passarão em reuniões negociando como seus softwares funcionarão juntos, e mais bugs eles terão de interações imprevistas. Felizmente, esse processo também funciona ao contrário: conforme os grupos ficam menores, o desenvolvimento de software se torna exponencialmente mais eficiente. Não me lembro dos programadores da Viaweb terem tido uma reunião real. Nunca tivemos mais a dizer em um momento do que poderíamos dizer enquanto caminhávamos para o almoço.
Se há uma desvantagem aqui, é que todos os programadores têm que ser, em algum grau, administradores de sistema também. Quando você está hospedando software, alguém tem que 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 estaria 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, desde que você ainda esteja desenvolvendo ativamente o produto. Software baseado na Web nunca será algo que você escreve, verifica e vai para casa. É algo vivo, rodando em seus servidores agora mesmo. Um bug ruim pode não travar apenas o processo de um usuário; pode travar todos eles. Se um bug no seu código corrompe alguns dados no disco, você tem que consertá-lo. E assim por diante. Descobrimos que você não precisa monitorar os servidores a cada minuto (após o primeiro ano ou mais), mas você definitivamente quer ficar de olho nas coisas que você mudou recentemente. Você não libera código tarde da noite e depois vai para casa.
Observando 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 até suas casas. Se você já viu alguém usar seu software pela primeira vez, sabe que surpresas devem tê-los esperado.
O software deve fazer o que os usuários pensam que ele fará. Mas você não pode ter ideia do que os usuários estarão pensando, acredite em mim, até observá-los. E o software baseado em servidor fornece informações sem precedentes sobre o comportamento deles. Você não está limitado a pequenos grupos de foco artificiais. Você pode ver cada clique feito por cada usuário. Você tem que considerar cuidadosamente o que vai ver, porque não quer violar a privacidade dos usuários, mas mesmo a amostragem estatística mais geral pode ser muito útil.
Quando você tem os usuários no seu servidor, não precisa depender de benchmarks, por exemplo. Benchmarks são usuários simulados. Com software baseado em servidor, você pode observar usuários reais. Para decidir o que otimizar, basta fazer login em um servidor e ver o que está consumindo toda a CPU. E você sabe quando parar de otimizar também: eventualmente, conseguimos que o editor Viaweb chegasse ao ponto em que ele era limitado pela memória em vez de limitado 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 muito bem parar por aí.
A eficiência importa para software baseado em servidor, porque você está pagando pelo hardware. O número de usuários que você pode suportar por servidor é o divisor do seu custo de capital, então se você puder tornar seu software muito eficiente, você pode vender mais barato que os concorrentes e ainda ter lucro. Na Viaweb, reduzimos o custo de capital por usuário para cerca de US$ 5. Seria menos agora, provavelmente menos do que o custo de enviar a eles a conta do primeiro mês. O hardware é gratuito agora, se seu software for razoavelmente eficiente.
Observar os usuários pode orientá-lo no design e 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 um tipo de caixa de sugestões, porque os usuários só o usavam quando os estilos de página predefinidos não conseguiam fazer o que 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 no lado esquerdo, tornamos isso uma opção (na verdade, o padrão) nos estilos de página predefinidos.
Por fim, ao observar os usuários, você pode frequentemente dizer quando eles estão com problemas. E como o cliente sempre tem razão, isso é um sinal de algo que você precisa consertar. 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 usaram o software. Levou cerca de cinco minutos e, no final, eles construíram 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. Então, qualquer coisa que pudéssemos fazer para que mais pessoas passassem pelo test drive aumentaria nossa taxa de crescimento.
Estudei os rastros de cliques de pessoas fazendo o test drive e descobri que em um certo passo elas ficavam confusas e clicavam no botão Voltar do navegador. (Se você tentar escrever aplicativos baseados na Web, verá 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 de não clicar no botão Voltar. Outra grande coisa sobre o software baseado na Web é que você obtém feedback instantâneo das mudanças: o número de pessoas concluindo o test drive aumentou imediatamente de 60% para 90%. E como o número de novos usuários era uma função do número de test drives concluídos, 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 pareceu uma declaração muito cínica. Mas depois percebi que isso 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 continuar comprando e instalando novas versões para que continuem pagando a você. E, felizmente, as assinaturas são a maneira natural de cobrar por aplicativos baseados na Web.
Hospedar aplicativos é uma área em que as empresas desempenharão um papel que provavelmente não será preenchido por freeware. Hospedar aplicativos é muito estressante e tem despesas reais. Ninguém vai querer fazer isso de graça.
Para empresas, aplicativos baseados na Web são uma fonte ideal de receita. Em vez de começar cada trimestre com uma lousa em branco, você tem um fluxo de receita recorrente. Como seu software evolui gradualmente, você não precisa se preocupar que um novo modelo fracasse; nunca precisa haver um novo modelo, por si só, e se você fizer algo com o software que os usuários odeiam, você 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. Alguma 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 usasse 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, o que significa cobrar de cada cliente o máximo que ele pode 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 caixas Intel: uma empresa que usa Suns não está interessada em economizar dinheiro e pode ser cobrada mais com segurança. 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 inventar 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 então compram, como duas etapas separadas. Foi o que eu pensava antes da Viaweb, na medida em que pensei sobre a questão. Na verdade, a segunda etapa pode se propagar de volta para a primeira: se algo é difícil de comprar, as pessoas mudarão de ideia sobre se 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 é praticamente a coisa mais fácil do mundo de comprar, especialmente se você acabou de fazer uma demonstração online. Os usuários não devem ter que fazer muito mais do que digitar 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 por ISPs que agem como revendedores. Esta é uma má ideia. Você tem que administrar os servidores, porque precisa estar constantemente melhorando tanto o hardware quanto o software. Se você abrir mão do controle direto dos servidores, você abre mão da maioria das vantagens de desenvolver aplicativos baseados na Web.
Vários dos nossos concorrentes deram um tiro no próprio pé dessa forma-- geralmente, eu acho, porque foram invadidos por ternos que estavam animados com esse enorme canal em potencial, e não perceberam que isso arruinaria o produto que esperavam vender por meio dele. Vender software baseado na Web por meio de ISPs é como vender sushi por meio de máquinas de venda automática.
Clientes
Quem serão os clientes? Na Viaweb, eles eram inicialmente indivíduos e empresas menores, e acho que essa será a regra com aplicativos baseados na Web. Esses são os usuários que estão prontos para tentar coisas novas, em parte porque são mais flexíveis e em parte porque querem os custos mais baixos da nova tecnologia.
Aplicativos baseados na Web frequentemente 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 aplicativos verdadeiramente baseados 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 depende da segurança: se o acesso é mais fácil para os funcionários, também será para os bandidos. Alguns comerciantes maiores estavam relutantes em usar a 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 inteiro é executar servidores ou um varejista de roupas? Não só tínhamos pessoas melhores se preocupando 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, provavelmente poderia ser abafado e, no pior dos casos, poderia fazer com que uma pessoa fosse demitida. Se alguém invadisse os nossos, isso poderia afetar milhares de comerciantes, provavelmente acabaria como notícia na CNet e poderia nos tirar do mercado.
Se você quer manter seu dinheiro seguro, você o guarda debaixo do 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 direito. 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 aplicativos baseados na Web está, até certo ponto, terceirizando a TI. Por mais drástico que pareça, acho que essa é geralmente uma boa ideia. As empresas provavelmente obterão um serviço melhor dessa forma do que obteriam de administradores de sistemas internos. Os administradores de sistemas podem ficar irritados e indiferentes 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 solteiro, tem poucas forças externas para mantê-lo na linha. [10] Na Viaweb, tínhamos forças externas de sobra para nos manter na linha. As pessoas que nos ligavam eram clientes, não apenas colegas de trabalho. Se um servidor ficasse preso, nós pulávamos; só de pensar nisso, sinto uma descarga de adrenalina, anos depois.
Então, aplicativos baseados 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 os computadores de mesa. E em parte pela mesma razão: valerá muito dinheiro convencer grandes empresas de que elas precisam de algo mais caro.
Há sempre uma tendência de 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. Na Viaweb, sempre enfrentamos isso. Perdemos vários comerciantes de alto nível para empresas de consultoria da Web que os convenceram de que estariam melhor se pagassem meio milhão de dólares por uma loja on-line personalizada em seu próprio servidor. Eles, como regra, não estavam em melhor situação, como mais de um descobriu quando a temporada de compras de Natal chegou e as cargas aumentaram em seu servidor. A Viaweb era muito mais sofisticada do que a maioria desses comerciantes tinha, mas não podíamos contar a eles. Por US$ 300 por mês, não podíamos enviar uma equipe de pessoas bem-vestidas e com aparência autoritária para fazer apresentações aos 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 sanitários, é em parte porque custa muito vender assentos sanitários por mil dólares.) E esta é uma das razões pelas quais o software de intranet continuará a prosperar, embora seja provavelmente uma má ideia. É simplesmente mais caro. Não há nada que você possa fazer sobre esse enigma, então o melhor plano é ir primeiro para os clientes menores. O resto virá com o tempo.
Filho do Servidor
Executar software no servidor não é nenhuma novidade. Na verdade, é o modelo antigo: aplicativos de mainframe são todos baseados em servidor. Se software baseado em servidor é uma ideia tão boa, por que ele perdeu da última vez? Por que computadores de mesa eclipsaram mainframes?
No começo, os computadores de mesa não pareciam ser uma grande ameaça. Os primeiros usuários eram todos hackers — ou amadores, como eram chamados na época. Eles gostavam de microcomputadores porque eram baratos. Pela primeira vez, você podia ter seu próprio computador. A frase "computador pessoal" faz parte da linguagem agora, mas quando foi usada pela primeira vez tinha um som deliberadamente audacioso, como a frase "satélite pessoal" teria hoje.
Por que os computadores de mesa assumiram o controle? Acho que foi porque eles tinham um software melhor. E acho que a razão pela qual o software de microcomputador era melhor era que ele podia ser escrito por pequenas empresas.
Não acho que muitas pessoas percebam o quão frágeis e hesitantes as startups são no estágio inicial. Muitas startups começam quase por acidente — como dois caras, seja com empregos diários 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 paralisará a startup. Escrever software de mainframe exigia muito comprometimento inicial. 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 hackear algo no seu Apple II à noite. E então você não tinha muitas startups escrevendo aplicativos de mainframe.
A chegada dos computadores de mesa inspirou muitos softwares novos, porque escrever aplicativos para eles parecia uma meta atingível para startups larvais. O desenvolvimento era barato, e os clientes seriam pessoas individuais que você poderia alcançar por meio de lojas de informática ou mesmo por correspondência.
O aplicativo que impulsionou os computadores de mesa para o mainstream foi o VisiCalc , a primeira planilha. Ele foi escrito por dois caras que trabalhavam em um sótão e, ainda assim, fazia coisas que nenhum software de mainframe conseguia fazer. [11] O VisiCalc foi um avanço tão grande, em sua época, 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 as startups escreveram software para eles.
Parece que o software baseado em servidor será bom desta vez, porque as startups o escreverão. Os computadores são tão baratos agora que você pode começar, como nós fizemos, usando um computador desktop como servidor. Processadores baratos comeram o mercado de estações de trabalho (você raramente ouve essa palavra agora) e estão quase no mercado de servidores; os servidores do Yahoo, que lidam com cargas tão altas quanto qualquer outro na Internet, todos têm os mesmos processadores Intel baratos que você tem em sua máquina desktop. E uma vez que você escreveu o software, tudo o que você precisa para vendê-lo é um site. Quase todos os nossos usuários vieram diretamente para o nosso site por meio do boca a boca e referências na imprensa. [12]
A Viaweb era uma típica startup larval. Tínhamos medo de 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 escrevíamos o software, nosso servidor Web era a mesma máquina desktop que usávamos para desenvolvimento, conectada ao mundo externo por uma linha discada. Nossas únicas despesas naquela fase eram comida e aluguel.
Há ainda mais motivos para startups escreverem software baseado na Web agora, porque escrever software para desktop se tornou muito menos divertido. Se você quer escrever software para desktop agora, faça isso nos termos da Microsoft, chamando suas APIs e trabalhando em torno de seu sistema operacional cheio de bugs. E se você conseguir escrever algo que decole, você pode descobrir que estava apenas fazendo pesquisa de mercado para a Microsoft.
Se uma empresa quer fazer uma plataforma na qual startups construirão, ela tem que fazer algo que os próprios hackers queiram usar. Isso significa que tem que ser barato e bem projetado. O Mac era popular entre hackers quando foi lançado, e muitos deles escreveram software para ele. [13] Você vê isso menos com o Windows, porque hackers não o usam. O tipo de pessoa que é boa em escrever software tende a rodar Linux ou FreeBSD agora.
Não acho que teríamos começado uma startup para escrever software de desktop, porque software de desktop tem que rodar no Windows, e antes que pudéssemos escrever software para Windows, teríamos que usá-lo. A Web nos permitiu fazer uma volta ao redor do Windows, e entregar software rodando em Unix diretamente para os 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 a gigante que todos temiam. É difícil imaginar agora, mas eu me lembro muito bem da sensação. Agora, a gigante assustadora é a Microsoft, e eu não acho que eles sejam tão cegos à ameaça que os enfrenta como a IBM era. Afinal, a Microsoft construiu deliberadamente seus negócios no ponto cego da IBM.
Mencionei antes que minha mãe não precisa realmente de um computador desktop. A maioria dos usuários provavelmente não precisa. Isso é um problema para a Microsoft, e eles sabem disso. Se os aplicativos rodam em servidores remotos, ninguém precisa do Windows. O que a Microsoft fará? Eles serão capazes de usar seu controle do desktop para impedir, 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 junto com os servidores que eles controlam. No mínimo, os arquivos estarão disponíveis centralmente para os usuários que quiserem isso. Não espero que a Microsoft vá ao extremo de fazer os cálculos no servidor, com apenas um navegador para um cliente, se puderem evitar. Se você só precisa de um navegador para um cliente, não precisa da Microsoft no cliente, e se a Microsoft não controla o cliente, ela não pode empurrar os usuários para seus aplicativos baseados em servidor.
Acho que a Microsoft terá dificuldade em manter o gênio na garrafa. Haverá muitos tipos diferentes de clientes para que eles os controlem todos. E se os aplicativos da Microsoft funcionarem apenas com alguns clientes, os concorrentes poderão superá-los oferecendo aplicativos que funcionam em qualquer cliente. [14]
Em um mundo de aplicativos baseados na Web, não há lugar automático para a Microsoft. Eles podem ter sucesso em criar um lugar para si mesmos, mas não acho que eles dominarão esse novo mundo como fizeram com o mundo dos aplicativos de desktop.
Não é tanto que um concorrente irá derrubá-los, mas que eles mesmos tropeçarão. Com o surgimento do software baseado na Web, eles enfrentarão não apenas problemas técnicos, mas também suas próprias ilusões. O que eles precisam fazer é canibalizar seus negócios existentes, e não consigo vê-los enfrentando isso. A mesma obstinação que os trouxe até aqui agora estará trabalhando contra eles. A IBM estava exatamente na mesma situação, e eles não conseguiram dominá-la. A IBM fez uma entrada tardia e sem entusiasmo no negócio de microcomputadores porque eles estavam ambivalentes sobre ameaçar sua vaca leiteira, a computação mainframe. A Microsoft também será prejudicada por querer salvar o desktop. Uma vaca leiteira pode ser um macaco muito pesado para suas costas.
Não estou dizendo que ninguém dominará os aplicativos baseados em servidor. Alguém provavelmente dominará eventualmente. Mas acho que haverá um bom e longo período de caos alegre, assim como houve nos primeiros dias dos microcomputadores. Foi uma boa época para startups. Muitas pequenas empresas floresceram, e fizeram isso fazendo coisas legais.
Startups, mas muito mais
A startup clássica é rápida e informal, com poucas pessoas e pouco dinheiro. Essas poucas pessoas trabalham muito duro, e a tecnologia amplia o efeito das decisões que elas tomam. Se elas ganham, elas ganham muito.
Em uma startup que escreve aplicativos baseados 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ê tem que ser ainda mais rápido, e pode se safar sendo 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 ficaram menores, mais rápidas e mais informais. Em 1960, o desenvolvimento de software significava uma sala cheia de homens com óculos de aro de chifre e gravatas pretas estreitas, escrevendo diligentemente 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 são dois caras sentados em uma sala de estar com laptops. (E jeans acabam não sendo a última palavra em informalidade.)
Startups são estressantes, e isso, infelizmente, também é levado ao extremo com aplicativos baseados na Web. Muitas empresas de software, especialmente no começo, têm períodos em que os desenvolvedores dormiam sob suas mesas e assim por diante. O alarmante sobre software baseado na Web é que não há nada que impeça que isso se torne o padrão. As histórias sobre dormir sob mesas geralmente terminam: então finalmente nós o enviamos e todos nós fomos para casa e dormimos por uma semana. Software baseado na Web nunca é enviado. Você pode trabalhar 16 horas por dia pelo tempo que quiser. E porque você pode, e seus concorrentes podem, você tende a ser forçado a isso. Você pode, então você deve. É a Lei de Parkinson correndo ao contrário.
O pior não são as horas, mas a responsabilidade. Tradicionalmente, programadores e administradores de sistemas 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 vão para casa e esquecem disso. Administradores de sistemas nunca deixam o trabalho para trás, mas quando são chamados às 4:00 da manhã, eles geralmente não precisam fazer nada muito complicado. Com aplicativos baseados 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.
Na Viaweb, passamos os primeiros seis meses apenas escrevendo software. Trabalhamos as longas horas habituais de uma startup iniciante. Em uma empresa de software para desktop, essa seria a parte em que estaríamos trabalhando duro, mas parecia férias em comparação com a próxima fase, quando levamos os usuários para o nosso servidor. O segundo maior benefício de vender a Viaweb para o Yahoo (depois do dinheiro) foi poder despejar a responsabilidade final por tudo nos ombros de uma grande empresa.
O software de desktop força os usuários a se tornarem administradores de sistema. O 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] Os aplicativos baseados na Web oferecem uma maneira direta de superar seus concorrentes. Nenhuma startup pede mais.
Apenas bom o suficiente
Uma coisa que pode dissuadi-lo de escrever aplicativos baseados na Web é a fraqueza das páginas da Web como uma IU. Isso é um problema, admito. Havia algumas coisas que realmente gostaríamos de ter adicionado ao HTML e ao HTTP. O que importa, no entanto, é que as páginas da Web sejam boas o suficiente.
Há um paralelo aqui com os primeiros microcomputadores. Os processadores nessas máquinas não foram realmente projetados para serem CPUs de computadores. Eles foram projetados para serem usados em coisas como semáforos. Mas caras como Ed Roberts, que projetou o Altair , perceberam que eles eram bons o suficiente. Você poderia combinar um desses chips com alguma memória (256 bytes no primeiro Altair) e interruptores do painel frontal, e você teria um computador funcional. Ser capaz de ter seu próprio computador era tão emocionante 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 IU para aplicativos, mas são boas o suficiente. E para um número significativo de usuários, o software que você pode usar de qualquer navegador será uma vitória suficiente para superar qualquer estranheza na IU. Talvez você não consiga escrever a planilha mais bonita usando HTML, mas pode escrever uma planilha que várias pessoas podem usar simultaneamente de diferentes locais sem software cliente especial, ou que pode incorporar feeds de dados ao vivo, ou que pode enviar uma mensagem quando certas condições são acionadas. Mais importante, você pode escrever novos tipos de aplicativos que nem têm nomes ainda. O VisiCalc não era meramente uma versão de microcomputador de um aplicativo de mainframe, afinal de contas — era um novo tipo de aplicativo.
Claro, aplicativos baseados em servidor não precisam ser baseados na Web. Você poderia ter algum outro tipo de cliente. Mas tenho certeza de que é 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 instalariam — mas se não o fizerem, você está perdido. Como o software baseado na Web não assume nada sobre o cliente, ele funcionará em qualquer lugar que a Web funcione. Essa já é uma grande vantagem, e a vantagem aumentará à medida que novos dispositivos da 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 observei a evolução da Web tão de perto quanto qualquer um, e não posso prever o que vai acontecer com os clientes. A convergência provavelmente está chegando, mas onde? Não posso escolher um vencedor. Uma coisa que posso prever é o conflito entre a AOL e a Microsoft. Seja lá o que o .NET da Microsoft venha a ser, provavelmente envolverá conectar o desktop aos servidores. A menos que a AOL reaja, eles serão colocados de lado ou transformados em um canal 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, o que significa que os aplicativos baseados na Web serão o único tipo que funcionará em todos os lugares.
Como tudo isso vai acontecer? Não sei. E você não precisa saber se apostar em aplicativos baseados 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. Os aplicativos baseados na Web são baratos de desenvolver e fáceis até para a menor startup entregar. Eles dão muito trabalho e são de um tipo particularmente estressante, mas isso só aumenta as chances para as startups.
Por que não?
EB White se divertiu ao saber de um amigo fazendeiro que muitas cercas eletrificadas não têm nenhuma corrente passando por elas. As vacas aparentemente aprendem a ficar longe delas, e depois disso você não precisa mais da corrente. "Levantem-se, vacas!", ele escreveu, "Tomem sua liberdade enquanto os déspotas roncam!"
Se você é um hacker que 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: construir algo que os usuários amem e ganhar mais do que gasta. Se você acertar essas duas coisas, estará à frente da maioria das startups. Você pode descobrir o resto conforme avança.
Você pode não ganhar mais do que gasta no começo, mas enquanto a diferença estiver diminuindo rápido o suficiente, você ficará bem. Se você começar com pouco dinheiro, isso pelo menos encorajará um hábito de frugalidade. Quanto menos você gasta, mais fácil é ganhar mais do que gasta. Felizmente, pode ser muito barato lançar um aplicativo baseado na Web. Lançamos com menos de US$ 10.000, e seria ainda mais barato hoje. Tivemos que gastar milhares em um servidor, e milhares a mais para obter SSL. (A única empresa que vendia 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ê pode lançar um aplicativo baseado na Web agora por menos do que o custo de uma cadeira de escritório chique.
Quanto a construir algo que os usuários amam, aqui estão algumas dicas gerais. Comece fazendo algo limpo e simples que você gostaria de usar. Obtenha uma versão 1.0 rapidamente, então 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 um 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 dos seus concorrentes for ruim; 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. A Viaweb deveria ser uma construtora de lojas online, mas nós a usamos para fazer nosso próprio site também. Não dê ouvidos a pessoas de marketing, designers ou gerentes de produto apenas por causa de seus cargos. Se eles têm boas ideias, use-as, mas cabe a você decidir; software tem que ser projetado por hackers que entendam de design, não designers que saibam 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 competição. O que você tem medo 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 alguns hackers descobrirem como alugar um espaço de escritório ou contratar vendedores do que para uma empresa de qualquer tamanho ter um software escrito. Eu estive dos dois lados, e eu sei. Quando a Viaweb foi comprada pelo Yahoo, de repente me vi trabalhando para uma grande empresa, e foi como tentar correr em água até a cintura.
Não quero menosprezar o Yahoo. Eles tinham alguns bons hackers, e a alta gerência era realmente foda. Para uma grande empresa, eles eram excepcionais. Mas eles ainda eram apenas cerca de um décimo da produtividade de 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 consegue desenvolver software. Eles são como uma montanha que pode andar.
Não se intimide. Você pode fazer tanto o que a Microsoft não pode quanto eles podem fazer o que você não pode. E ninguém pode impedi-lo. Você não precisa pedir permissão a ninguém para desenvolver aplicativos baseados na Web. Você não precisa fazer acordos de licenciamento, ou obter espaço nas prateleiras de lojas de varejo, ou rastejar para ter seu aplicativo empacotado com o sistema operacional. Você pode entregar software diretamente para o navegador, e ninguém pode ficar entre você e os usuários em potencial sem impedi-los de navegar na Web.
Você pode não acreditar, mas eu lhe prometo, a Microsoft tem medo de você. Os gerentes de nível médio complacentes podem não ter, mas Bill tem, porque ele já foi você, em 1975, a última vez que uma nova maneira de entregar software apareceu.
Notas
[1] Percebendo que grande parte do dinheiro está nos serviços, as empresas que criam clientes leves geralmente tentam 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 executar um serviço online, e em parte porque os usuários odeiam a ideia. Oferecer o barbeador e ganhar dinheiro com as lâminas pode funcionar para a Gillette, mas um barbeador é um compromisso muito menor do que um terminal da Web. Os fabricantes de celulares estão satisfeitos em vender hardware sem tentar capturar a receita do serviço também. Esse provavelmente deve ser o modelo para clientes da Internet também. Se alguém vendesse uma caixinha bonita com um navegador da Web que você pudesse usar para se conectar por meio de qualquer ISP, todos os tecnófobos do país comprariam um.
[2] A segurança sempre depende mais de não estragar 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 em não estragar. Comprometer um servidor pode causar tantos danos que os ASPs (que querem permanecer no mercado) provavelmente serão cuidadosos com a segurança.
[3] Em 1995, quando começamos a Viaweb, os applets Java deveriam ser a tecnologia que todos usariam para desenvolver aplicativos baseados em servidor. Os applets nos pareciam uma ideia antiquada. Baixar programas para rodar no cliente? Mais simples apenas ir até o fim e rodar os programas no servidor. Perdemos pouco tempo com applets, mas inúmeras outras startups devem ter sido atraídas para esse poço de piche. Poucos podem ter escapado vivos, ou a Microsoft não teria conseguido 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 à correção de bugs antigos, e o custo pode ser mais linear se todos os bugs forem encontrados rapidamente".
[5] O tipo mais difícil de bug de encontrar pode ser uma variante de bug composto onde um bug compensa outro. Quando você corrige um bug, o outro se torna visível. Mas parecerá que a correção está errada, já que essa foi a última coisa que você alterou.
[6] Dentro da Viaweb, uma vez fizemos um concurso para descrever a pior coisa sobre nosso software. Duas pessoas de suporte ao cliente empataram no primeiro prêmio com inscrições que ainda me arrepio ao lembrar. 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 generalizada (quantas vezes já ouviu um retalhista afirmar que o seu poder de compra significava preços mais baixos para si?) que fiquei surpreendido ao descobrir que foi proibida nos EUA pela Lei Robinson-Patman de 1936. Esta lei não parece ser aplicada com rigor.
[9] Em No Logo, Naomi Klein diz que as marcas de roupa preferidas pela “juventude urbana” não se esforçam muito para impedir os furtos em lojas porque no seu mercado-alvo os furtadores também são os líderes da moda.
[10] As empresas frequentemente se perguntam o que terceirizar e o que não terceirizar. Uma resposta possível: terceirizar qualquer trabalho que não esteja diretamente exposto à pressão competitiva, porque terceirizá-lo irá, portanto, expô-lo à pressão competitiva.
[11] Os dois caras eram Dan Bricklin e Bob Frankston. Dan escreveu um protótipo em Basic em alguns dias, então 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, falhasse. Não é grande coisa."
[12] Não é tão fácil quanto eu faço parecer. Demorou um tempo dolorosamente longo para o boca a boca começar, e não começamos a ter muita cobertura da imprensa até contratarmos uma empresa de RP (reconhecidamente a melhor do ramo) por US$ 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 bom, por que ele perdeu? Custo, novamente. A Microsoft se concentrou no negócio de software e liberou um enxame de fornecedores de componentes baratos para o hardware da Apple. Também não ajudou que os ternos tenham assumido o controle durante um período crítico.
[14] Uma coisa que ajudaria os aplicativos baseados na Web e ajudaria a evitar que a próxima geração de software fosse ofuscada pela Microsoft seria um bom navegador de código aberto. O Mozilla é de código aberto, mas parece ter sofrido por ter sido um software corporativo por tanto tempo. Um navegador pequeno e rápido que fosse mantido ativamente seria uma grande coisa por si só e provavelmente também encorajaria as empresas a construir pequenos aparelhos da Web.
Entre outras coisas, um navegador de código aberto adequado faria com que HTTP e HTML continuassem a evoluir (como, por exemplo, Perl). Ajudaria muito os aplicativos baseados na Web a conseguir distinguir entre selecionar um link e segui-lo; tudo o que você precisaria para fazer isso seria um aprimoramento trivial do HTTP, para permitir múltiplas 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 mecanismo 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 — as coisas novas começam com seus usuários.
[15] Trevor Blackwell, que provavelmente sabe mais sobre isso por experiência própria do que qualquer outra pessoa, escreve:
"Eu iria mais longe ao dizer que, como o software baseado em servidor é tão difícil para os programadores, ele causa uma mudança econômica fundamental para longe das grandes empresas. Ele requer o tipo de intensidade e dedicação dos programadores que eles só estarão dispostos a fornecer quando for sua própria empresa. As empresas de software podem contratar pessoas qualificadas para trabalhar em um ambiente não muito exigente e podem contratar pessoas não qualificadas para suportar dificuldades, mas não podem contratar pessoas altamente qualificadas para se esforçarem. Como o capital não é mais necessário, as grandes empresas têm pouco a oferecer."
[16] Na versão original deste ensaio, aconselhei evitar Javascript. Esse era um bom plano em 2001, mas Javascript agora funciona.
Agradeço a Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson e Dan Giffin pela leitura dos rascunhos deste artigo; a Dan Bricklin e Bob Frankston pelas informações sobre o VisiCalc; e novamente a Ken Anderson por me convidar para falar na BBN.
Você encontrará este ensaio e outros 14 em Hackers & Painters .