O OUTRO CAMINHO À FRENTE
OriginalSeptember 2001
(Este artigo explica por que muito da próxima geração de software pode ser baseado em servidor, o que isso significará para os programadores, e por que esse novo tipo de software é uma ótima oportunidade para startups. Ele é 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 precedeu o IPO do Netscape estava a todo vapor na época, e havia muita conversa na imprensa sobre comércio online. Na época, pode ter havido trinta lojas reais na Web, todas feitas à mão. Se houvesse muitas lojas online, seria necessário software para fazer elas, então decidimos escrever algumas.
Na primeira semana, mais ou menos, 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 por meio da 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, este 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. Só depois do lançamento do Hotmail, um ano depois, as pessoas começaram a entender. Agora todo mundo sabe que essa é uma abordagem válida. Existe um nome agora para o que éramos: um provedor de serviços de aplicativos, ou ASP.
Acho que muito da próxima geração de software será escrito 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 para fora da área de trabalho e 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 move para servidores, o que estou descrevendo aqui é o futuro.
A Próxima Coisa?
Quando olharmos para trás na era do software de desktop, acho que vamos nos maravilhar com os inconvenientes 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 possuir um carro. Mas os carros eram tão uma grande vitória que muitas pessoas que não eram especialistas em carros queriam tê-los também.
Os computadores estão nessa fase agora. Quando você possui um computador de mesa, você acaba aprendendo muito mais do que queria saber sobre o que está acontecendo dentro dele. Mas mais da metade das famílias nos EUA possui um. Minha mãe tem um computador que ela usa para e-mail e para manter contas. Há cerca de um ano, ela ficou alarmada ao receber uma carta da Apple, oferecendo a ela 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 nem deveriam saber as palavras "sistema operacional", muito menos "driver de dispositivo" ou "patch".
Agora existe outra maneira de entregar software que salvará os usuários de se tornarem administradores de sistema. Os aplicativos baseados na Web são programas que são executados em servidores Web e usam páginas da Web como o usuário interface. 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 sobre qualquer coisa, exceto os aplicativos que usam. Todas as coisas confusas e em constante mudança estarão em algum servidor, 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 software. Tudo o que você precisará será 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 US$ 200 e que as pessoas escolhem principalmente com base na aparência da caixa. Você pagará mais por serviços de Internet do que pelo hardware, assim como faz agora com telefones. [1]
Levará cerca de um décimo de segundo para um clique chegar ao servidor e voltar, então os usuários de software altamente interativo, como Photoshop, ainda vão querer que os cálculos aconteçam no desktop. Mas se você olhar para o tipo de coisas que a maioria das pessoas usa computadores para, uma latência de um décimo de segundo não seria um problema. Minha mãe não precisa realmente 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 do inconveniente". A maioria das pessoas, na maioria das vezes, vai pegar 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 software em seu computador de mesa, você só pode usá-lo naquele computador. Pior ainda, seus arquivos são presos naquele computador. O inconveniente desse modelo se torna cada vez mais evidente à medida que as pessoas se acostumam com as redes.
A ponta fina da cunha 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 você 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 você não pode editá-lo? Por que algum de seus dados deve ser preso em algum computador sentado em uma mesa distante?
A ideia toda de "seu computador" está desaparecendo e 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 outro motivo para não manter seus dados neles: algo que você carrega com você 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 ser vaporizado.
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 é executado em seu sistema operacional.
Por não precisar de instalação, será fácil e comum experimentar software baseado na Web antes de "comprá-lo". Você deve esperar ser capaz de fazer um test drive de 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 no serviç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 receber novas versões sem pagar a mais, ou fazendo qualquer trabalho, ou possivelmente até mesmo sabendo disso.
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 de parte dos desenvolvedores. Eles terão que projetar software para que possa ser atualizado sem confundir os usuários. Esse é um novo problema, mas existem 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. 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 em um determinado momento. Isso é ordens de magnitude melhor do que o software de desktop.
Aplicações baseadas na Web podem ser usadas por várias pessoas ao mesmo tempo. Isso é 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. O Viaweb permitiu que vários usuários editassem um site simultaneamente, mais porque essa era a maneira correta 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 mais 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 sistemas reais preocupados com essas coisas, mas porque um ASP que perde os dados das pessoas estará em uma grande, grande enrascada. 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 culpar. 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 além de um navegador, há menos chance de executar vírus e nenhum dado local para danificar. E um programa que atacasse os próprios servidores deveria 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 atenda a essa descrição. Desatado, poderia ser uma força poderosa.
Cidade do Código
Para os desenvolvedores, a diferença mais visível entre software baseado na Web e software de desktop é que um aplicativo baseado na Web não é uma única peça de código. 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 prédio: além dos prédios, você precisa de estradas, placas de rua, serviços públicos, polícia e bombeiros, e planos para o crescimento e vários tipos de desastres.
No Viaweb, o software incluía aplicativos bastante grandes com os quais os usuários conversavam diretamente, programas que esses programas usavam, programas que eram executados constantemente em segundo plano procurando problemas, programas que tentavam reiniciar as coisas se elas quebrassem, programas que eram executados ocasionalmente para compilar estatísticas ou construir índices para pesquisas, programas que executávamos 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 com os visitantes, mas indispensável para nós também), modificações (incluindo correções de bugs) para software de código aberto e uma grande quantidade de arquivos 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 pelo Yahoo. Os programas nos paginavam, enviavam faxes e e-mails para os usuários, realizavam transações com processadores de cartão de crédito e conversavam uns com os outros por meio de sockets, pipes, solicitações http, ssh, pacotes udp, memória compartilhada e arquivos. Parte do Viaweb até consistia 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 em configurações de servidor. 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. Tínhamos que pensar se nosso ISP upstream tinha conexões rápidas o suficiente para todas as backbones. Nós seriamente namoramos fornecedores de RAID.
Mas o hardware não é apenas algo para se preocupar. Quando você o controla, pode fazer mais pelos usuários. Com um aplicativo de desktop, você pode especificar um determinado hardware mínimo, mas não pode adicionar mais. Se você administrar os servidores, pode em uma etapa permitir que todos os seus usuários paginem pessoas, ou enviem faxes, ou enviem comandos por telefone, ou processem 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 diferenciar 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 - o que significa 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 forma 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é mesmo Lisp.
Com software baseado em servidor, ninguém pode dizer qual linguagem usar, porque você controla todo o sistema, até o hardware. Diferentes linguagens são boas para diferentes tarefas. Você pode usar o que for melhor para cada um. 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 natureza sem estado dos scripts CGI. Se você fosse mudar alguma coisa, todas as mudanças tinham que acontecer em uma única 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 software de desktop.
Lançamentos
Uma das mudanças mais importantes nesse novo mundo é a forma como você faz lançamentos. No negócio de software de desktop, fazer um lançamento é um trauma enorme, no qual toda a empresa sua e se esforça para lançar uma única peça de código gigante. 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 estivesse escrevendo para si mesmo. Você lança software como uma série de alterações incrementais em vez de uma explosão grande ocasional. Uma empresa típica de software de desktop pode fazer um ou dois lançamentos por ano. No Viaweb, muitas vezes 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 de desktop são devidos à natureza catastrófica dos lançamentos.
Quando você lança apenas uma nova versão por ano, tende a lidar com bugs por atacado. Algum tempo antes da data de lançamento, você monta uma nova versão na qual metade do código foi removida e substituída, 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 final da lista e, de fato, ninguém sabe onde está o fim. É como pescar entulho em um lago. Você nunca sabe realmente o que está acontecendo dentro do software. No melhor dos casos, você acaba com um tipo estatístico de correção.
Com software baseado em servidor, a maior parte da mudança é pequena e incremental. Isso por si só é menos propenso a introduzir bugs. Também significa que você sabe o que testar com mais cuidado quando está prestes a lançar 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 lê o código-fonte, você o faz como um piloto examinando o painel de instrumentos, não como um detetive tentando desvendar algum mistério.
O software de desktop cria um certo fatalismo sobre bugs. Você sabe que está enviando algo cheio de bugs e até configurou mecanismos para compensar isso (por exemplo, lançamentos de patches). Então, por que se preocupar com mais alguns? Em breve, você estará 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 pronto. 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 ele funcione, e você pode lançá-lo assim que ele funcionar.
O veterano da indústria pode estar pensando: é uma ideia boa dizer que você nunca precisa lançar software antes que ele funcione, mas o que acontece quando você prometeu entregar uma nova versão do seu software até uma determinada 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 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 parecer estranho, porque nós sempre estávamos anunciando novas versões. Isso foi feito inteiramente para fins de RP. A imprensa especializada, aprendemos, pensa em números de versão. Eles darão a você uma cobertura importante 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 de ponto, 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 nos pareceu evidência de sua retrógrada, eles receberiam todo tipo de publicidade. Não queríamos perder, então começamos a dar números de versão para nosso software também. Quando queríamos alguma publicidade, faríamos uma lista de todos os recursos que adicionamos desde o último "lançamento", colocaríamos um novo número de versão no software, e emitiríamos um comunicado de imprensa dizendo que a nova versão estava disponível imediatamente. Incrivelmente, ninguém nunca nos chamou por isso.
Na época em que fomos comprados, tínhamos feito isso três vezes, então estávamos na versão 4. Versão 4.1 se eu me lembro corretamente. Depois que a Viaweb se tornou Yahoo Store, não havia mais tanta necessidade desesperada de 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 você faria com software de desktop: você deve ser capaz de reproduzir o erro enquanto eles estão no telefone com você. Você pode até saber disso já, se tiver código para notar erros embutido em seu aplicativo.
O software baseado na Web é usado o tempo todo, então tudo o que você faz é imediatamente colocado no liquidificador. Os bugs aparecem rapidamente.
As empresas de software são às vezes acusadas de deixar os usuários depurar seu software. E é exatamente isso que estou defendendo. Para software baseado na Web é realmente um bom plano, porque os bugs são menos numerosos e transitórios. Quando você lança software gradualmente, você obtém muito menos bugs para começar. E quando você pode reproduzir erros e lançar mudanças instantaneamente, você pode encontrar e corrigir a maioria dos bugs assim que eles aparecem. Nunca tivemos bugs suficientes ao mesmo tempo para nos incomodar com um sistema formal de rastreamento de bugs.
Você deve testar as alterações antes de lançá-las, é claro, para que nenhum bug importante seja lançado. Aqueles poucos que inevitavelmente escapam irão envolver casos limítrofes e afetarão apenas os poucos usuários que os encontrarem antes que alguém ligue para reclamar. Como contanto que você corrija 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.
Corrigir bugs recentes é mais fácil do que corrigir bugs antigos. É geralmente bastante 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 para a fonte, porque você já estava preocupado com isso subconscientemente. Corrigir um bug em algo que você escreveu há seis meses (o caso médio se você lança uma vez por ano) é muito mais trabalho. E como você não entende o código tão bem, é mais provável que você o corrija de uma forma feia, ou até mesmo introduza mais bugs. [4]
Quando você detecta bugs cedo, você também obtém menos bugs compostos. Bugs compostos são dois bugs separados que interagem: você tropeça descendo as escadas, e quando você pega na mão corrente, ela sai na sua mão. No software, esse tipo de bug é o mais difícil de encontrar, e também tende a ter as piores consequências. [5] O tradicional "quebre tudo e depois filtre os bugs" abordagem inerentemente produz muitos bugs compostos. E o software que é lançado em uma série de pequenas mudanças inerentemente tende a não. Os pisos são constantemente varridos para remover quaisquer objetos soltos que possam mais tarde ficar presos em algo.
Ajuda se você usar uma técnica chamada programação funcional. Programação funcional significa evitar efeitos colaterais. É algo que você tem mais probabilidade 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 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 negócio de software de 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 eram prováveis de serem usuários avançados, empurrando os limites. Usuários avançados são mais tolerantes com bugs, especialmente porque você provavelmente os introduziu no processo de adicionar 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 costumavam se orgulhar de pegar um. Eles ligariam para o suporte em um espírito mais de triunfo do que raiva, como se tivessem marcado pontos contra nós.
Suporte
Quando você pode reproduzir erros, isso muda sua abordagem ao atendimento 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 eles estão apenas fazendo algo errado e você tem que descobrir o que é. Em qualquer caso, 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 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 dos clientes. Se alguém tivesse um problema, queríamos saber disso 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. As pessoas do atendimento ao cliente estavam a cerca de trinta pés de distância dos programadores, e sabiam que sempre poderiam interromper qualquer coisa com um relatório de um bug genuíno. Deixaríamos uma reunião do conselho para corrigir um bug sério.
Nossa abordagem ao suporte tornou todos mais felizes. Os clientes estavam encantados. Imagine como seria ligar para uma linha de suporte e ser tratado como alguém que traz notícias importantes. O cliente as pessoas do atendimento ao cliente gostaram porque isso significava que elas podiam ajudar os usuários, em vez de ler scripts para eles. E os programadores gostaram porque eles podiam reproduzir bugs em vez de apenas ouvir vagos relatórios em segunda mão sobre eles.
Nossa política de corrigir erros em tempo real mudou o relacionamento entre as pessoas do suporte ao cliente e os hackers. Na maioria das empresas de software, as pessoas do 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 erros, é provável que seja unidirecional: as pessoas do suporte que ouvem sobre erros preenchem 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 de ouvir sobre um erro de um cliente, as pessoas do suporte poderiam estar ao lado de um programador ouvindo-o dizer "Merda, você está certo, é um erro". Deleitava as pessoas do suporte ouvir "você está certo" dos hackers. Eles costumavam nos trazer erros com a mesma expectativa de um gato que lhe traz um rato que acabou de matar. Também os tornava mais cuidadosos ao julgar a gravidade de um erro, porque agora sua honra estava em jogo.
Depois que fomos comprados pelo Yahoo, as pessoas do suporte ao cliente foram transferidas para longe dos programadores. Foi só então que percebemos que elas eram efetivamente QA e, em certa medida, marketing também. Além de detectar erros, elas eram as guardiãs do conhecimento de coisas mais vagas, semelhantes a erros, como recursos que confundiam os usuários. [6] Elas também eram uma espécie de grupo de foco por procuração; poderíamos perguntar a elas qual de duas novas funcionalidades os usuários queriam mais, e elas sempre estavam certas.
Moral
Ser capaz de lançar 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 funcionou para recursos maiores também. Mesmo que algo levasse duas semanas para ser escrito (poucos projetos levavam mais tempo), eu sabia que poderia ver o efeito no software assim que estivesse pronto.
Se eu tivesse que esperar um ano para a próxima versão, teria arquivado a maioria dessas ideias, pelo menos por um tempo. A coisa sobre ideias, no entanto, é que elas levam a mais ideias. Você já notou que quando você se senta para escrever algo, metade das ideias que acabam nele são ideias que você teve enquanto escrevia? A mesma coisa acontece com o software. Trabalhar para implementar uma ideia lhe dá mais ideias. Então, arquivar uma ideia custa não apenas esse atraso na implementação, mas também todas as ideias que a implementação 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 a próxima versão".
O que as grandes empresas fazem em vez de implementar recursos é planejá-los. Na Viaweb, às vezes tínhamos problemas com essa conta. Investidores e analistas nos perguntavam o que tínhamos planejado para o futuro. A resposta verdadeira teria sido que não tínhamos nenhum plano. 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 parecia ser a maior vitória. Não sei se eu jamais 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 maioria dos códigos tinha um proprietário definido. Mas quando você era dono de algo, você realmente era dono: ninguém, exceto o dono de um pedaço de software, precisava aprovar (ou mesmo saber) um lançamento. Não havia proteção contra quebra, exceto o medo de parecer um idiota para seus colegas, e isso era mais do que suficiente. Posso ter dado a impressão de que simplesmente avançávamos alegremente escrevendo código. Nós realmente fomos rápidos, mas pensamos muito cuidadosamente antes de lançar o software nesses servidores. E prestar atenção é mais importante para a confiabilidade do que se mover lentamente. Porque 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 em movimento, à 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 programadores bons e confiáveis do que para uma grande empresa de programadores medíocres, onde as 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 exige menos programadores. Já trabalhei para uma empresa de software para desktop de médio porte que tinha mais de 100 pessoas trabalhando em engenharia como um todo. Apenas 13 dessas estavam no desenvolvimento de produtos. Todos os outros estavam trabalhando em lançamentos, portas 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, portas e assim por diante.
A Viaweb foi escrita por apenas três pessoas. [7] Eu sempre estava 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, economiza mais do que dinheiro. Como Fred Brooks apontou em O Mito do Homem-Mês, adicionar pessoas a um projeto tende a desacelerá-lo. O número de conexões possíveis entre os desenvolvedores cresce exponencialmente com o tamanho do grupo. Quanto maior o grupo, mais tempo eles passarão em reuniões negociando como seu software funcionará em conjunto e mais erros 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 me lembro dos programadores da Viaweb jamais tendo uma reunião real. Nunca tínhamos mais para dizer em um determinado 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 certa medida, administradores de sistemas 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 as 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 limitado nossas opções de design. E, 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 possa ser de outra forma, enquanto você ainda estiver desenvolvendo ativamente o produto. O software baseado na Web nunca será algo que você escreve, verifica e vai para casa. É uma coisa viva, rodando em seus servidores agora. Um erro grave pode não apenas travar o processo de um usuário; pode travar todos eles. Se um erro em seu código corromper alguns dados no disco, você tem que corrigi-lo. E assim por diante. Descobrimos que você não precisa ficar de olho nos 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 lança código tarde da noite e depois vai para casa.
Observando os Usuários
Com o 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á viu alguém usar seu software pela primeira vez, sabe que surpresas devem tê-los aguardado.
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é que você os observe. E o software baseado em servidor lhe dá informações sem precedentes sobre seu comportamento. Você não se limita a pequenos grupos de foco artificiais. Você pode ver cada clique feito por cada usuário. Você tem que considerar cuidadosamente o que vai olhar, porque você 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 em seu servidor, você não precisa depender de benchmarks, por exemplo. Benchmarks são usuários simulados. Com o 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 da Viaweb chegasse ao ponto em que ele era 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 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 abaixo dos concorrentes e ainda obter 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 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ó o usavam quando os estilos de página predefinidos não conseguiam 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 à esquerda lado, fizemos isso uma opção (na verdade, o padrão) nos estilos de página predefinidos.
Finalmente, observando os usuários, você geralmente pode 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 foi o teste de condução online. Não era apenas uma série de slides construídos por profissionais de marketing. Em nosso teste de condução, os usuários realmente usaram o software. Levou cerca de cinco minutos e, no final, eles construíram uma loja real e funcionando.
O teste de condução 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 teste de condução com sucesso, eles gostarão do produto. Se eles ficarem confusos ou entediados, não vão. Portanto, qualquer coisa que pudéssemos fazer para que mais pessoas passassem pelo teste de condução aumentaria nossa taxa de crescimento.
Estudei os rastros de cliques de pessoas fazendo o teste de condução e descobri que em uma determinada etapa elas ficavam confusas e clicavam no botão Voltar do navegador. (Se você tentar escrever aplicativos baseados 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 de não clicar no botão Voltar. Outra coisa ótima sobre o software baseado na Web é que você recebe feedback instantâneo das alterações: o número de pessoas que concluíram o teste de condução aumentou imediatamente de 60% para 90%. E como o número de novos usuários era uma função do número de testes de condução concluídos, nosso crescimento de receita aumentou 50%, apenas com essa mudança.
Dinheiro
No início da década de 1990, li um artigo em que alguém disse que o software era um negócio de assinatura. No início, isso parecia uma declaraçã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 continuem pagando a você. E, felizmente, as assinaturas são a maneira natural de cobrar por aplicativos baseados na Web.
Hospedar aplicativos é uma área onde 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 as empresas, os 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 com o fato de um novo modelo fracassar; 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 inadimplentes; 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 sendo um problema. Uma certa quantidade de pirataria é vantajosa para as empresas de software. Se algum usuário realmente não tivesse comprado seu software a nenhum 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, o que significa cobrar de cada cliente o máximo que 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 caixas Intel: uma empresa que usa Suns não está interessada em economizar dinheiro e pode ser cobrada com segurança 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, eles terão que encontrar outra solução.
O software baseado na Web vende bem, especialmente em comparação com o software de desktop, porque é fácil de comprar. Você pode pensar que as pessoas decidem comprar algo e depois compram, como duas etapas separadas. Era o que eu pensava antes da Viaweb, na medida em que pensava na 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 queriam ou não. E vice-versa: você venderá mais de algo quando for fácil de comprar. Compro mais livros porque a Amazon existe. O software baseado na Web é quase 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 inserir um número de cartão de crédito. (Faça-os fazer mais por sua conta e risco.)
Às vezes, o software baseado na Web é oferecido por meio de ISPs atuando como revendedores. Esta é uma má ideia. Você tem que estar administrando os servidores, porque precisa estar constantemente melhorando o hardware e 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 de nossos concorrentes se atiraram no pé dessa maneira - geralmente, acho, porque foram dominados por ternos que estavam animados com esse enorme canal 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 experimentar coisas novas, em parte porque são mais flexíveis e em parte porque desejam os custos mais baixos da nova tecnologia.
Os aplicativos baseados na Web geralmente serão a melhor coisa para grandes empresas também (embora elas demorem para perceber). A melhor intranet é a Internet. Se uma empresa usar 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 gira em torno da segurança: se o acesso for 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 de 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 eram 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 preocupadas com a segurança, mas também nos preocupávamos mais com ela. 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 levar uma pessoa a ser demitida. Se alguém invadisse a nossa, isso poderia afetar milhares de comerciantes, provavelmente acabaria como notícia na CNet e poderia nos levar à falência.
Se você quiser manter seu dinheiro seguro, você o mantém embaixo do seu colchão em casa ou o coloca em um banco? Esse argumento se aplica a todos os aspectos da administração do servidor: 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 com o servidor eram o grande não-não para nós, como um brinquedo perigoso seria para um fabricante de brinquedos, ou uma epidemia de salmonela para um processador de alimentos.
Uma grande empresa que usa aplicações baseadas na Web está, nesse sentido, externalizando 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 mal-humorados e não responderem 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 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 saltávamos; só de pensar nisso me dá um choque de adrenalina, anos depois.
Então, as aplicações baseadas na Web serão normalmente a resposta certa para grandes empresas também. No entanto, elas serão as últimas a perceber isso, assim como foram com os computadores de mesa. E em parte pelo mesmo motivo: valerá muito dinheiro para convencer as grandes empresas de que precisam de algo mais caro.
Há sempre uma tendência para os 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, estávamos sempre lutando contra isso. Perdemos vários comerciantes de alto nível para empresas de consultoria Web que os convenceram de que ficariam melhor se pagassem meio milhão de dólares por uma loja online personalizada em seu próprio servidor. Eles, como regra, não estavam melhor, como mais de um descobriu quando a época de compras de Natal chegou e as cargas aumentaram em seu servidor. A Viaweb era muito mais sofisticada do que a maioria desses comerciantes obteve, mas não podíamos nos dar ao luxo de dizer a eles. A US$ 300 por mês, não podíamos nos dar ao luxo de enviar uma equipe de pessoas bem vestidas e com um som autoritário para fazer apresentações aos clientes.
Uma grande parte do que as grandes empresas pagam a mais é o custo de vender coisas caras a 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 esta é uma das razões pelas quais o software de 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 é novidade. Na verdade, é o modelo antigo: as aplicações de mainframe são todas baseadas em servidor. Se o software baseado em servidor é uma ideia tão boa, por que ele perdeu da última vez? Por que os computadores de mesa eclipsaram os mainframes?
No início, os computadores de mesa não pareciam uma grande ameaça. Os primeiros usuários eram todos hackers - ou entusiastas, 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 na fase inicial. Muitas startups começam quase por acaso - como um casal de caras, com empregos diurnos ou na escola, escrevendo um protótipo de algo que pode, se parecer promissor, se transformar em uma empresa. Nesta fase larval, qualquer obstáculo significativo interromperá a startup. Escrever software de mainframe exigia muito compromisso adiantado. As máquinas de desenvolvimento eram caras e, como os clientes seriam grandes empresas, você precisaria de uma força de vendas de aparência impressionante para vendê-la a eles. Começar uma startup para escrever software de mainframe seria um empreendimento muito mais sério do que apenas hackear algo em seu Apple II à noite. E assim, você não teve muitas startups escrevendo aplicações de mainframe.
A chegada dos computadores de mesa inspirou muitos softwares novos, 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 por meio de lojas de informática ou até mesmo por encomenda.
A aplicação que impulsionou os computadores de mesa para a corrente principal foi VisiCalc, a primeira planilha. Foi escrito por dois caras trabalhando em um sótão, e ainda assim fez coisas que nenhum software de mainframe podia 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 este foi o início 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 fizemos, usando um computador de mesa como servidor. Os processadores baratos comeram o mercado de estações de trabalho (você raramente ouve a palavra agora) e estão na maior parte do caminho através do mercado de servidores; os servidores do Yahoo, que lidam com cargas tão altas quanto qualquer um na Internet, todos têm os mesmos processadores Intel baratos que você tem em seu computador de mesa. E depois de escrever o software, tudo o que você precisa para vendê-lo é um site. Quase todos os nossos usuários vieram diretamente para nosso site por meio de boca a boca e referências na imprensa. [12]
A Viaweb era uma startup larval típica. Estávamos apavorados em começar uma empresa e, nos primeiros meses, nos consolamos tratando o todo 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 as 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, faça isso nos termos da Microsoft, chamando suas APIs e contornando seu sistema operacional com bugs. E se você conseguir escrever algo que decole, pode descobrir que estava apenas fazendo pesquisa de mercado para a Microsoft.
Se uma empresa quiser criar uma plataforma na qual as startups construirão, ela tem que torná-la algo que os próprios hackers queiram usar. Isso significa que tem que 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 pessoa que é boa em escrever software tende a estar executando 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 o Windows, teríamos que usá-lo. A Web nos permitiu fazer um desvio do Windows e entregar software rodando no Unix diretamente aos usuários por meio 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 que todos temiam. É difícil imaginar agora, mas me lembro muito bem da sensação. Agora o gigante assustador é a Microsoft, e não acho que eles sejam tão cegos à ameaça que enfrentam quanto a IBM era. Afinal, a Microsoft deliberadamente construiu seu negócio no ponto cego da IBM.
Mencionei antes que minha mãe não precisa realmente de um computador de mesa. A maioria dos usuários provavelmente não precisa. Esse é um problema para a Microsoft, e eles sabem disso. Se as aplicações forem executadas 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 funciona junto com os servidores que eles controlam. No mínimo, os arquivos estarão centralmente disponíveis para os usuários que desejarem 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 evitar. Se você só precisa de um navegador para um cliente, você não precisa da Microsoft no cliente e, se a Microsoft não controla o cliente, ela não pode direcionar os usuários para suas aplicações baseadas em servidor.
Acho que a Microsoft terá dificuldades em manter o gênio na garrafa. Haverá muitos tipos diferentes de clientes para que eles controlem todos. E se os aplicativos da Microsoft só funcionarem 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á um 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 o mundo dos aplicativos de desktop.
Não é tanto que um concorrente os atrapalhe, mas que eles tropeçarão em si mesmos. Com o surgimento do software baseado na Web, eles enfrentarão não apenas problemas técnicos, mas também seus próprios desejos. O que eles precisam fazer é canibalizar seus negócios existentes, e não consigo vê-los enfrentando isso. A mesma teimosia que os levou até aqui agora estará trabalhando contra eles. A IBM estava exatamente na mesma situação, e eles não conseguiram dominar. A IBM fez uma entrada tardia e hesitante no negócio de microcomputadores porque era ambivalente em relação a ameaçar sua vaca leiteira, a computação de mainframe. A Microsoft também será prejudicada por querer salvar o desktop. Uma vaca leiteira pode ser um macaco muito pesado nas suas costas.
Não estou dizendo que ninguém vai dominar as aplicações baseadas em servidor. Alguém provavelmente vai eventualmente. Mas acho que haverá um bom período de caos alegre, assim como houve nos primeiros dias dos microcomputadores. Era uma boa época para startups. Muitas pequenas empresas floresceram e o fizeram criando coisas legais.
Startups, mas ainda 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 eles vencerem, vencerão em grande estilo.
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 alocado 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 usando jeans para o escritório e digitando em vt100s. Agora são dois caras sentados em uma sala de estar com laptops. (E o jeans acaba não sendo a última palavra em informalidade.)
As startups são estressantes, e isso, infelizmente, também é levado ao extremo com aplicativos baseados na Web. Muitas empresas de software, especialmente no início, têm períodos em que os desenvolvedores dormiam embaixo de suas mesas e assim por diante. O que é alarmante sobre o software baseado na Web é que não há nada para impedir que isso se torne o padrão. As histórias sobre dormir embaixo de mesas geralmente terminam: então finalmente lançamos e todos fomos para casa e dormimos por uma semana. O software baseado na Web nunca é lançado. 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 fazer isso. Você pode, então você deve. É a Lei de Parkinson funcionando ao contrário.
O pior não são as horas, mas a responsabilidade. Programadores e administradores de sistemas tradicionalmente têm suas próprias preocupações separadas. Os programadores têm que se preocupar com bugs e os administradores de sistemas têm que se preocupar com a infraestrutura. Os 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. Os administradores de sistemas nunca deixam o trabalho completamente, mas quando são chamados às 4h da manhã, 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. Trabalhávamos 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 colocamos usuários em nosso servidor. O segundo maior benefício de vender a Viaweb para o Yahoo (depois do dinheiro) foi poder transferir a responsabilidade final por tudo para os ombros de uma grande empresa.
O software de desktop força os usuários a se tornarem administradores de sistemas. O software baseado na Web força os programadores a fazerem 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] As aplicações baseadas na Web oferecem uma forma direta de superar seus concorrentes. Nenhuma startup pede mais do que isso.
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 interface do usuário. Esse é um problema, eu 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 dessas máquinas não eram realmente destinados a 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 eles eram apenas bons o suficiente. Você poderia combinar um desses chips com alguma memória (256 bytes no primeiro Altair) e interruptores de painel frontal, e você teria um computador funcionando. 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 interface do usuário para aplicativos, mas são apenas boas o suficiente. E para um número significativo de usuários, o software que você pode usar em qualquer navegador será uma vitória em si mesma para superar qualquer incômodo na interface do usuário. Talvez você não consiga escrever a planilha mais bonita usando HTML, mas você pode escrever uma planilha que várias pessoas podem usar simultaneamente de diferentes locais sem software de cliente especial, ou que pode incorporar feeds de dados ao vivo, ou que pode avisá-lo quando certas condições são acionadas. Mais importante ainda, você pode escrever novos tipos de aplicativos que ainda não têm nome. O VisiCalc não era apenas uma versão de microcomputador de um aplicativo de mainframe, afinal - era um novo tipo de aplicativo.
Claro, as 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 é 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 fariam isso - mas se eles não fizerem, você está ferrado. Porque 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 crescerá à medida que novos dispositivos da Web proliferarem. Os usuários vão gostar 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 acompanhei a evolução da Web de perto como qualquer outra pessoa e não consigo prever o que vai acontecer com os clientes. A convergência provavelmente está chegando, mas para onde? Não consigo escolher um vencedor. Uma coisa que posso prever é o conflito entre AOL e Microsoft. Seja o que for que o .NET da Microsoft se torne, provavelmente envolverá conectar o desktop a servidores. A menos que a AOL revide, eles serão empurrados para o lado ou transformados em um cano entre o cliente da Microsoft e o software do servidor. 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 os únicos que funcionam em todos os lugares.
Como tudo isso vai acontecer? Eu 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á funcionando por muito tempo. Os aplicativos baseados na Web são baratos de desenvolver e fáceis de entregar até mesmo para a menor startup. Eles dão muito trabalho, e de um tipo particularmente estressante, mas isso só aumenta as chances para as startups.
Por que não?
E. B. White achou divertido 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, "Aproveitem 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 fazer isso. Uma é que você não sabe nada sobre negócios. A outra é que você tem medo da competição. Nenhuma dessas cercas tem corrente.
Existem apenas duas coisas que você precisa saber sobre negócios: construir algo que os usuários adorem e gastar menos do que ganha. Se você acertar essas duas coisas, estará à frente da maioria das startups. Você pode descobrir o resto à medida que avança.
Você pode não ganhar mais do que gasta no início, mas contanto que a diferença esteja diminuindo rápido o suficiente, você estará bem. Se você começar com pouco dinheiro, isso pelo menos incentivará o hábito da frugalidade. Quanto menos você gastar, mais fácil será ganhar mais do que gasta. Felizmente, pode ser muito barato lançar um aplicativo baseado na Web. Lançamos o nosso 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 pelo tráfego de dados. Você poderia 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 adorem, aqui estão algumas dicas gerais. Comece criando algo limpo e simples que você gostaria de usar. Crie uma versão 1.0 rapidamente e continue a melhorar o software, ouvindo atentamente os usuários enquanto o faz. O cliente sempre tem razão, mas clientes diferentes têm razão 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 opções dos usuários. Não se torne complacente se o software de seus concorrentes for ruim; o padrão para comparar seu software é o que ele poderia ser, não o que seus concorrentes atuais acontecem de ter. Use seu software você mesmo, o tempo todo. O Viaweb era para ser um construtor de lojas online, mas também o usamos para criar nosso próprio site. Não ouça os profissionais de marketing, designers ou gerentes de produto apenas por causa de seus cargos. Se eles tiverem boas ideias, use-as, mas cabe a você decidir; o software tem que 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 competição. O que você tem medo não são presumivelmente grupos de hackers como você, mas empresas reais, com escritórios, planos de negócios, 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 um escritório ou contratar vendedores do que para uma empresa de qualquer tamanho conseguir que o software seja escrito. Já 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 em água até a cintura.
Não quero menosprezar o Yahoo. Eles tinham alguns bons hackers, e a alta gerência era realmente implacável. Para uma grande empresa, eles eram excepcionais. Mas eles 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 consegue desenvolver software. Eles são como uma montanha que pode andar.
Não se intimide. Você pode fazer tanto quanto a Microsoft não pode, assim como eles podem fazer o que você não pode. E ninguém pode te impedir. 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 conseguir espaço nas prateleiras de lojas de varejo, ou implorar para que seu aplicativo seja incluído no sistema operacional. Você pode entregar o 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 prometo a você, a Microsoft tem medo de você. Os gerentes médios complacentes podem não ter, mas o Bill tem, porque ele já foi você, em 1975, a última vez que uma nova maneira de entregar software apareceu.
Notas
[1] Percebendo que muito do dinheiro está nos serviços, as 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 executar um serviço online, e em parte porque os usuários odeiam a ideia. Dar a gilete de graça e ganhar dinheiro com as lâminas pode funcionar para a Gillette, mas uma gilete é muito menor compromisso do que um terminal Web. Os fabricantes de telefones celulares estão satisfeitos em vender hardware sem tentar capturar o serviço receita também. Esse provavelmente deveria ser o modelo para a Internet clientes também. Se alguém apenas vendesse uma caixa pequena e bonita com um navegador da Web que você poderia usar para se conectar por meio de qualquer ISP, todos tecnofóbicos do país comprariam um.
[2] A segurança sempre depende mais de não estragar do que de qualquer design decisão, mas a natureza do software baseado em servidor fará com que os desenvolvedores prestem mais atenção a não estragar. Comprometer um servidor poderia causar tanto dano que os ASPs (que querem permanecer no negócio) são provavelmente cuidadosos com a segurança.
[3] Em 1995, quando começamos o Viaweb, os applets Java eram para ser a tecnologia que todos iriam usar para desenvolver servidores aplicativos. Applets nos pareciam uma ideia antiquada. Baixar programas para executar no cliente? Mais simples apenas ir até o fim e executar os programas no servidor. Perdemos pouco tempo com applets, mas inúmeras outras startups devem ter sido atraídas para essa poça de piche. Poucos podem ter escapado vivos, ou a Microsoft não poderia ter se safado com a queda do Java na versão mais recente do Explorador.
[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 a ser encontrado pode ser uma variante de composto bug onde um bug acontece para compensar outro. Quando você corrige um bug, o outro se torna visível. Mas parecerá que o correção é a culpada, já que foi a última coisa que você mudou.
[6] Dentro do Viaweb, uma vez tivemos um concurso para descrever o pior sobre nosso software. Duas pessoas de suporte ao cliente empataram para o primeiro prêmio com entradas que ainda me fazem tremer ao lembrar. Corrigimos os dois 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 gerente, 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 gerente principalmente em Perl, e o editor em Lisp.
[8] A discriminação de preços é tão generalizada (quantas vezes você já ouviu um varejista alegar que seu poder de compra significava preços mais baixos para você?) que fiquei surpreso ao descobrir que era proibido nos EUA por a Lei Robinson-Patman de 1936. Esta lei não parece ser vigorosamente aplicada.
[9] Em No Logo, Naomi Klein diz que as marcas de roupas favorecidas por "jovens urbanos" não tentam muito impedir furtos 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 seja 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 um par de dias, então ao longo do próximo ano 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", escreveu Bob, "Se falhasse, falhasse. Sem problemas."
[12] Não é tão fácil quanto eu 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 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 lançou um enxame de fornecedores de componentes baratos no hardware da Apple. Também não ajudou que os ternos assumissem o controle durante um período crítico.
[14] Uma coisa que ajudaria as aplicações baseadas 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 software corporativo por tanto tempo. Um navegador pequeno e rápido que fosse ativamente mantido seria uma ótima coisa em si, e provavelmente também encorajaria as 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, Perl). Seria muito útil para as aplicações baseadas na Web poderem distinguir entre selecionar um link e segui-lo; tudo o que você precisaria fazer seria uma melhoria trivial do HTTP, para permitir vários URLs em uma solicitação. Menus em cascata também seriam bons.
Se você quiser mudar o mundo, escreva um novo Mosaic. Acha que é tarde demais? Em 1998, muitas pessoas pensaram que era tarde demais para lançar um novo mecanismo de pesquisa, 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 pessoal do que qualquer um, 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. 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çar ao máximo. Como o capital não é mais necessário, as grandes empresas têm pouco a oferecer."
[16] Na versão original deste ensaio, eu aconselhei a evitar Javascript. Era um bom plano em 2001, mas Javascript agora funciona.
Obrigado 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 VisiCalc; e novamente a Ken Anderson por me convidar a falar na BBN.
Você encontrará este ensaio e outros 14 em Hackers & Painters.