Appointy 9: Por que descartamos o código que levou 9 anos para ser construído
Publicados: 2017-02-17Este blog é sobre por que e como fomos capazes de descartar nosso código de 9 anos e começamos a pensar de novo.
Capítulo Um: Apontado em formação
Entre 2004 e 2006, desenvolvemos sites em WordPress para o setor de saúde e bem-estar. Havia um plugin WordPress para quase todas as necessidades – exceto um plugin de agendamento. Recebemos tantos pedidos para um plugin de agendamento que não conseguimos acompanhar!
Então, nós escrevemos nosso próprio roteiro . Um script que nos permitiria economizar tempo por não ter que construir o mesmo código repetidamente. Um dos primeiros desafios que enfrentamos foi que cada vertical tem requisitos específicos. Então, criamos regras de agendamento para generalizar nosso script para diferentes verticais.
Logo a demanda por agendamento aumentou e o Appointy foi ao ar pela primeira vez em janeiro de 2008 com um conceito “Faça você mesmo”.
Infelizmente, em nosso zelo de agradar a todos os clientes, continuamos adicionando recursos e o Appointy se tornou esmagador. E então, os mesmos clientes começaram a reclamar. Percebemos que estamos nos afastando do conceito Do-it-Yourself. Então voltamos à prancheta com a ideia de simplificar novamente, mantendo a funcionalidade.
Custou-nos um ano inteiro. Mas aprendemos uma lição importante.
A Appointy é uma empresa bootstrap (nunca levantou fundos externos) e teve que ganhar dinheiro com os clientes para sobreviver . Acreditamos que a melhor forma de ganhar dinheiro é resolver primeiro o problema de alguém e depois pedir um preço justo. Quanto mais pudermos ajudar nossos clientes, mais cresceremos.
Começamos a melhorar nosso processo de integração e suporte. Mas logo percebemos que cada negócio é único por natureza e precisa de algo diferente. Significava simplesmente que precisávamos não apenas aumentar nossa equipe de suporte, mas também que precisávamos obter mais programadores. Precisávamos de uma maneira de escalar verticalmente em todos os departamentos.
Começamos a contratar mais programadores. Depois de alguns meses, durante uma reunião de scrum, um novo membro da equipe compartilhou que estava feliz por algo que ele havia escrito estar disponível em nosso site de produção. Para ele, foi definitivamente uma conquista. No entanto, eu não estava feliz. Percebi que há algo errado em nossa configuração se está levando meses para que novos programadores se tornem produtivos.
Era hora de sair do conforto e tomar algumas decisões ousadas. Nós simplesmente não conseguimos escalar tão rápido quanto queríamos nesse ritmo!
Capítulo 2: Uma decisão difícil, mas ótima
No dia seguinte, conversei com alguns caras seniores e tentei entender o problema. O problema se resumia à arquitetura que criamos há 9 anos. A tecnologia está mudando a cada ano e, tecnicamente, estávamos quase 9 anos atrasados .
Recomendado para você:
Como o Metaverse transformará a indústria automobilística indiana
O que significa a provisão antilucratividade para startups indianas?
Como as startups de Edtech estão ajudando a qualificação da força de trabalho da Índia e se preparando para o futuro
Ações de tecnologia da nova era esta semana: os problemas do Zomato continuam, EaseMyTrip publica...
Startups indianas pegam atalhos em busca de financiamento
Plataforma de marketing digital Logicserve Bags Financiamento de INR 80 Cr, renomeia como LS Dig...
Eu não sabia como dizer à minha equipe para mudar todo o código que eles estavam escrevendo há 9 anos. Eu não queria parecer louca e decidi me arriscar primeiro. Afinal, eu mesmo já fui programador (e muito bom nisso!
Eu sempre anoto um objetivo antes de iniciar qualquer nova tarefa. Então aqui estava meu objetivo – Criar uma arquitetura modular com uma curva de aprendizado de menos de uma semana e desenvolver um aplicativo extremamente rápido. Se o Google pode buscar os resultados corretos de trilhões de linhas em menos de um segundo, por que o Appointy não pode?
Me deparei com um termo RxJS no Angular.io. Acompanhei o tópico por algumas horas e gostei muito da ideia de fazer streaming dos dados. O conceito era simples – você assistiria a um vídeo no Youtube se tivesse que esperar 5 minutos toda vez que quisesse assistir?
Eu decidi tentar, mas a realidade era que eu não poderia fazer isso sozinho. Eu precisaria da ajuda dos caras mais velhos.
No dia seguinte, acabei de explicar o conceito de streaming para minha equipe e tentei criar interesse. Nos dias seguintes, continuei o processo até que nossas estrelas do rock (que são programadores muito melhores do que eu agora) pegaram o ritmo. A primeira semente da mudança foi lançada .
Em poucos dias, conseguimos implementar todo o conceito de streaming no código existente do Appointy. Como esperado, estava funcionando bem, mas não foi ótimo. Precisávamos fazer mais.
Capítulo 3: O suspense se desenrola
Havia mais duas questões que ainda precisavam ser abordadas
- Interface do usuário e experiência do usuário (UX/UI).
- Velocidade de carregamento.
1,5 mês já tinha passado e só tínhamos ganho conhecimento . Nenhuma ação ainda. Não consegui pedir aos caras seniores para trabalhar em UX/UI e eles saberiam que estávamos tentando descartar o código antigo e eu não sabia o que teria acontecido.
Então, decidi trabalhar com um dos estagiários que contratamos. Este novo estagiário tinha uma abordagem diferente à codificação . Ele queria ser rápido, mais rápido do que qualquer outra pessoa. Ele me ajudou a implementar ferramentas para que eu pudesse verificar as mudanças ao vivo e dar-lhe feedback instantaneamente. Nós dois começamos a chegar cedo às 6 da manhã e quando nosso escritório começaria, já teríamos trabalhado algumas horas. O novo produto começou a tomar forma.
Depois de alguns dias, percebi que tudo estava funcionando muito bem. Estávamos no caminho certo e era hora de conversar com toda a equipe. Agora eu tinha alguma prova de conceito para justificar que 9 anos de código podem ser descartados, mas não sem nossa equipe de estrelas do rock.
O dia chegou. Mostramos a nova interface do usuário e explicamos os próximos passos para entrar em operação. Nossa equipe de rock star começou a acreditar que isso pode ser alcançado. Isso é apenas o que era necessário.
Agora depois de 4 meses, nossa primeira versão está em fase de testes.
Resultado
- Conseguimos reduzir o tempo de carregamento da “Área Admin” de 10 segundos para 2 segundos. (Sim, 5 vezes mais rápido!!)
- Conseguimos reduzir a carga em nossos servidores em 50%.
- Somos capazes de obter novos programadores produtivos dentro de uma semana.
- Finalmente consegui tempo para escrever um blog!
Qual é o próximo?
- O primeiro passo é portar o software existente. O próximo passo seria construir recursos extremamente necessários (estamos compilando solicitações de recursos de nossos clientes e nossa lista de prioridades está pronta).
- Nossa API está pronta e pode ser usada por nossa equipe ou equipes externas para integrar diferentes aplicativos. Por exemplo, não precisaríamos mais de uma semana para adicionar um novo gateway de pagamento.
- Teríamos mais largura de banda para nos unirmos a outras empresas que possam agregar mais valor ao seu negócio. Já nos associamos ao Reservar com o Google para ajudar você a conquistar novos clientes.
PS: Durante esses 4 meses, não apenas criamos o Appointy do zero, mas também criamos com sucesso outro produto de agendamento de salas de conferência do zero. Vendemos por US$ 130 mil sem nem mesmo conhecer o cliente pessoalmente.
[Esta postagem de Nemesh Singh apareceu pela primeira vez no blog oficial e foi reproduzida com permissão.]