Um novo olhar para a questão antiga: o aplicativo deve ser reescrito do zero ou é "o pior erro estratégico que um desenvolvedor de software pode cometer"? Acontece que, ao trabalhar com uma base de código madura, há mais de duas opções de resposta.

"O código fonte parece estar enferrujado !" - Joel Spolsky

Quase duas décadas atrás, Joel Spolsky encenou a Netscape por reescrever a base de código do navegador em seu épico ensaio "O que você nunca pode fazer" . Ele chegou à conclusão de que o software em funcionamento nunca deve ser reescrito do zero . Ele tinha dois argumentos principais:

• Partes que parecem lixo da base de código geralmente incluem conhecimento adquirido com muito esforço sobre situações de fronteira e bugs estranhos.
  
• A alteração completa é uma empresa de longo prazo que distrai a melhoria do produto existente, que fornece trunfos aos concorrentes.

Para muitos, as descobertas de Joel se tornaram dogmas; ao mesmo tempo eles tiveram uma grande influência em mim. Mas nos anos seguintes, percebi que, em algumas circunstâncias, ainda faz sentido refazer completamente o produto. Por exemplo:

• Às vezes, uma base de código desatualizada não é realmente recuperável; portanto, mesmo uma atualização simples requer alterações em cascata em outras partes do código.
  
• As soluções tecnológicas originais podem interferir nas melhorias necessárias.
  
• Ou, a tecnologia original pode estar desatualizada, dificultando (ou muito caro) contratar desenvolvedores qualificados.

Claro, de fato depende muito das circunstâncias. Sim, às vezes faz sentido refatorar gradualmente o código desatualizado. E sim, às vezes faz sentido jogar tudo fora e começar de novo.

Mas essa não é a única escolha . Vamos dar uma olhada em seis histórias e ver quais lições podem ser aprendidas.

---

1. Netscape

O código do navegador foi reescrito três vezes do zero

A transição catastrófica do Netscape de 5.0 para 6.0 foi a ocasião para o artigo mencionado por Joel Spolsky e muitos convenceram que isso nunca deveria ser feito.

O Netscape Navigator foi lançado em 1994, nos primeiros anos da Internet comercial. Dois anos depois, a empresa abriu a era das pontocom com um IPO de US $ 3 bilhões.

O primeiro grande concorrente da Netscape foi o Microsoft Internet Explorer, lançado em 1996.

No início de 1998, o Netscape ainda era o principal navegador, mas com grande dificuldade. O Netscape era um programa comercial vendido por US $ 49, e a Microsoft distribuiu o IE gratuitamente e entregue como o navegador padrão no Windows.



Com o lançamento do Netscape 4.0, a empresa anunciou que a próxima versão será gratuita e será desenvolvida pela comunidade de código aberto, criada e financiada pela Mozilla. Por sua vez, foi uma jogada essencialmente sem precedentes, e a Netscape ganhou muitos apoiadores por uma decisão tão ousada. Mas, na realidade, essa "comunidade" não se concretizou. Jamie Zawinski, um dos primeiros desenvolvedores de navegadores, explica :

A verdade é que o projeto Mozilla envolveu cerca de cem desenvolvedores em tempo integral do Netscape e cerca de trinta desenvolvedores freelancers; portanto, o projeto ainda era de propriedade exclusiva da Netscape.

A equipe chegou à conclusão de que os desenvolvedores externos não estavam interessados ​​no projeto, inclusive por causa da bagunça na base de código:

O código acabou sendo muito complicado e confuso para mudar, para que as pessoas não contribuíssem ... Foi por isso que mudamos para um novo mecanismo. Uma base de código mais limpa e atualizada, mais fácil de entender e participar do desenvolvimento.

Do zero

Assim, um ano depois, o grupo decidiu abandonar o 5.0 sem lançar um release e começou a desenvolver a versão 6.0 do zero.

A preparação do Netscape 6.0 levou dois anos inteiros; e mesmo depois de tudo isso, ficou claro que o navegador estava em bruto. Segundo o colunista do New York Times, David Pog, o navegador funcionou por um minuto inteiro (!) E consumiu RAM. Faltavam vários recursos simples de usabilidade que estavam nas versões anteriores:

A função de visualização de impressão desapareceu, bem como a capacidade de arrastar o ícone de endereço do site diretamente para o menu de favoritos. Além disso, você não pode copiar ou colar um endereço da Web na barra de endereços clicando com o botão direito do mouse. E toda vez que você inicia o trabalho, é necessário alterar o tamanho da janela: O Navegador não se lembra do estado anterior. Mas a desvantagem mais desagradável é que você não pode selecionar a barra de endereço inteira com um clique.

Mas isso foi quase irrelevante, porque nos três anos em que a Netscape parou, o Internet Explorer capturou a participação de mercado restante:


Quando o refinamento do navegador começou, o Netscape rapidamente perdeu terreno para o Microsoft Internet Explorer. O novo navegador saiu três anos depois, era lento e lento; e a participação de mercado da Netscape, entretanto, caiu para quase zero (gráfico adaptado da Wikipedia )

Em 1999, quando o redesenho do navegador estava em pleno andamento, a AOL adquiriu a Netscape por US $ 10 bilhões. Apenas dois anos após o lançamento do Netscape 6.0, a divisão de AOL da Netscape foi liquidada.

A Mozilla, a comunidade de código aberto criada pela Netscape, continuará existindo e lançará o navegador Firefox em 2002, outro projeto em branco. O Firefox conseguiu devolver alguns dos usuários que deixaram a Microsoft.

Mas a Netscape, como empresa, morreu (a Microsoft enterrará os restos da propriedade intelectual da Netscape como resultado de um acordo de 2012 com a AOL).

Tendo vencido essa batalha, a Microsoft se recusou a investir em tecnologia de navegador. O Internet Explorer 6.0 foi lançado em 2001 e não foi atualizado por cinco anos . Alguns consideram isso uma tentativa deliberada de bloquear a promoção da Internet como uma plataforma para aplicativos.

Conclusões

Alguns acreditam que reescrever do zero não foi um desastre. No final, graças a isso, o mecanismo Gecko e o navegador Firefox finalmente apareceram.

Mas todos tivemos que suportar anos de estagnação nas tecnologias da Web sob o monopólio infindável e sufocante do IE6 , enquanto esperávamos um novo navegador que desse vida ao setor. E o fim da era do IE6 não foi colocado pelo Firefox, mas pelo Google Chrome.

De qualquer forma, não se trata de como o projeto afetou a Internet. É sobre qual é o resultado para a empresa. A morte da Netscape não pode ser responsabilizada por esses motivos: o tribunal concordou que a Microsoft abusou intencionalmente de seu monopólio. Mas é claro que a decisão de reescrever tudo do zero foi um fator importante e levou ao resultado final: a destruição de uma empresa no valor de bilhões de dólares e milhares de demissões. Portanto, concordo com Joel que as conseqüências líquidas dessa decisão foram desastrosas .

---

2. Basecamp

No início dos anos 2000, o estúdio de web design de 37signals , com sede em Chicago, ficou famoso por seu blog influente e muitas vezes controverso, co-fundado pelos fundadores Jason Fried e DHH .

Quando comecei a criar web design, eles chamaram minha atenção com uma série de artigos com exemplos de design incorreto e opções de como refazê-los para sites como Google e PayPal. O projeto foi chamado 37better .




O redesenho do formulário de entrega da 37signals FedEx (acima) ainda é melhor que o design real , quase duas décadas depois

A empresa possuía um sistema de gerenciamento de projetos para uso interno , lançado em 2004 como um serviço SaaS chamado Basecamp .

O SaaS ainda era novo na época. As ferramentas de gerenciamento de projetos foram vendidas em caixas com preços de quatro dígitos e manuais pesados. Todos eles trabalharam no conceito de modelagem de caminhos críticos e desenharam gráficos de Gantt complexos. O Basecamp era vendido por US $ 50 por mês e tornou-se uma lufada de ar fresco com sua interface super simples e foco na comunicação.

Avançando alguns anos, o Basecamp tem meio milhão de usuários satisfeitos, os pagamentos chegam todos os meses, mas Jason e David começaram a se preocupar.

Alguns anos atrás, David contou essa história em uma conferência de negócios de software . Ele admitiu que foi influenciado por Joel Spolsky e acreditava que a reescrita de software mataria a empresa. Além disso, havia um certo elemento de complacência e justiça própria em conexão com a popularidade do movimento Agile:

[I] estava completamente absorvido pela idéia de software transcendental ... Um código infinitamente flexível. Legado infinitamente valioso. Você pode mudar qualquer coisa, reescrever qualquer programa, qualquer código ... Se o software for difícil de mudar, a culpa é sua. Você é um programador ruim, por isso precisa melhorar.

No entanto, após “sete anos gordos”, a empresa se viu em um dilema - e o problema não tinha nada a ver com dívidas técnicas .

Algemas de ouro

Tudo começou com o fato de os caras perceberem falta de entusiasmo. Não apenas não havia motivação suficiente para trabalhar em um produto principal, mas eles próprios não usaram particularmente seu programa.

Eles tinham muitas idéias sobre como tornar o produto fundamentalmente melhor, mas qualquer alteração interromperia os fluxos de trabalho habituais de centenas de milhares de usuários do Basecamp. O problema não estava na base de código complexa, mas nos usuários.

Devido ao desejo de agradar os clientes existentes, o produto parou em desenvolvimento, o que impediu a atração de novos usuários. Isso não ameaçou diretamente o negócio, mas representou uma ameaça a longo prazo. O DHH comparou metaforicamente a situação com um balde com vazamento:

Você pode tapar todos os buracos, corrigir todos os erros, atualizar todas as funções das quais os clientes existentes reclamam - mas parte da água sempre sai. Os clientes saem do trabalho e saem do software, mesmo que gostem. Você pode ser enganado: “Ei, o balde está mais da metade cheio. Há apenas um pequeno buraco, apenas um pequeno vazamento, é completamente natural. " Mas, se a situação persistir, o balde estará completamente vazio.

Parte do problema é que você ouve constantemente os clientes atuais, mas não ouve os futuros:

Pessoas que visitaram a página do Basecamp em 2011 e se recusaram a comprar o produto porque ele não era mais adequado para eles: como você acha, com que frequência ouvimos a opinião deles? Nunca. Só ouvimos uma ampla base de clientes existentes que realmente queriam que continuássemos a tapar esses pequenos buracos.

Os desenvolvedores começaram a considerar um produto lucrativo como um par de algemas de ouro:

O principal é garantir que todos os usuários atuais estejam satisfeitos. O dinheiro vem todo mês, um novo cheque, um novo cheque, um novo cheque. Ótimo. Mas, em seguida, estenda a mão e admita: "É isso, nunca mudarei meu software novamente".

Spoiler: Basecamp foi reescrito do zero, e ficou ótimo. Demorou cerca de um ano e, imediatamente após o lançamento do Basecamp 2, o número de novos registros dobrou.

Eu acho que eles fizeram duas coisas principais.

Primeiro, eles não tentaram refazer o produto antigo - porque antes de tudo desejavam implementar novas idéias sobre como abordar a solução dos problemas que o produto antigo resolveu.

Somos tão presunçosos a ponto de pensar que as idéias de 2003 ainda são as melhores de 2011? Sim, fui acusado de arrogância, mas todo o vapor saiu em 2008.

Assim, eles introduziram o Basecamp 2 como um produto completamente novo, sem nenhuma garantia compatível com o Basecamp Classic. Muitas coisas novas apareceram, algo desapareceu completamente e muita coisa mudou completamente.

Esta decisão deu um certo grau de liberdade. A liberdade motiva e as pessoas motivadas trabalham melhor.

A falta da necessidade de oferecer suporte a cada uma das opções de uso do produto original ajudou. Por exemplo, o Basecamp original permitiu hospedar documentos em seu próprio servidor FTP. Os desenvolvedores removeram essa e outras funções semelhantes que faziam sentido, mas agora são marginalizadas. Essa redução na funcionalidade desnecessária tornou possível trazer um novo produto ao mercado dentro de um prazo razoável.

O pôr do sol é considerado prejudicial

Mas e as centenas de milhares de usuários existentes que tiveram seu brinquedo favorito levado? Isso nos leva à segunda coisa interessante que os desenvolvedores fizeram: eles mantiveram o produto antigo .

David teve uma ótima idéia do termo "software do pôr do sol":

Alguém em algum lugar inventou um lindo eufemismo chamado "pôr do sol" ... Chame a destruição de software de "pôr do sol" ... Como todos os usuários estão na praia - e assistem com emoção como suas informações desaparecem. Isso é ótimo!

As únicas pessoas que acreditam no "pôr do sol" são aquelas que chamam assim. Nem um único usuário que realmente passou pelo período do pôr do sol volta e diz: "Oh, isso foi lindo". Eles voltam e dizem: “Droga! Coloquei anos de trabalho aqui! .. E agora você vai me enrolar?! ”

Ele observou que forçar as pessoas a fazer as malas e a se mudar é o "pior erro estratégico", porque você força todos os clientes regulares a tomar uma decisão, continuar a usar seu software ou mudar para outra coisa.

Eu realmente preciso do Basecamp? Se você ainda precisar transferir todo o lixo, talvez transfira para outro lugar. Se você precisar empacotar as coisas em caixas e carregá-las em um caminhão, posso simplesmente transportá-lo pela cidade. Não é um grande problema. O grande problema é empacotar toda a manat. E para onde ir, novamente para o Basecamp ou para outro lugar, essa é uma questão secundária.

David comparou o Basecamp Classic ao Leica M3: a câmera não é produzida desde 1967, mas Leica promete mantê-lo e repará-lo até o fim de seus dias (foto: Dnalor 01 )

Em vez disso, o Basecamp prometeu "respeitar seu legado" : eles simplificaram a atualização para a nova versão, mas não exigiram deixar o Basecamp Classic. Além disso, eles prometeram manter o Basecamp Classic para sempre.

A piada é que, após quatro anos, eles fizeram isso de novo: em 2015, o Basecamp 3 foi lançado, novamente reescrito do zero, com alguns recursos novos e sem os antigos, e novamente muita coisa mudou. Como antes, os usuários de versões mais antigas podem atualizar facilmente. Mas, se quiserem, eles podem continuar usando o Basecamp Classic ou o Basecamp 2 "até o final da Internet".

Basecamp 3 não vai rolar nada. Não é a versão atual, nem a versão original clássica do Basecamp. Algum destes trabalhos funciona bem para você? Legal! Por favor, continue a usá-lo até o final da Internet! Garantimos que os programas permaneçam rápidos, seguros e sempre acessíveis.

Mas há muito "mas". Não é caro? O suporte a várias versões exige muito esforço? E a segurança? E as bases de código desatualizadas? O que posso dizer? Apenas nos preocupamos com os clientes, mesmo que eles não desejem ser atualizados de acordo com nossa programação.

Conclusões

Pessoalmente, esse modelo parece realmente inspirador para mim.

Cada alteração permitiu ao Basecamp olhar para trás e refazer o produto com base na experiência. Para os usuários, este é um jogo em que todos ganham: os conservadores mantêm seus brinquedos; e os inovadores que enfrentam as limitações do sistema obtêm uma aplicação nova e, espero, mais ponderada.

Obviamente, o suporte a várias versões por um tempo infinitamente longo tem um preço; mas como Davi diz:

Não é grátis. Claro que não. Este é um produto valioso e, claro, o suporte não é gratuito. Mas vale a pena.

---

3. Visual Studio e código VS

Nota: Ícone Hipster

A Microsoft criou o VS Code para alcançar desenvolvedores em outras plataformas.

Você deve se lembrar que, durante muito tempo, a Microsoft ofereceu "tudo ou nada". Se você usou o Visual Studio, deve ter trabalhado no .NET e vice-versa. Isso dividiu a comunidade de software em dois grandes campos, principalmente mutuamente exclusivos - em detrimento de todos.

Apelar para os caras legais

A situação começou a mudar nos anos de Steve Ballmer: lembre-se de quão alta foi a decisão dos desenvolvedores do ASP.NET de não inventar o jQuery !

Uma das principais tarefas do CEO da Satya Nadella era entrar em contato com os desenvolvedores do lado de fora de seu "jardim cercado".

Mas houve um problema. Aqui está o que Julia Lewson, vice-presidente do Visual Studio nesta edição do podcast The Changelog, diz :

Não podíamos oferecer toda uma classe de desenvolvedores: modernos, orientados para a Web, que trabalham com Node e JavaScript - não tínhamos nada com o que conversar. Simplesmente não conseguimos atrair esses desenvolvedores.

Então, o VS Code foi criado para quebrar essa barreira e dizer: “Sabe mesmo, pessoal? Ainda temos algo útil para você.

O Visual Studio é um produto pesado em todos os sentidos: somente a instalação pode levar mais de meia hora. Ele suporta uma ampla variedade de casos de uso complexos nos quais os clientes corporativos confiam. Portanto, não havia sentido em considerar o Visual Studio como ponto de partida e adicionar recursos em um novo projeto em outras plataformas. E, obviamente, a idéia de lançar o Visual Studio para Mac ou Linux não era particularmente suportada.

Portanto, a Microsoft começou do zero sem garantias de compatibilidade com versões anteriores.

Na verdade, não muito do zero: a Microsoft já tinha algumas partes importantes, como o editor de Mônaco no navegador. E como o VS Code é um aplicativo Node.js. (escrito em Typescript e lançado em Electron), eles aproveitaram os ricos recursos do ecossistema JavaScript.

Código VS de código aberto, leve, rápido, extensível - o que é surpreendente para um produto da Microsoft - tornou-se uma ferramenta de programação moderna para jovens avançados.


O VS Code tornou-se o editor principal de JS-hipsters (diagrama do relatório State of JavaScript Survey, 2018 )

Ambos os produtos ainda estão em desenvolvimento ativo e não há indicação de que a Microsoft pretenda fechar o Visual Studio.

Conclusões

Ao contrário do Netscape, a Microsoft realmente conseguiu criar uma comunidade ativa de código aberto em torno do VS Code. Aumentou os esforços dos desenvolvedores para melhorar o produto.


De todos os projetos de código aberto, o Visual Studio Code ocupa a 13ª posição em termos de número de estrelas no GitHub - coincidentemente, logo abaixo do Linux!

Obviamente, nem toda empresa pode permitir que seu principal produto esteja disponível gratuitamente. Mas se o código aberto faz parte da sua estratégia de desenvolvimento, faz sentido comparar as histórias da Microsoft e da Netscape - e descobrir o que a Microsoft fez de maneira diferente para que sua comunidade floresça.

Outro fator importante: a Microsoft forneceu ao VS Code um modelo de extensibilidade de alta qualidade , como resultado da qual a comunidade já escreveu cerca de 10.000 extensões.

Uma das últimas conclusões da história do VS Code é que, nos últimos anos, tudo mudou drasticamente: hoje em dia é mais fácil do que nunca criar protótipos e software .

Apesar dos gemidos sobre a complexidade das ferramentas modernas , o ecossistema JavaScript nos últimos anos se tornou um verdadeiro paraíso de módulos de código aberto. A este respeito, agora é um tempo historicamente sem precedentes.

---

4. Gmail e caixa de entrada

Nota: o ícone do pôr do sol da

Caixa de entrada do Gmail foi originalmente apresentado como um UX minimalista alternativo para o Gmail, "com foco no que realmente importa". Ele nunca tentou igualar a funcionalidade do Gmail original e introduziu novos recursos: grupos temáticos (pacotes), cartas fixadas e mensagens pendentes.

Alguns usuários, inclusive eu, aceitaram o Inbox com entusiasmo. Eu sempre pensei que o Inbox era uma demonstração do que o Gmail acabaria se tornando, então atendi a falta de algumas das nuances do Gmail, esperando que elas chegassem ao Inbox.

Duas interfaces, um serviço

O Inbox e o Gmail funcionaram no mesmo back-end. Na verdade, essas são apenas interfaces de usuário diferentes para o mesmo serviço, e você pode alternar conforme desejar. Isso tinha suas vantagens e desvantagens: se a Caixa de entrada não tivesse uma função (digamos, uma secretária eletrônica para férias), você sempre poderia retornar ao Gmail e configurar o que precisava, embora alternar para frente e para trás parecesse estranho.

No entanto, depois de um tempo, o Inbox parou de melhorar - ficou claro que o Google não estava mais investindo recursos nele. Naturalmente, quatro anos após o lançamento, o Google anunciou o pôr do sol da Caixa de entrada .



Como todo mundo, no começo fiquei com raiva dessa decisão. Mas, depois de passar um tempo com a versão mais recente do Gmail, descobri que muitos dos meus recursos favoritos da Caixa de entrada foram transportados para o produto original : uma resposta inteligente, ações instantâneas, anexos e imagens incorporados. Várias caixas de correio do Gmail substituem muito bem os grupos de temas da Caixa de entrada.

Mas nem tudo da Caixa de entrada foi transferido para o Gmail: por exemplo, as pessoas estão tão acostumadas ao "modo de pausa" (soneca) que sem ela agora estão literalmente sofrendo fisicamente.

Conclusões

A Caixa de entrada permitiu que os desenvolvedores do Gmail experimentassem recursos sem interromper o fluxo de trabalho da grande maioria dos usuários.

No entanto, servindo as duas versões no mesmo back-end , o Gmail impôs severas restrições à inovação .

Mais uma vez, o Google foi muito criticado por fechar o serviço popular. Claro, o Google constantemente fecha seus projetos , então nada inesperado.

Mas, nesse caso, a atitude inicial do Google em relação à Caixa de entrada nos levou a acreditar que temos uma demonstração do futuro do Gmail. Como o DHH diria, o pôr do sol ficou feio: muitas pessoas acharam desagradável voltar a um produto antigo e perder os fluxos de trabalho inovadores da Inbox.

Penso que, para muitos, a transição teria sido muito mais fácil se, antes de fechar a Caixa de entrada, todas as suas funções estivessem integradas ao Gmail.

---

5. FogBugz & Trello

Nota: O distintivo

FogBugz e o emblema "dinheiro, dinheiro, dinheiro" são um caso particularmente interessante, pois esse é um produto do próprio Joel Spolsky: fornece uma idéia de como o princípio de "nunca reescrever" é confrontado com a vida real.

Antes do advento dos problemas do Jira e do GitHub, havia um sistema de rastreamento de tickets baseado na Web chamado FogBugz. Lançado em 2000, esse sistema foi o primeiro produto da nova empresa Fog Creek Software, que Joel fundou com Michael Prior. E por mais de uma década, o FogBugz continua sendo seu principal produto. Inicialmente, era vendido apenas como uma versão em caixa para instalação em seus próprios servidores, mas posteriormente foi lançada uma opção SaaS com pagamento de assinatura.

O FogBugz se tornou muito popular, especialmente entre os desenvolvedores que, no meu exemplo, leram o blog de Joel e seguiram seus conselhos de coração. Minha empresa usou o sistema por muitos anos, foi um ótimo produto para o seu tempo.

O FogBugz foi originalmente escrito no ASP clássico, que funcionava em servidores Windows. Quando o ASP.NET saiu, Joel explicou por que não tinha pressa em atualizar .

Para instalar o FogBugz nos servidores Linux, um estagiário da empresa escreveu um compilador Thistle para converter ASP clássico em PHP. Em 2006, o Thistle havia se tornado uma linguagem de programação proprietária chamada Wasabi, compilada em ASP, PHP e JavaScript do cliente.

A estranha história de Wasabi

Atualmente, desenvolver sua própria linguagem de programação e compilador proprietários é, digamos, uma escolha excêntrica. Então é interessante ver como tudo aconteceu.

A certa altura, Joel mencionou Wasabi em uma de suas postagens no blog. Alguns pensaram que era uma piada, então ele explicou que não era uma piada . Jeff Atwood, um colega blogueiro, explodiu a cabeça com esta notícia:

Escrever em seu próprio idioma é absolutamente além dos limites. Essa é uma solução tóxica que está tão em desacordo com as excelentes e robustas dicas de desenvolvimento de software anteriores de Joel que as pessoas realmente pensavam que ele estava brincando.

Joel insistiu que a decisão fazia sentido do ponto de vista comercial. Obviamente, teoricamente, não vale a pena inventar sua própria linguagem, mas se você avaliar cada pequeno passo em direção a essa decisão, dado o contexto tecnológico e a base de código, tudo parecia lógico.

Refletindo sobre Wasabi em um ensaio substancial intitulado "Dívida técnica e a busca pelo vento", o ex-engenheiro de Fog Creek, Ted Unangst, compara o processo de viajar sem um mapa:

Imagine que você está em Savannah, na Geórgia, e quer ir para Londres, Inglaterra. Você não tem um mapa, apenas um vago senso de direção ... Você não segue uma linha reta porque não possui um barco, mas o oceano à sua frente. Mas, por outro lado, uma praia agradável leva ao nordeste, e esta é aproximadamente a direção certa. Você anda pela praia, anda e anda. O tempo passa. Você vê e percebe que a cada passo ele se aproxima do objetivo, embora não avance diretamente para ele.

Em algum lugar em Boston ou na Nova Escócia, você finalmente para e pensa em sua escolha. Talvez essa estrada não leve a Londres? Longe da galeria, você pode ouvir risos: “Ha ha ha, olhe para esses idiotas. Eles não vêem a diferença entre Inglaterra e Nova Inglaterra. Dê um mapa a esses tolos. Mas este é precisamente o problema: você não tem um cartão. Os mapas são feitos por pessoas que quase por definição não sabem para onde estão indo.

De qualquer forma, explica Jacob Krall, outro ex-desenvolvedor do Fog Creek, a solução sacrificou a capacidade de manutenção de amanhã pela velocidade de desenvolvimento atual. E em 2010, as contas dessa dívida começaram a chegar.

Como não colocamos o [Wasabi] em código aberto, incorremos apenas nos custos, devido aos nossos principais produtos rentáveis ​​... Era uma enorme dependência que exigia um desenvolvedor permanente somente neste produto: não é barato para uma empresa do nosso tamanho. Às vezes, o compilador xingava um pedaço de código que parecia bastante razoável para uma pessoa. Ele compilou lentamente. O Visual Studio não conseguiu editar ou conectar facilmente o depurador ao FogBugz ... Todos os novos funcionários foram treinados por Wasabi pela primeira vez por um longo tempo, independentemente da experiência anterior ... Além disso, não vivíamos no vácuo. As linguagens de programação, é claro, melhoraram fora de Fog Creek ... Os desenvolvedores começaram a sentir que suas idéias brilhantes são confrontadas com as limitações do nosso pequeno universo Wasabi.

Ponto de inflexão

Até então, o FogBugz já tinha dez anos: era um produto maduro e estável. Como um projeto paralelo, Joel lançou o Stack Overflow junto com Jeff Atwood (obviamente, a cabeça queimada de Jeff já havia se recuperado).

O FogBugz está envelhecendo gradualmente. Embora o mercado de rastreadores de bugs permanecesse fragmentado, o Jira de Atlassian, que surgiu alguns anos depois do FogBugz, veio à tona. Tornou-se a opção padrão, especialmente para grandes usuários corporativos.

É realmente interessante observar esse ponto de inflexão específico na história do FogBugz. Como o Basecamp, eles tinham um produto lucrativo e maduro. Sim, não está mais tão na moda e talvez não tenha sido muito interessante trabalhar nisso. Para o bem ou para o mal, ele incorpora muitos anos de mudança tecnológica e novas idéias sobre como resolver um problema específico: rastrear bugs.

Obviamente, havia uma opção do Basecamp: levar em conta toda a experiência, tirar e reescrever o FogBugz do zero. Suponho que essa idéia não foi longe demais, porque lembramos: “o que nunca pode ser feito”, “o pior erro estratégico” e assim por diante.

Recentemente, chamei a atenção de um artigo de 2009 que Joel escreveu para Inc. Magazine A coluna de seu autor, intitulada "Crescimento lento significa morte lenta?" seu tom é completamente diferente da pompa comum de autoconfiança: soa introspectivamente, incerto, cheio de dúvidas. Joel se preocupa com o rápido crescimento da Atlassian, discute se há espaço para vários participantes no mercado.

Eu tive que pensar. Temos um grande concorrente que está crescendo muito mais rápido que nós. A empresa fecha grandes negócios com grandes clientes corporativos ... Enquanto isso, nosso produto é muito melhor e somos uma empresa bem gerenciada, mas isso não parece importar. Porque

Ele decide fazer duas coisas. Primeiro, adicione todos os recursos ao FogBugz :

A tarefa da equipe de desenvolvimento para 2010 é eliminar qualquer possível razão pela qual os clientes podem comprar lixo de nossos concorrentes apenas porque há alguma função pequena que eles supostamente absolutamente não podem viver sem. Sinceramente, não acho que será muito difícil.

Em segundo lugar, crie uma equipe de vendas corporativa . Joel admite que ele não é forte aqui e acha essa tarefa desagradável.

Não sei como essas medidas funcionaram. Joel mencionou o FogBugz pela última vez em seu blog em maio de 2010 , anunciando brevemente uma nova versão.

Nova esperança

E foi o que aconteceu:

Na área do décimo aniversário da Fog Creek Software, comecei a pensar: para manter nossos funcionários motivados por mais dez anos, precisamos começar a trabalhar em algo novo.

Portanto, eles foram divididos em duas equipes, cada uma criando um protótipo de um novo produto. A idéia vencedora foi criada com o espírito de um quadro Kanban - um quadro offline real que é frequentemente usado em projetos de desenvolvimento de software: geralmente se parece com notas dispostas em colunas em um quadro.

Joel introduziu este programa como uma ferramenta de gerenciamento em um nível superior ao FogBugz:

Honestamente, com todo esse software sofisticado para "gerenciamento de projetos", eu nunca conseguia rastrear quem está trabalhando no quê ... Como fundador de duas empresas, caminhei pelos corredores e vi dezenas de pessoas pagas para sentar em computadores ... e eu não tinha idéia se eles estavam fazendo seu trabalho corretamente ou se consideravam importante o que realmente não importa.

Ao criar o Trello, os desenvolvedores do Fog Creek tiveram a chance de usar tecnologias modernas:

Utilizamos tecnologia avançada, por isso não é sem sacrifícios. Nossas feridas de desenvolvedor estão espalhadas pelo MongoDB, WebSockets, CoffeeScript e Node. Mas agora eles estão interessados. No mercado de trabalho movimentado de hoje, programadores talentosos decidem muito sobre o que querem trabalhar. Se você lhes der um produto interessante ... eles vão gostar e amarão a companhia deles.

O Trello deu suporte a plug-ins desde o início, então os desenvolvedores terceiros começaram a ajudar:

Plugins e APIs têm a maior prioridade ... Nunca faça você mesmo um produto se você puder fornecer uma API básica, e usuários valiosos ... farão isso por você. Existe uma regra para a equipe do Trello de que, se alguma função puder ser implementada por meio de um plug-in, ela deverá ser implementada dessa maneira.

Os programadores, é claro, entenderam imediatamente os benefícios do Trello, mas não havia nada específico na ferramenta para o desenvolvimento de software específico. Joel descreveu o Trello como uma ferramenta útil para "tudo em que você deseja compartilhar listas com outras pessoas". Logo o Trello começou a ser usado para organizar tudo de uma vez: desde jantares semanais a casamentos e abrigos para cães .

Enquanto o FogBugz era um produto vertical - orientado para um nicho de mercado específico - o Trello era um produto horizontal adequado para qualquer coisa. Joel considera correto o "movimento horizontal" de Fog Creek nesse ponto:

É quase impossível criar um grande produto horizontal, útil em todas as áreas. Não pode ser caro, porque você compete com outros produtos horizontais que podem absorver seus custos de desenvolvimento para um grande número de usuários. Esse é um alto risco e uma alta recompensa: esse caminho não é adequado para uma startup jovem, mas é uma boa idéia para um segundo ou terceiro produto de uma empresa madura e estável, como a Fog Creek.

Para escalar rapidamente para um número muito grande de usuários, o Trello foi inicialmente oferecido gratuitamente. Mais tarde, introduziu um plano de negócios .

Em 2014, o Trello foi apontado como uma empresa independente. Três anos depois, vendeu mais de 425 milhões de dólares com mais de 17 milhões de usuários. Ironicamente, o comprador era Atlassian, o velho inimigo jurado de Fog Creek.

Enquanto isso, estamos voltando para casa ...

O Fog Creek continuou a desenvolver outro novo produto, um ambiente de programação colaborativo chamado HyperDev , que mais tarde foi renomeado para GoMix e depois Glitch .

Ao mesmo tempo, o sistema FogBugz congelou na obscuridade. Em 2017, alguém decidiu que FogBugz é um nome bobo, e o esforço de engenharia foi renomear o produto como Manuscript . Um ano depois - apenas alguns meses atrás -, a Fog Creek vendeu o produto para uma pequena empresa DevFactory , que imediatamente retornou o nome FogBugz .

Sob a liderança do CEO Anil Dash, a Fog Creek tornou-se uma empresa de produto único e mudou seu nome para Glitch .

Conclusões

Eu tenho muitos pensamentos sobre isso.

A chave para entender a história é que o Fog Creek sempre se preocupou não apenas com o rastreamento de bugs, mas com o empoderamento de programadores - começando pelo seu:

A principal tarefa: criar condições de trabalho confortáveis. Criamos contas pessoais para os funcionários, eles só voavam em primeira classe, trabalhavam 40 horas por semana, recebiam almoço grátis, cadeiras Aeron e os melhores computadores. Compartilhamos nossa fórmula engenhosa com o mundo: excelentes condições de trabalho → excelentes programadores → excelente software → lucro!

Com base nessa "fórmula", uma conclusão lógica e encorajadora pode ser feita: a Fog Creek construiu um negócio em torno da felicidade dos desenvolvedores. Isso afetou os produtos da empresa e seu "sistema operacional" interno. O primeiro produto, um rastreador de erros, serviu de base para o lançamento de um novo produto que resolveu um problema semelhante de uma maneira mais abstrata.

De acordo com Joel, parece que a história do Trello não é tanto uma busca por um novo negócio, mas oportunidades para apoiar a motivação e o envolvimento dos desenvolvedores do Fog Creek . Um produto no valor de meio bilhão de dólares era apenas um efeito colateral agradável.

No entanto, um pouco triste como tudo terminou no FogBugz. Não acho que os desenvolvedores do Fog Creek tenham ficado particularmente felizes nos últimos dias antes da venda.

Está claro que havia projetos mais importantes e maiores: Stack Overflow, Trello e Glitch - cada um individualmente é muito mais útil e mais valioso que o FogBugz; e é impossível para uma pessoa acompanhar tudo. Portanto, não posso culpar ninguém, em particular, pela perda de interesse no FogBugz com uma base de códigos de 20 anos e forte concorrência no mercado. Mas usuários leais, pelo menos, encontraram um bom lar e não receberam um remédio para o pôr do sol!

No entanto, minha parte sentimental prefere "honrar a herança" de forma mais honrosa de todos os envolvidos na criação e no uso deste produto nos últimos anos.

---

6. FreshBooks e BillSpring

Nota: ícone de operação secreta

O artigo cresceu mais do que eu esperava, mas não posso deixar essa história de lado. Espere, haverá uma virada inesperada.

Pare-me se você já ouviu isso antes

No início dos anos 2000, Mike McDerment tinha uma pequena empresa de design. Ele decidiu que o software de contabilidade era muito complicado, então usou o Word e o Excel para cobrança.

Tudo funcionou bem até um caso :

O momento crítico chegou quando apenas o caso salvou uma fatura importante do cliente - apenas cliquei no botão desejado. Eu sabia que tinha que haver uma maneira melhor, então passei as próximas duas semanas programando um protótipo que seria a base dos FreshBooks de hoje.

Mike é um designer, não um programador, mas ele e os dois co-fundadores conseguiram montar uma ferramenta boa o suficiente para várias pessoas pagarem US $ 10 por mês pelo uso. Levou quase quatro anos para a empresa deixar o porão da casa dos pais.

No décimo aniversário do programa (soa familiar?), O Freshbooks se tornou uma empresa lucrativa, com mais de 10 milhões de usuários e 300 funcionários.

Mas havia um problema. Quando a empresa conseguiu contratar programadores “reais”, eles tinham um milhão de linhas de “código fundador”. Um analista externo revisou a base de código e concluiu:

“A boa notícia é que você resolveu a tarefa mais difícil. Você descobriu como criar um negócio e tem um produto que as pessoas gostam. A má notícia é que vocês são pouco versados ​​em tecnologia . ”

Mais importante, era impossível implementar as idéias existentes em um produto existente:

Fundamos a empresa há mais de dez anos, o mundo mudou e aprendemos muito sobre o desenvolvimento de programas e as necessidades de empreendedores individuais, que estão se tornando cada vez mais na sociedade ... sabíamos que eram necessários alguns esforços para manter o FreshBooks atualizado em cinco anos.

O MacDerment está familiarizado com a sabedoria convencional de que você não pode reescrever um sistema do zero:

Reescrever o código do zero é o maior risco para uma empresa de software. Provavelmente, você nem terminará o projeto. Levará mais tempo do que o planejado e custará mais. O resultado final pode não agradar aos clientes. E não há garantia de que a nova plataforma seja realmente melhor que a anterior. A regra número um no software é não reescrever seu software.

Assim, eles fizeram várias tentativas para limpar a bagunça sem reescrever o sistema do zero; mas "substituir pneus em movimento" não era possível.

O que aconteceu a seguir pode surpreendê-lo

McDermint foi visitado pela idéia de criar secretamente um FreshBooks "concorrente".

Ele fundou uma empresa completamente nova em Delaware, chamada BillSpring. Ela tinha seu próprio site, marca e logotipo. Tentando não conectar as duas empresas, ele instruiu um advogado externo a desenvolver novos documentos para ela.

A equipe de desenvolvimento implementou práticas de desenvolvimento ágil com base no livro de Jeff Gottelf e Josh Seiden “ LX UX: projetando ótimos produtos com equipes flexíveis” : equipes scrum e iterações semanais com feedback de clientes reais. MacDerment pediu que eles agissem como uma startup e o levassem como investidor de risco:

Você tem quatro meses e meio. Se você entrar no mercado, obtenha mais dinheiro. Caso contrário, o fim. "

A equipe conseguiu liberar o MVP alguns dias antes do prazo. Eles compraram palavras-chave do Google AdWords para direcionar tráfego e ofereceram contas gratuitas aos usuários pelo primeiro ano. Logo, os clientes apareceram - e começaram os rápidos ciclos de iteração do produto real.

No final do primeiro ano, o BillSpring começou a cobrar. Em algum momento, o novo produto recebeu uma avaliação inesperada da qualidade :

"Uma pessoa ligou para cancelar a assinatura do FreshBooks e ir para a nossa nova empresa", diz McDermint. "Foi um ótimo dia."

Logo eles levantaram o véu de sigilo e informaram os clientes do BillSpring que se tratava de um produto FreshBooks e também informaram os clientes existentes do FreshBooks que uma nova versão estava chegando em breve.

Gradualmente, os clientes dos FreshBooks "clássicos" foram admitidos na nova versão, mas sempre podiam retornar à antiga, se quisessem.

Conclusões

O projeto secreto do FreshBooks não foi barato: de acordo com McDermint, eles gastaram US $ 7 milhões nele, porém, após mais de uma década de crescimento usando apenas seus próprios recursos, eles levantaram US $ 30 milhões em capital de risco, portanto havia dinheiro. Nem todo mundo pode pagar.

A Forbes estimou a receita do FreshBooks em 2013 em US $ 20 milhões. Depois que a atualização foi concluída em 2017, eles ganharam US $ 50 milhões. Não se sabe o quanto veio do novo produto, mas escrever o sistema do zero claramente não diminuiu o crescimento da empresa.

MacDerment diz que o processo de desenvolvimento e implementação de novos recursos se tornou mais rápido e fácil. Mais importante, agora eles têm um produto em suas mãos que implementa as melhores idéias. Com este não tem medo de olhar para o futuro.

Além disso, a experiência adquirida mudou a cultura da empresa - em um bom caminho. Quando eles fingiram ser uma startup, eles aprenderam a trabalhar como uma startup. As práticas de UX enxuto se espalharam por toda a equipe de desenvolvimento. Os clientes estão ativamente envolvidos no desenvolvimento de novos recursos.

O FreshBooks tomou medidas extraordinárias para se proteger de possíveis problemas: ao introduzir inovações sob a marca falsa, os desenvolvedores puderam repensar completamente o programa e assumir grandes riscos. Mesmo no pior dos casos, eles não prejudicarão a marca existente.

Tudo parece um pouco extremo. Talvez essas medidas não fossem necessárias. Mas isso é um lembrete de quão sérias são as apostas.

---

Alguns pensamentos

É geralmente aceito que é melhor evitar reescrever um programa do zero e fazer melhorias graduais, se possível. Na maioria das vezes, eu concordo com isso.

Mas o conselho sugere que, no final, obtemos um produto original mais um conjunto de novos recursos.

Mas e se você quiser remover a funcionalidade? Ou implementar alguma opção de maneira completamente diferente ? E se a experiência surgisse com as idéias de uma abordagem fundamentalmente nova?

Minha conclusão dessas histórias é a seguinte: assim que você entender que a versão atual é muito diferente do ideal imaginário , a nova versão não deve ser lançada como um substituto, mas em paralelo com a atual .

Quando se pensa em reescrever tudo do zero, pode valer a pena fazer outras perguntas. Talvez crie seu próprio concorrente? Se meu produto for FogBugz, qual será o meu Trello? Se for o Visual Studio, como será meu código VS?

Se compararmos o artigo de Spolsky no Netscape e o post do DHH sobre o Basecamp, eles concordam com uma coisa: o legado tem valor.

A boa notícia é que você não precisa jogar esse valor fora para inovar.