O OUTRO CAMINHO À FRENTE
OriginalSetembro de 2001
(Este artigo explica por que grande parte da próxima geração de software pode ser baseada em servidores, 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 iniciar uma startup. A campanha de relações públicas que antecedeu a oferta pública inicial da Netscape estava em pleno andamento naquela é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 um software para criar elas, então decidimos escrever um.
Durante a primeira semana ou mais, tínhamos a intenção de fazer isso um aplicativo de desktop comum. Então, um dia, tivemos a ideia de fazer o software ser executado em nosso servidor Web, usando o navegador como interface. Tentamos reescrever o software para funcionar pela Web, e ficou claro que esse era o caminho a seguir. Se escrevêssemos nosso software para ser executado no servidor, seria muito mais fácil para os usuários e para nós também.
Isso se provou 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 dissemos que o software era executado no servidor. Só foi 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. Há um nome agora para o que éramos: um Provedor de Serviços de Aplicativos, ou ASP.
Acho que muita da próxima geração de software será escrita nesse modelo. Até a Microsoft, que tem mais a perder, parece ver a inevitabilidade de mover algumas coisas 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 surpreendentes coisas que vimos, como alguns dos primeiros visitantes deste novo mundo. Na medida em que o software se mover para servidores, o que estou descrevendo aqui é o futuro.
O Próximo Passo?
Quando olharmos para a era do software de desktop, acho que nos maravilharemos com os inconvenientes que as pessoas suportavam, assim como nos maravilhamos agora com o que os primeiros proprietários de carros suportavam. Pelos primeiros vinte ou trinta anos, você tinha que ser um especialista em carros para ter um carro. Mas os carros eram uma grande vitória, então 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 desktop, você acaba aprendendo muito mais do que queria saber sobre o que está acontecendo dentro dele. Mas mais da metade dos lares nos EUA possuem um. Minha mãe tem um computador que ela usa para e-mail e para manter as 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 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 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 sistemas. Aplicativos baseados na Web são programas que são executados em servidores Web e usam páginas da Web como a interface do usuário. Para o usuário médio, esse novo tipo de software será mais fácil, mais barato, mais móvel, mais confiável e, muitas vezes, mais poderoso do que o software de desktop.
Com software baseado na Web, a maioria dos usuários não precisará pensar em nada, exceto nos aplicativos que usam. Todo o material sujo e em constante mudança ficará em algum servidor, mantido por pessoas que são boas nesse tipo de coisa. E, portanto, você normalmente não precisará de um computador, em si, para usar o 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 telefone celular. Seja o que for, será eletrônica de consumo: algo que custa cerca de $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 chegar ao servidor e voltar, então os usuários de software altamente interativo, como o Photoshop, ainda vão querer que os cálculos aconteçam no computador de mesa. Mas, se você olhar para o tipo de coisas que a maioria das pessoas usa os computadores, um atraso 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.
O Ganho 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 maior parte do tempo, escolherá a opção que exigir menos trabalho. Se o software baseado na Web vencer, será porque é mais conveniente. E parece que será, tanto para os usuários quanto para os 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, só pode usá-lo naquele computador. Pior ainda, seus arquivos ficam presos naquele computador. O inconveniente desse modelo fica 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 às 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 não editá-lo? Por que qualquer um dos seus dados deve ficar preso em algum computador sentado em uma mesa distante?
A ideia de "seu computador" está desaparecendo e sendo substituída por "seus dados". Você deve poder acessar 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, à medida que os clientes ficam menores, você tem outro motivo para não manter seus dados neles: algo que você carrega consigo pode ser perdido ou roubado. Deixar seu PDA em um táxi é como uma falha de disco, exceto que seus dados são entregues a outra pessoa em vez de serem 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 é 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 poder testar qualquer aplicativo baseado na Web gratuitamente, apenas visitando o site onde ele é oferecido. Na Viaweb, todo o nosso site era como uma grande seta apontando os usuários para o teste.
Depois de experimentar a demonstração, inscrever-se no serviço não deve exigir mais do que preencher um breve formulário (quanto mais breve, melhor). E isso deve ser o último trabalho que o usuário precisa fazer. Com software baseado na Web, você deve receber novas versões sem pagar extra, fazer qualquer trabalho ou, possivelmente, até mesmo saber sobre isso.
Upgrades não serão os grandes choques que são agora. Com o tempo, os aplicativos crescerão silenciosamente mais poderosos. Isso exigirá algum esforço por parte dos desenvolvedores. Eles terão que projetar software de forma 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. Portanto, o software baseado na Web deve ter muito menos bugs do que o software de desktop. Na Viaweb, duvido que tenhamos tido dez bugs conhecidos ao mesmo tempo. Isso é ordens de magnitude melhor do que o software de desktop.
Os aplicativos baseados na Web podem ser usados por várias pessoas ao mesmo tempo. Isso é uma vitória óbvia para aplicativos de colaboração, mas eu aposto que os usuários começarão a querer isso na maioria dos aplicativos assim que perceberem que é possível. Muitas vezes será útil permitir que duas pessoas editem o mesmo documento, por exemplo. A Viaweb permitia que vários usuários editassem um site simultaneamente, mais porque essa era a maneira certa de escrever o software do que porque esperávamos que os usuários quisessem, mas acabou que muitos queriam.
Quando você usa um aplicativo baseado na Web, seus dados estarão mais seguros. Falhas de disco não serão coisa do passado, mas os usuários não ouvirão mais sobre elas. Elas acontecerão dentro de fazendas de servidores. E as empresas que oferecem aplicativos baseados na Web realmente farão backups - não apenas porque terão administradores de sistemas reais se preocupando com essas coisas, mas porque um ASP que perder os dados das pessoas estará em grandes, grandes problemas. Quando as pessoas perdem seus próprios dados em uma falha de disco, elas não podem ficar muito bravas, porque só têm a si mesmas para ficar bravas. Quando uma empresa perde seus dados por 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 a ser danificado. 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 dentro do usuário médio do Windows, encontraria um desejo enorme e praticamente inexplorado por software que atenda a essa descrição. Liberado, poderia ser uma força poderosa.
Cidade de Código
Para os desenvolvedores, a diferença mais conspícua entre o software baseado na Web e o de desktop é que um aplicativo baseado na Web não é um único pedaço de código. Será uma coleção de programas de diferentes tipos, em vez de um único grande binário. E, portanto, projetar software baseado na Web é como projetar uma cidade, em vez de um prédio: além de prédios, você precisa de estradas, placas de rua, serviços públicos, polícia e corpo de bombeiros, e planos tanto para o crescimento quanto para vários tipos de desastres.
Na Viaweb, o software incluía aplicativos relativamente grandes com os quais os usuários conversavam diretamente, programas que esses programas usavam, programas que eram executados constantemente em segundo plano procurando por 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 ou 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 acionava uma impressionante coleção de mostradores exibindo estatísticas de servidor em tempo real (um sucesso com os visitantes, mas indispensável para nós também), modificações (incluindo correções de bugs) em software de código aberto e muitos arquivos de configuração e configurações. Trevor Blackwell escreveu um programa espetacular para mover lojas para novos servidores em todo o país, sem fechá-las, depois que fomos comprados pela Yahoo. Os programas nos enviavam mensagens, 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 soquetes, pipes, solicitações http, ssh, pacotes udp, memória compartilhada e arquivos. Parte da 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 possam usar para invadir seus servidores.
Não terminou com 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. Tivemos que pensar se nosso provedor de internet upstream tinha conexões rápidas o suficiente com todas as backbones. Nós datamos fornecedores de RAID em série.
Mas o hardware não é apenas algo com o que se preocupar. Quando você o controla, pode fazer mais pelos usuários. Com um aplicativo de desktop, você pode especificar determinado hardware mínimo, mas não pode adicionar mais. Se você administrar os servidores, você pode, em uma única etapa, habilitar todos os seus usuários a enviar páginas, enviar faxes, enviar comandos por telefone, processar cartões de crédito, etc., apenas instalando o hardware relevante. Sempre procuramos novas maneiras de adicionar recursos com hardware, não apenas porque agradava aos usuários, mas também como uma maneira de nos distinguirmos da concorrência que (seja porque vendiam software de desktop ou revendiam aplicativos baseados na Web por meio de provedores de serviços de internet) 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 - significando C e C++. E assim essas linguagens (especialmente entre pessoas não técnicas, como gerentes e VCs) passaram a ser consideradas as linguagens para o 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é mesmo Lisp.
Com software baseado em servidor, ninguém pode lhe dizer que 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 uma. E quando você tem concorrentes, "você pode" significa "você deve" (voltaremos a isso mais tarde), porque se você não aproveitar essa possibilidade, seus concorrentes o farão.
A maioria de nossos concorrentes usava C e C++, e isso tornava seu software visivelmente inferior porque (entre outras coisas) eles não tinham como contornar a falta de estado dos scripts CGI. Se você fosse mudar algo, todas as alterações teriam 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 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 de desktop, fazer um lançamento é um enorme trauma, no qual toda a empresa sua e se esforça para empurrar um único e gigantesco pedaço de código. Comparações óbvias sugerem-se, 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 mudanças incrementais em vez de uma grande explosão ocasional. Uma típica empresa de software de desktop pode fazer uma ou duas versões por ano. Na Viaweb, muitas vezes fazíamos três a cinco versões por dia.
Quando você muda para esse novo modelo, você percebe o quanto o desenvolvimento de software é afetado pela maneira como ele é lançado. Muitos dos problemas mais desagradáveis que você vê no negócio de software de desktop são devido à natureza catastrófica dos lançamentos.
Quando você lança apenas uma nova versão por ano, você tende a lidar com bugs em atacado. Algum tempo antes da data de lançamento, você monta uma nova versão na qual metade do código foi arrancada e substituída, introduzindo inúmeros bugs. Então uma equipe de pessoas de controle de qualidade entra e começa a contá-los, e os programadores trabalham na lista, consertando-os. Eles geralmente não chegam ao final da lista, e de fato, ninguém tem certeza de onde está o final. É como pescar escombros de um lago. Você nunca realmente sabe o que está acontecendo dentro do software. Na melhor das hipóteses, você acaba com uma espécie de correção estatística.
Com software baseado em servidor, a maior parte da mudança é pequena e incremental. Isso por si só é menos provável de introduzir bugs. Também significa que você sabe o que testar com mais cuidado quando você está prestes a lançar o software: a última coisa que você mudou. Você acaba tendo um domínio muito mais firme do código. Como regra geral, você realmente 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ê o faz como um piloto verificando 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é mesmo montou mecanismos para compensá-lo (por exemplo, lançamentos de patches). Então, por que se preocupar com alguns a mais? Em breve, você está lançando recursos inteiros que você sabe que estão quebrados. Apple fez isso no início deste ano. Eles sentiram pressão para lançar seu novo sistema operacional, cuja data de lançamento já havia sido adiada quatro vezes, mas algumas partes do software (suporte para CDs e DVDs) não estavam prontas. 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 muito 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 em uma determinada 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 no software baseado na Web.
Se alguém se lembra da Viaweb, isso pode soar estranho, porque sempre estávamos anunciando novas versões. Isso foi feito inteiramente para fins de relações públicas. A imprensa comercial, 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 simples fato de existirem parecia para nós evidência de seu atraso, eles receberiam todo o tipo de publicidade. Não queríamos ficar de fora, então começamos a dar números de versão ao nosso software também. Quando queríamos alguma publicidade, faríamos uma lista de todos os recursos que havíamos adicionado desde o "lançamento" anterior, colocaríamos um novo número de versão no software e emitiriamos um comunicado de imprensa dizendo que a nova versão estava disponível imediatamente. Surpreendentemente, ninguém nunca nos questionou sobre isso.
Quando fomos comprados, já havíamos feito isso três vezes, então estávamos na Versão 4. Versão 4.1, se me lembro corretamente. Depois que a Viaweb se tornou a 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 em 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 ao telefone com você. Você até pode saber disso já, se tiver um código para notar erros incorporado em seu aplicativo.
O software baseado na Web é usado 24 horas por dia, então tudo o que você faz é imediatamente submetido ao teste. Os bugs aparecem rapidamente.
As empresas de software às vezes são acusadas de deixar os usuários depurar seu software. E é exatamente isso que estou defendendo. Para o software baseado na Web, isso é realmente um bom plano, porque os bugs são menos frequentes e transitórios. Quando você lança o software gradualmente, você começa com muito menos bugs. E quando você pode reproduzir erros e lançar mudanças instantaneamente, você pode encontrar e corrigir a maioria dos bugs assim que eles aparecerem. Nunca tivemos bugs suficientes de uma só vez para nos incomodar com um sistema formal de rastreamento de bugs.
Você deve testar as alterações antes de lançá-las, é claro, então nenhum bug grave deve ser lançado. Aqueles poucos que inevitavelmente escapam envolverão casos limítrofes e afetarão apenas os poucos usuários que os encontrarem antes que alguém ligue para reclamar. Desde que você 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 algum 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ê muitas vezes sabe o que está errado antes mesmo de olhar o código-fonte, porque você já estava se preocupando com isso subconscientemente. Corrigir um bug em algo que você escreveu há seis meses (o caso médio se você lançar uma vez por ano) é muito mais trabalho. E como você não entende o código tão bem, você é mais propenso a corrigi-lo de uma maneira feia ou até mesmo introduzir mais bugs. [4]
Quando você pega os bugs cedo, você também obtém menos bugs compostos. Bugs compostos são dois bugs separados que interagem: você tropeça escada abaixo e, quando você alcança o corrimão, ele se solta em 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] A abordagem tradicional de "quebrar tudo e depois filtrar os bugs" inerentemente gera muitos bugs compostos. E o software que é lançado em uma série de pequenas alterações inerentemente tende a não ter. Os pisos estão constantemente sendo varridos de 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ê 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 partes substanciais dessa maneira. 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 grande parte do editor da Viaweb nesse estilo e fizemos nossa linguagem de script, RTML, uma linguagem puramente funcional.
As 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 provavelmente eram usuários avançados, empurrando os limites. Usuários avançados são mais tolerantes com relação a bugs, especialmente desde que você provavelmente os tenha introduzido no curso 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 muitas vezes se orgulhavam de pegar um. Eles ligariam para o suporte em um espírito mais de triunfo do que de raiva, como se tivessem marcado pontos contra nós.
Suporte
Quando você pode reproduzir erros, isso muda sua abordagem ao suporte ao cliente. Na maioria das empresas de software, o suporte é oferecido como uma maneira de fazer os clientes se sentirem melhor. Eles estão ligando sobre um bug conhecido ou apenas fazendo algo errado e você precisa descobrir o que é. Em qualquer caso, não há muito o que você possa aprender com eles. E então você tende a ver as ligações de suporte como uma dor de cabeça que você quer isolar de seus desenvolvedores o máximo possível.
Não foi assim que as coisas funcionaram na Viaweb. Na Viaweb, o suporte era gratuito, porque queríamos ouvir dos clientes. Se alguém tivesse um problema, queríamos saber sobre isso 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 de suporte ao cliente ficavam 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 real. Deixaríamos uma reunião do conselho para corrigir um bug grave.
Nossa abordagem ao suporte deixou todo mundo mais feliz. Os clientes ficaram encantados. Imagine como seria se você ligasse para uma linha de suporte e fosse tratado como alguém trazendo notícias importantes. As pessoas de suporte ao cliente gostaram porque significava que elas poderiam 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 corrigir bugs na hora mudou o relacionamento entre as pessoas de suporte ao cliente e os hackers. Na maioria das empresas de software, as pessoas de suporte são escudos humanos mal pagos, e os hackers são pequenas cópias do Pai Deus, criadores do mundo. Seja qual for o procedimento para relatar bugs, é provável que seja unidirecional: as pessoas de suporte que ouvem sobre bugs preenchem um formulário que eventualmente chega (possivelmente via QA) aos programadores, que o colocam em sua lista de tarefas. Era muito diferente na Viaweb.
Dentro de um minuto de ouvir sobre um bug de um cliente, as pessoas de suporte poderiam estar ao lado de um programador ouvindo-o dizer "Merda, você está certo, é um bug". Deliciava as pessoas de suporte ouvir esse "você está certo" dos hackers. Eles costumavam nos trazer bugs com o mesmo ar expectante de um gato trazendo um rato que acabou de matar. Também os tornava mais cuidadosos ao julgar a gravidade de um bug, porque agora sua honra estava em jogo.
Depois que fomos comprados pela Yahoo, as pessoas de suporte ao cliente foram movidas para longe dos programadores. Foi só então que percebemos que elas eram, de fato, QA e, em certa medida, marketing também. Além de capturar bugs, elas eram as guardiãs do conhecimento de coisas mais vagas e semelhantes a bugs, como recursos que confundiam os usuários. [[6]] Elas também eram uma espécie de grupo focal substituto; podíamos perguntar a elas qual dos dois novos recursos os usuários queriam mais, e elas sempre estavam certas.
Moral
Poder 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 a fazia naquele dia. Isso funcionava para recursos maiores também. Mesmo que algo fosse levar 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 pela próxima versão, eu 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 entrando são aquelas que você pensou enquanto estava escrevendo? A mesma coisa acontece com o software. Trabalhar para implementar uma ideia lhe dá mais ideias. Então, arquivar uma ideia lhe custa não apenas esse atraso na implementação, mas também todas as ideias que a implementação teria gerado. Na verdade, arquivar uma ideia provavelmente até inibe novas ideias: quando você começa a pensar em algum novo recurso, você vê 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 nos metíamos em problemas por causa disso. Investidores e analistas nos perguntariam o que tínhamos planejado para o futuro. A resposta verdadeira teria sido: 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 faríamos nos próximos seis meses? O que parecesse ser o maior ganho. Não sei se alguma vez me atrevi a dar essa resposta, mas essa era a verdade. Planos são apenas outra palavra para ideias na prateleira. Quando pensávamos em boas ideias, as implementávamos.
Na Viaweb, como em muitas empresas de software, a maior parte do código tinha um proprietário definitivo. Mas quando você era o proprietário, você realmente era: ninguém, exceto o proprietário de um pedaço de software, precisava aprovar (ou mesmo saber sobre) um lançamento. Não havia proteção contra quebras, exceto o medo de parecer um idiota para seus pares, e isso era mais do que suficiente. Posso ter dado a impressão de que simplesmente avançávamos escrevendo código. Nós realmente íamos rápido, mas pensávamos muito cuidadosamente antes de lançar software nesses servidores. E prestar atenção é mais importante para a confiabilidade do que se mover lentamente. Porque presta atenção, um piloto da Marinha pode pousar uma aeronave de 40.000 libras a 140 milhas por hora em um convés de navio em movimento, à noite, com mais segurança do que o adolescente médio pode cortar um bagel.
Esta forma de escrever software é uma faca de dois gumes, é claro. Funciona muito melhor para uma pequena equipe de bons programadores confiáveis do que para uma grande empresa de medíocres, onde as más ideias são interceptadas por comitês em vez das pessoas que as tiveram.
Brooks em Reverso
Felizmente, o software baseado na Web requer menos programadores. Eu já trabalhei para uma empresa de software desktop de médio porte que tinha mais de 100 pessoas trabalhando na engenharia como um todo. Apenas 13 deles estavam no desenvolvimento de produtos. Todos os outros estavam trabalhando em lançamentos, portos 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, portos e assim por diante.
O Viaweb foi escrito 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 alto preço 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 lhe economiza mais do que dinheiro. Como Fred Brooks apontou em The Mythical Man-Month, adicionar pessoas a um projeto tende a desacelerá-lo. O número de conexões possíveis entre desenvolvedores cresce exponencialmente com o tamanho do grupo. Quanto maior o grupo, mais tempo eles gastarão em reuniões negociando como seu software funcionará juntos, e mais bugs eles obterão de interações imprevistas. Felizmente, esse processo também funciona ao contrário: à medida que os grupos ficam menores, o desenvolvimento de software fica exponencialmente mais eficiente. Eu não me lembro dos programadores do Viaweb tendo uma reunião real. Nunca tínhamos mais a 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 precisa estar monitorando os servidores, e na prática, as únicas pessoas que podem fazer isso adequadamente são as que escreveram o software. No Viaweb, nosso sistema tinha tantos componentes e mudava tão frequentemente que não havia uma fronteira definida entre software e infraestrutura. Declarar arbitrariamente tal fronteira teria restringido nossas opções de design. E então, embora estivéssemos constantemente esperando que um dia ("em um par de meses") tudo ficasse estável o suficiente para que pudéssemos contratar alguém cujo trabalho fosse apenas se preocupar com os servidores, isso nunca aconteceu.
Eu não acho que poderia ser de outra maneira, desde que você ainda esteja desenvolvendo ativamente o produto. O software baseado na Web nunca vai ser algo que você escreve, faz o check-in e vai para casa. É uma coisa viva, sendo executada em seus servidores agora mesmo. Um bug grave pode não apenas travar o processo de um usuário; pode travá-los todos. Se um bug em seu código corromper alguns dados no disco, você precisa consertá-lo. E assim por diante. Descobrimos que você não precisa ficar de olho nos servidores a cada minuto (depois do primeiro ano ou algo assim), mas definitivamente quer manter um olho em 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 acompanhá-los em casa. Se você já observou alguém usando seu software pela primeira vez, você sabe que surpresas devem tê-los aguardado.
O software deve fazer o que os usuários pensam que fará. Mas você não pode ter nenhuma ideia do que os usuários estarão pensando, acredite em mim, até você os observar. E o software baseado em servidor lhe dá 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ê precisa considerar cuidadosamente o que você 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 se basear em 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 entrar no servidor e ver o que está consumindo todo o CPU. E você sabe quando parar de otimizar também: eventualmente conseguimos deixar o editor Viaweb no ponto em que era limitado pela memória em vez de limitado pelo CPU, e como não havia nada que pudéssemos fazer para diminuir o tamanho dos dados dos usuários (bem, nada fácil), sabíamos que poderíamos parar por aí.
A eficiência é importante 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 de 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, conseguimos reduzir o custo de capital por usuário para cerca de $5. Provavelmente seria menos agora, provavelmente menos do que o custo de enviar a eles a fatura do primeiro mês. O hardware é gratuito agora, se seu software for razoavelmente eficiente.
Observar os usuários pode orientá-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 podiam fazer o que eles queriam. Originalmente, o editor colocava barras de botões através da página, por exemplo, mas depois que vários usuários usaram o RTML para colocar os botões no lado esquerdo lado, fizemos isso uma opção (de fato, o padrão) nos estilos de página predefinidos.
Finalmente, observando os usuários, você muitas vezes pode dizer quando eles estão em problemas. E como o cliente sempre tem razão, esse é um sinal de algo que você precisa consertar. Na Viaweb, a chave para obter usuários era o teste drive on-line. Não era apenas uma série de slides criados por pessoas de marketing. Em nosso teste drive, os usuários realmente usavam o software. Levava cerca de cinco minutos e, no final, eles haviam construído uma loja real e funcional.
O teste 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 com sucesso por um teste drive, eles gostarão do produto. Se ficarem confusos ou entediados, não vão. Então, qualquer coisa que pudéssemos fazer para fazer mais pessoas passarem pelo teste drive aumentaria nossa taxa de crescimento.
Estudei os rastros de cliques de pessoas fazendo o teste drive e descobri que em uma determinada etapa eles ficariam confusos e clicariam no botão Voltar do navegador. (Se você tentar escrever aplicativos baseados na Web, você descobrirá que o botão Voltar se torna um de seus problemas filosóficos mais interessantes.) Então, adicionei uma mensagem nesse ponto, dizendo aos usuários que eles estavam quase terminando e lembrando-os de não clicar no botão Voltar. Outra ótima coisa sobre software baseado na Web é que você obtém feedback instantâneo de mudanças: o número de pessoas concluindo o teste drive subiu imediatamente de 60% para 90%. E como o número de novos usuários era uma função do número de testes drive 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 disse que o software era um negócio de assinatura. Inicialmente, isso pareceu 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 continuar comprando e instalando novas versões para que elas continuem pagando a você. E felizmente, as assinaturas são a forma natural de faturar por aplicativos baseados na Web.
Hospedar aplicativos é uma área em que as empresas desempenharão um papel que provavelmente não será preenchido por software gratuito. Hospedar aplicativos é muito estressante e tem despesas reais. Ninguém vai querer fazê-lo de graça.
Para as empresas, as aplicações baseadas na Web são uma fonte ideal de receita. Em vez de começar cada trimestre com uma folha em branco, você tem um fluxo de receita recorrente. Como seu software evolui gradualmente, você não precisa se preocupar que um novo modelo fracasse; nunca precisa haver um novo modelo, por assim dizer, 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 se revelar um problema. Certa quantidade de pirataria é vantajosa para as empresas de software. Se algum usuário realmente não teria comprado seu software a qualquer preço, você não perdeu nada se ele usar uma cópia pirata. Na verdade, você ganha, porque ele é mais um usuário ajudando a tornar seu software o padrão - ou que pode comprar uma cópia mais tarde, quando ele 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 eles podem pagar. [8] O software é particularmente adequado para a 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, 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 dois passos separados. Era o que eu pensava antes da Viaweb, na medida em que eu pensava sobre a questão de todo modo. Na verdade, o segundo passo pode se propagar de volta para o primeiro: se algo é difícil de comprar, as pessoas mudarão de ideia sobre se queriam ou não. E vice-versa: você venderá mais de algo quando for fácil de comprar. Eu compro mais livros porque a Amazon existe. O software baseado na Web é praticamente a coisa mais fácil do mundo para comprar, especialmente se você acabou de fazer uma demonstração on-line. 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 provedores de serviços de Internet (ISPs) atuando como revendedores. Essa é uma má ideia. Você precisa estar administrando os servidores, porque precisa estar constantemente melhorando tanto o hardware quanto o software. Se você abrir mão do controle direto dos servidores, você abrirá mão da maior parte das vantagens de desenvolver aplicativos baseados na Web.
Vários de nossos concorrentes se atiraram no pé dessa maneira - geralmente, eu acho, porque foram atropelados por executivos que estavam entusiasmados 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 provedores de serviços de Internet é como vender sushi por 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 querem os menores custos da nova tecnologia.
Os aplicativos baseados na Web muitas vezes serão o melhor para as grandes empresas também (embora elas sejam lentas em perceber isso). A melhor intranet é a Internet. Se uma empresa usar aplicativos Web verdadeiramente baseados, 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 se baseia na segurança: se o acesso for mais fácil para os funcionários, também será para os criminosos. Alguns comerciantes maiores relutaram em usar a Viaweb porque achavam que as informações dos cartões 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 delas. Quem pode contratar melhores pessoas para gerenciar a segurança, uma startup de tecnologia cujo negócio é executar servidores, ou um varejista de roupas? Não só tínhamos pessoas melhores se preocupando com a segurança, nos preocupávamos mais com isso. Se alguém invadisse os servidores do varejista de roupas, afetaria no máximo um comerciante, provavelmente poderia ser abafado e, no pior caso, poderia levar a demissão de uma pessoa. Se alguém invadisse os nossos, poderia afetar milhares de comerciantes, provavelmente terminaria como notícia no CNet e poderia nos tirar do negócio.
Se você quiser manter seu dinheiro seguro, você o mantém 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 também tempo de atividade, largura de banda, gerenciamento de carga, backups, etc. Nossa existência dependia de fazer essas coisas corretamente. Problemas com servidores 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á, nessa medida, terceirizando a TI. Por mais drástico que isso pareça, acho que essa é geralmente uma boa ideia. As empresas provavelmente obterão um melhor serviço dessa maneira do que teriam de administradores de sistemas internos. Os administradores de sistemas podem se tornar azedos e pouco receptivos porque não estão diretamente expostos à pressão competitiva: um vendedor precisa lidar com clientes e um desenvolvedor precisa lidar com o software da concorrência, mas um administrador de sistemas, como um velho solteiro, tem poucas forças externas para mantê-lo no eixo. [[10]] Na Viaweb, tínhamos forças externas em abundância para nos manter no eixo. As pessoas que nos ligavam eram clientes, não apenas colegas de trabalho. Se um servidor ficasse travado, nós pulávamos; só de pensar nisso me dá uma descarga de adrenalina, anos depois.
Portanto, os aplicativos baseados na Web serão normalmente a resposta certa também para as grandes empresas. 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 a pena convencer as grandes empresas de que elas precisam de algo mais caro.
Sempre há uma tendência para que clientes ricos comprem 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 nos deparávamos com isso. Perdemos vários comerciantes de alto nível para empresas de consultoria da Web que os convenceram de que eles estariam melhores se pagassem meio milhão de dólares por uma loja online personalizada em seu próprio servidor. Eles, como regra, não estavam melhores, como mais de um descobriu quando chegou a temporada de compras de Natal e as cargas aumentaram em seu servidor. A Viaweb era muito mais sofisticada do que o que a maioria desses comerciantes conseguiu, mas não podíamos nos dar ao luxo de lhes dizer isso. Com $300 por mês, não podíamos nos dar ao luxo de enviar uma equipe de pessoas bem vestidas e com ar de autoridade 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 de vaso sanitário, é em parte porque custa muito vender assentos de vaso sanitário por mil dólares.) E essa é uma das razões pelas quais o software 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 dilema, 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 é nada novo. Na verdade, é o modelo antigo: os aplicativos de mainframe são todos baseados em servidor. Se o software baseado em servidor é uma boa ideia, por que ele perdeu da última vez? Por que os computadores de mesa eclipsaram os mainframes?
Inicialmente, os computadores de mesa não pareciam representar 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ê poderia 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 se tornaram dominantes? Acho que foi porque eles tinham software melhor. E acho que a razão pela qual o software de microcomputador era melhor é que poderia ser escrito por pequenas empresas.
Não acho que muitas pessoas percebam o quão frágeis e incertos são os startups em seu estágio inicial. Muitos startups começam quase por acidente - como um par de caras, seja com empregos durante o dia ou na faculdade, escrevendo um protótipo de algo que, se parecer promissor, pode se transformar em uma empresa. Nesse estágio larval, qualquer obstáculo significativo interromperá o startup por completo. Escrever software para mainframe exigia muito compromisso inicial. As máquinas de desenvolvimento eram caras e, como os clientes seriam grandes empresas, você precisaria de uma força de vendas com boa aparência para vendê-lo a eles. Iniciar um startup para escrever software para mainframe seria uma empreitada muito mais séria do que simplesmente hackear algo em seu Apple II à noite. E, portanto, não havia muitos startups escrevendo aplicativos para mainframe.
A chegada dos computadores de mesa inspirou muito novo software, porque escrever aplicativos para eles parecia uma meta alcançável para startups em estágio larval. O desenvolvimento era barato e os clientes seriam pessoas individuais que você poderia alcançar através de lojas de informática ou até mesmo por correspondência.
O aplicativo que empurrou os computadores de mesa para o mainstream foi o VisiCalc, a primeira planilha eletrônica. Foi escrito por dois caras trabalhando em um sótão e, no entanto, fez coisas que nenhum software de mainframe poderia fazer. [1] O VisiCalc era um avanço tão grande, na sua época, que as pessoas compravam Apple IIs apenas para executá-lo. E esse foi o início de uma tendência: os computadores de mesa venceram porque startups escreveram software para eles.
Parece que o software baseado em servidor será bom desta vez, porque startups o escreverão. Os computadores são tão baratos agora que você pode começar, como nós fizemos, usando um computador de mesa como servidor. 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 uma na Internet, têm todos os mesmos processadores Intel baratos que você tem em seu computador de mesa. E, uma vez que você tenha escrito o software, tudo o que você precisa para vendê-lo é um site na Web. Quase todos os nossos usuários vieram diretamente para o nosso site por meio do boca a boca e de referências na imprensa. [2]
A Viaweb era um startup larval típico. Tínhamos medo de iniciar uma empresa e, pelos primeiros meses, nos consolávamos tratando todo o negócio como um experimento que poderíamos interromper a qualquer momento. Felizmente, havia poucos obstáculos, exceto os técnicos. Enquanto escrevíamos o software, nosso servidor Web era o mesmo computador de mesa que usávamos para desenvolvimento, conectado ao mundo exterior por uma linha discada. Nossas únicas despesas nessa fase foram alimentação e aluguel.
Há ainda mais razão para os startups escreverem software baseado na Web, porque escrever software de desktop se tornou muito menos divertido. Se você quiser escrever software de desktop agora, você o faz nos termos da Microsoft, chamando suas APIs e trabalhando em torno de seu sistema operacional com defeitos. 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 os startups construirão, ela precisa fazer algo que os próprios hackers queiram usar. Isso significa que deve ser barato e bem projetado. O Mac era popular entre os hackers quando foi lançado, e muitos deles escreveram software para ele. [3] Você vê isso menos com o Windows, porque os hackers não o usam. O tipo de pessoas que são boas em escrever software tendem a estar executando Linux ou FreeBSD agora.
Eu não acho que teríamos começado uma startup para escrever software de desktop, porque o software de desktop precisa ser executado no Windows, e antes de podermos escrever software para o Windows, teríamos que usá-lo. A Web nos permitiu dar a volta no Windows e entregar software executado no Unix diretamente aos usuários por meio do navegador. Essa é uma perspectiva libertadora, muito semelhante à chegada dos PCs há vinte e cinco anos.
Microsoft
Na época em que os computadores de mesa chegaram, a IBM era o gigante que todos temiam. É difícil imaginar agora, mas me lembro muito bem dessa sensação. Agora o gigante assustador é a Microsoft, e não acho que eles estejam tão cegos para a ameaça que enfrentam quanto a IBM estava.
Mencionei anteriormente que minha mãe realmente não precisa 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 os aplicativos forem executados 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 de servidor/desktop, em que o sistema operacional funcione em conjunto com servidores que eles controlam. No mínimo, os arquivos estarão disponíveis de forma centralizada para os usuários que quiserem 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ó precisar de um navegador como cliente, você não precisa da Microsoft no cliente, e se a Microsoft não controlar o cliente, eles não podem empurrar os usuários em direção a 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 eles controlarem todos. E se os aplicativos da Microsoft só funcionarem com alguns clientes, os concorrentes poderão superá-los oferecendo aplicativos que funcionem de qualquer cliente. [1]
Em um mundo de aplicativos baseados na Web, não há um lugar automático para a Microsoft. Eles podem ter sucesso em se criar um lugar, mas não acho que dominarão esse novo mundo como fizeram no mundo dos aplicativos de desktop.
Não é tanto que um concorrente os fará tropeçar, mas que eles tropeçarão em si mesmos. Com o surgimento de 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 seu negócio existente, e não consigo vê-los enfrentando isso. A mesma determinação que os trouxe até aqui agora estará trabalhando contra eles. A IBM estava exatamente na mesma situação e não conseguiu dominá-la. A IBM fez uma entrada tardia e pouco entusiasmada no negócio de microcomputadores porque estava ambivalente sobre ameaçar sua vaca leiteira, a computação de mainframe. Da mesma forma, a Microsoft será prejudicada por querer salvar o desktop. Uma vaca leiteira pode ser um macaco muito pesado em suas costas.
Não estou dizendo que ninguém dominará os aplicativos baseados em servidor. Alguém provavelmente acabará dominando. Mas acho que haverá um bom e longo período de alegre caos, assim como houve nos primeiros dias dos microcomputadores. Esse foi um bom momento para as startups. Muitas pequenas empresas prosperaram e o fizeram criando coisas legais.
Startups, mas Mais
A startup clássica é rápida e informal, com poucas pessoas e pouco dinheiro. Essas poucas pessoas trabalham muito, e a tecnologia amplia o efeito das decisões que elas tomam. Se eles vencerem, eles vencerão grande.
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ê precisa ser ainda mais rápido e pode se dar ao luxo de ser mais informal. Você literalmente pode lançar seu produto como três caras sentados na sala de estar de um apartamento e um servidor colocalizado em um provedor de serviços de Internet. Nós fizemos isso.
Ao longo do 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 aros e gravatas pretas estreitas, escrevendo diligentemente dez linhas de código por dia em formulários de codificação IBM. Em 1980, era uma equipe de oito a dez pessoas usando jeans no escritório e digitando em vt100s. Agora são um par de caras sentados em uma sala de estar com laptops. (E os jeans se revelam não ser 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 início, têm períodos em que os desenvolvedores dormem embaixo de suas mesas e assim por diante. O 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, enviamos e todos fomos para casa e dormimos por uma semana. O software baseado na Web nunca é enviado. Você pode trabalhar 16 horas por dia pelo tempo que quiser. E porque você pode, e seus concorrentes podem, você tende a ser forçado a 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. Tradicionalmente, programadores e administradores de sistemas 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 no código-fonte, mas em algum momento eles podem ir para casa e esquecer disso. Os administradores de sistemas nunca deixam completamente o trabalho para trás, mas quando eles são acionados à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. Trabalhamos as longas horas habituais de uma startup inicial. Em uma empresa de software de desktop, essa teria sido a parte em que estávamos trabalhando duro, mas parecia uma férias em comparação com a próxima fase, quando colocamos usuários em nosso servidor. O segundo maior benefício de vender a Viaweb para o Yahoo (depois do dinheiro) foi poder jogar a responsabilidade final por tudo isso nos 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 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 trabalhar mais do que seus concorrentes. Nenhuma startup pede mais.
Apenas o Suficiente
Uma coisa que pode desencorajá-lo de escrever aplicativos baseados na Web é a mediocridade das páginas da Web como interface do usuário. Esse é um problema, eu admito. Havia algumas coisas que realmente gostaríamos de adicionar ao HTML e 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 os 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 apenas 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 em funcionamento. Poder ter seu próprio computador era tão emocionante que havia muitas pessoas que queriam comprá-los, por mais limitados que fossem.
Páginas da web não foram projetadas para serem uma interface do usuário para aplicativos, mas elas são boas o suficiente. E para um número significativo de usuários, o software que você pode usar de qualquer navegador será o suficiente para superar qualquer estranheza na interface do usuário. Talvez você não possa escrever a melhor planilha usando HTML, mas você pode escrever uma planilha que várias pessoas possam usar simultaneamente de diferentes locais sem software cliente especial, ou que possa incorporar feeds de dados ao vivo, ou que possa notificá-lo quando certas condições forem acionadas. Mais importante, você pode escrever novos tipos de aplicativos que ainda nem têm nome. Afinal, o VisiCalc não era apenas uma versão para microcomputador de um aplicativo de mainframe - era um novo tipo de aplicativo.
Claro, os aplicativos baseados em servidor não precisam ser baseados na Web. Você poderia ter algum outro tipo de cliente. Mas tenho certeza de que essa é uma má ideia. Seria muito conveniente se você pudesse assumir que todos instalariam seu cliente - tão conveniente que você poderia facilmente convencer a si mesmo de que eles fariam isso - mas se eles não fizerem, você está ferrado. Como o software baseado na Web não assume nada sobre o cliente, ele funcionará em qualquer lugar onde a Web funcionar. Essa é uma grande vantagem, e a vantagem crescerá à medida que novos dispositivos da Web se proliferarem. Os usuários gostarão de você porque seu software simplesmente funciona, e sua vida será mais fácil porque você não precisará ajustá-lo para cada novo cliente. [1]
Sinto que tenho acompanhado a evolução da Web tão de perto quanto qualquer um, e não consigo prever o que vai acontecer com os clientes. A convergência provavelmente está chegando, mas para onde? Não posso escolher um vencedor. Uma coisa que posso prever é o conflito entre a AOL e a Microsoft. Seja lá o que for que o .NET da Microsoft se torne, provavelmente envolverá conectar a área de trabalho aos servidores. A menos que a AOL reaja, eles serão empurrados para o lado ou transformados em um duto entre o software cliente e servidor da Microsoft. Se a Microsoft e a AOL entrarem em uma guerra de clientes, a única coisa que com certeza funcionará em ambos 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 se desenrolar? 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á a funcionar 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 são muito trabalho e de um tipo particularmente estressante, mas isso só torna as chances melhores para as startups.
Por que não?
E. B. White ficou divertido ao saber de um amigo fazendeiro que muitas cercas eletrificadas não têm corrente elétrica passando por elas. As vacas aparentemente aprendem a ficar longe delas, e depois disso você não precisa da corrente. "Levantem-se, vacas!" ele escreveu, "Tomem sua liberdade enquanto os déspotas dormem!"
Se você é um hacker que já pensou em um dia iniciar 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 elétrica.
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 esses dois pontos, estará à frente da maioria das startups. Você pode descobrir o resto conforme avança.
Você pode não ganhar mais do que gasta de início, mas desde que o gap esteja fechando rapidamente, você ficará bem. Se você começar com pouco financiamento, pelo menos isso incentivará um hábito de frugalidade. Quanto menos você gastar, mais fácil será ganhar mais do que gasta. Felizmente, pode ser muito barato lançar um aplicativo baseado na Web. Nós lançamos com menos de $10.000, e seria ainda mais barato hoje em dia. Tivemos que gastar milhares em um servidor e milhares a mais para obter SSL. (A única empresa vendendo software SSL na época era a Netscape.) Agora você pode alugar um servidor muito mais poderoso, com SSL incluído, por menos do que pagamos apenas pela largura de banda. Você poderia lançar um aplicativo baseado na Web agora por menos do que o custo de uma cadeira de escritório sofisticada.
Quanto à construção de 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, depois continue a melhorar o software, ouvindo atentamente os usuários à medida que você o faz. O cliente sempre tem razão, mas diferentes clientes têm razão sobre coisas diferentes; os usuários menos sofisticados mostram o que você precisa simplificar e esclarecer, e os mais sofisticados lhe dizem quais recursos você precisa adicionar. A melhor coisa que o software pode ser é fácil, mas a maneira de fazer isso é acertar os padrões, não limitar as escolhas dos usuários. Não fique complacente se o software 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. O Viaweb deveria ser um construtor de lojas online, mas nós o usamos para fazer nosso próprio site também. Não ouça pessoas de marketing, designers ou gerentes de produto apenas por causa de seus títulos de trabalho. Se eles tiverem boas ideias, use-as, mas cabe a você decidir; o software precisa ser projetado por hackers que entendem de design, não por designers que sabem um pouco sobre software. Se você não puder projetar software tão bem quanto implementá-lo, não comece uma startup.
Agora vamos falar sobre concorrência. O que você teme não são presumivelmente grupos de hackers como você, mas empresas reais, com escritórios e planos de negócios e vendedores e assim por diante, certo? Bem, eles têm mais medo de você do que você deles, e eles estão certos. É muito mais fácil para um par de hackers descobrir como alugar um escritório ou contratar vendas do que é para uma empresa de qualquer tamanho obter software escrito. Eu estive em ambos os lados e eu sei. Quando o Viaweb foi comprado pelo Yahoo, de repente me vi trabalhando para uma grande empresa, e era como tentar correr através de água até a cintura.
Não quero menosprezar o Yahoo. Eles tinham alguns bons hackers e a alta gerência eram verdadeiros chutadores de bunda. Para uma grande empresa, eles eram excepcionais. Mas ainda eram apenas cerca de um décimo tão produtivos quanto uma pequena startup. Nenhuma grande empresa pode fazer muito melhor do que isso. O que assusta sobre a Microsoft é que uma empresa tão grande possa desenvolver software de todo. Eles são como uma montanha que pode andar.
Não se intimide. Você pode fazer tanto que a Microsoft não pode quanto eles podem fazer que você não pode. E ninguém pode te parar. Você não precisa pedir permissão a ninguém para desenvolver aplicativos baseados na Web. Você não precisa fazer acordos de licenciamento, ou conseguir espaço nas prateleiras de lojas, ou implorar para que seu aplicativo seja incluído com o sistema operacional. Você pode entregar software diretamente para o navegador e ninguém pode se colocar entre você e os usuários potenciais sem impedi-los de navegar na Web.
Você pode não acreditar, mas eu lhe prometo, a Microsoft está com medo de você. Os gerentes de nível médio complacentes podem não estar, mas o Bill está, porque ele era você uma vez, de volta em 1975, a última vez que apareceu uma nova maneira de entregar software.
Notas
[1] Percebendo que grande parte 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 de graça o aparelho e ganhar dinheiro nas lâminas pode funcionar para a Gillette, mas um aparelho é um compromisso muito menor do que um terminal da Web. Os fabricantes de telefones celulares estão satisfeitos em vender hardware sem tentar capturar a receita do serviço também. Esse provavelmente deve ser o modelo para os clientes da Internet também. Se alguém simplesmente vendesse uma pequena caixa bonita com um navegador da Web que você pudesse usar para se conectar através de qualquer provedor de serviços de Internet, todos os tecnófobos do país comprariam uma.
[[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 a não estragar. Comprometer um servidor poderia causar tanto dano que os ASPs (que querem permanecer no negócio) provavelmente serão cuidadosos com a segurança.
[3] Em 1995, quando começamos a Viaweb, os applets Java eram supostamente a tecnologia que todo mundo ia usar para desenvolver aplicativos baseados em servidor. Os applets pareciam-nos uma ideia ultrapassada. Baixar programas para executar no cliente? Mais simples apenas ir até o fim e executar os programas no servidor. Desperdiçamos pouco tempo com applets, mas inúmeras outras startups devem ter sido atraídas para esse atoleiro. Poucos devem ter escapado com vida, caso contrário a Microsoft não poderia ter se livrado do Java na versão mais recente do Explorer.
[4] Este ponto é de 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 bug composto, onde um bug acaba compensando outro. Quando você corrige um bug, o outro se torna visível. Mas parecerá que a correção está errada, já que foi a última coisa que você mudou.
[6] Dentro da Viaweb, uma vez tivemos um concurso para descrever a pior coisa sobre nosso software. Dois atendentes de suporte ao cliente empataram em primeiro lugar com entradas que ainda me fazem estremecer 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 você já ouviu um varejista afirmar que seu poder de compra significava preços mais baixos para você?) que fiquei surpreso ao descobrir que era proibida nos EUA pela Lei Robinson-Patman de 1936. Esta lei não parece ser rigorosamente aplicada.
[9] Em No Logo, Naomi Klein diz que as marcas de roupas preferidas pelos "jovens urbanos" não se esforçam muito para evitar o furto de lojas porque, em seu mercado-alvo, os ladrões também são os líderes da moda.
[10] As empresas muitas vezes se perguntam o que terceirizar e o que não terceirizar. Uma possível resposta: terceirize qualquer trabalho que não esteja diretamente exposto à pressão competitiva, pois terceirizá-lo o exporá à pressão competitiva.
[11] Os dois caras eram Dan Bricklin e Bob Frankston. Dan escreveu um protótipo em Basic em alguns dias, depois, ao longo do ano seguinte, eles trabalharam juntos (principalmente à noite) para fazer uma versão mais poderosa escrita em linguagem de máquina 6502. Dan estava na Harvard Business School na época e Bob nominalmente tinha um emprego durante o dia escrevendo software. "Não havia grande risco em fazer um negócio", escreveu Bob, "Se falhasse, falharia. Não era grande coisa."
[12] Não é tão fácil quanto eu faço parecer. Demorou muito tempo para o boca a boca começar a funcionar, e não começamos a receber muita cobertura da imprensa até contratarmos uma empresa de RP (admitidamente a melhor do ramo) por $16.000 por mês. No entanto, era verdade que o único canal significativo era nosso próprio site na Web.
[13] Se o Mac era tão ótimo, por que ele perdeu? Custo, novamente. A Microsoft se concentrou no negócio de software e lançou uma enxurrada de fornecedores de componentes baratos sobre o hardware da Apple. Também não ajudou que os executivos assumiram o controle durante um período crítico.
[14] Uma coisa que ajudaria os aplicativos baseados na Web e ajudaria a manter a próxima geração de software de ser ofuscada pela Microsoft seria um bom navegador de código aberto. O Mozilla é de código aberto, mas parece ter sofrido por ter sido um 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 incentivaria as empresas a construir pequenos eletrodomésticos da Web.
Entre outras coisas, um navegador de código aberto adequado faria com que o HTTP e o HTML continuassem a evoluir (como, por exemplo, o Perl). Isso ajudaria muito os aplicativos baseados na Web a serem capazes de distinguir entre selecionar um link e segui-lo; tudo o que você precisaria fazer para isso seria um aprimoramento trivial do HTTP, para permitir múltiplas URLs em uma solicitação. Menus suspensos em cascata também seriam bons.
Se você quiser 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 pesquisa, mas o Google provou que elas 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 livres primeiro - as novas coisas começam com seus usuários.
[15] Trevor Blackwell, que provavelmente sabe mais sobre isso por experiência pessoal do que qualquer outra pessoa, escreve:
"Eu iria mais longe ao dizer que, porque o software baseado em servidor é tão difícil para os programadores, isso causa uma mudança econômica fundamental afastando-se 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çarem 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 o JavaScript. Esse era um bom plano em 2001, mas o 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 o VisiCalc; e novamente a Ken Anderson por me convidar para falar na BBN.
Você encontrará este ensaio e outros 14 em Hackers & Painters.