Ou faça certo

Se você escolher uma ideia que mata mais produtos, essa é a criação de uma reserva para o futuro (prova futura).

Geralmente a idéia se manifesta em um padrão.

Precisamos de {X} e, embora fazer {Y} seja muito mais fácil, mas com o início de {Z} a primeira opção simplificará nossas vidas.

Onde {Z} é um evento que pode ocorrer em um futuro distante.

Aqui estão alguns exemplos:

• A infraestrutura precisa do Kubernetes e do Docker , embora um servidor grande seja muito mais simples, mas quando você precisar escalar para 11 servidores , isso simplificará nossa vida.
• O processamento de dados requer um design distribuído , embora uma solução centralizada seja muito mais simples, mas quando o cliente exige 99,999% de tempo de atividade no SLA , isso simplifica nossas vidas.
• Precisamos recrutar uma equipe de desenvolvimento e criar nosso próprio software , embora o Wordpress e o Shopify sejam muito mais simples, mas quando a base de clientes cresce 100 vezes , isso simplifica nossas vidas.
• Precisamos usar um design baseado na herança de tipos , embora a composição seja muito mais simples , mas após 5 anos aumentando a base de código, isso simplificará nossas vidas.
• Precisamos escrever código em C ++ com cache de representação, embora um script Python com solicitações diretas ao Postgres seja muito mais simples, mas com um grande aumento na quantidade de dados, isso simplificará nossas vidas.

Recentemente, escrevi um artigo sobre problemas imaginários que as pessoas pensam de si mesmas por tédio, e não para sempre. Os estoques para o futuro geralmente se enquadram nessa categoria. Eu diria mesmo que este é o erro mais popular na maioria das pequenas empresas.

Mas vale a pena discutir mais, porque criar um estoque para o futuro pode realmente ajudar o produto, é preciso fazer tudo certo. No entanto, a maioria das pessoas comete erros e prejudica o trabalho.

Sucesso é mais difícil do que viver com ele

Não importa o quão estranho possa parecer, acho que uma das principais razões para o que está acontecendo é o culto às celebridades.

As pessoas têm uma estranha obsessão de se colocar no lugar de alguém mais bem-sucedido. Então eles fazem planos a partir dessa posição e não pensam à sua maneira.

Todo mundo fantasia o que fazer com esse poder incrível que ele não tem. Como se ele fosse o presidente do país, um bilionário, uma celebridade, um artista virtuoso ou um super-homem com habilidades sobre-humanas.

O problema com os desenvolvedores é que eles se entregam demais a essas fantasias. Todos podem escrever software. O Facebook não apenas é capaz de criar uma plataforma de mídia que suporta bilhões de usuários, mas você está desperdiçando seu tempo. A mágica do Facebook era atrair esses bilhões de usuários, e expandir o sistema foi a parte mais fácil.

Existem dois aspectos:

• a) Atingir o crescimento é muito mais difícil do que garantir tecnicamente.
• b) Os engenheiros mais importantes e conhecidos trabalham em produtos que exigem escala.

O primeiro ponto é óbvio, se você pensar sobre isso. Quantas empresas de software falharam quando atingiram bilhões em receita ou milhões de usuários? Talvez 80% ... se você definir "falha" muito estritamente.

No entanto, de todas as empresas de software já criadas, talvez apenas 0,05% tenham atingido essa escala.

O problema com a criação de um estoque é que ele geralmente é criado para cenários que nunca ganham vida. Seja o crescimento para 1.000 funcionários, 10.000.000 usuários ou 10 grandes clientes com requisitos draconianos.

E é difícil abandonar esses planos, porque interfere nos pensamentos de sucesso. Impede que as pessoas fantasiem como derrotam a Amazon, mas retornam à realidade. Mas, na realidade, você tem 50 clientes, metade dos quais são parentes e amigos.

O segundo ponto apenas piora a situação. Naturalmente, os melhores programadores conseguem os melhores lugares nas principais empresas. Eles ajudaram a criá-los ou pagam milhões por suporte lá.

O princípio de Pareto funciona contra nós, porque os melhores programadores escrevem a maioria dos livros e dão a maioria das palestras. Ouvimos constantemente sobre serviços distribuídos em milhares de máquinas que processam petabytes de dados e lutam por cada porcentagem de desempenho. Mas a maioria de nós não precisa pensar em quantos sistemas grandes ou confiáveis, como o Facebook ou o Google, exigem.

Então, se as fantasias sobre o futuro não ajudam, então você não precisa planejar?

Não é claro. Pensar no futuro é importante. Deve ser colocado sobre ele, mas faça o que é certo.

Design para flexibilidade cria imperfeição

Quando se trata de pensar no futuro, menos é melhor, mas melhor.

Produtos muito raros atendem exatamente às necessidades dos usuários, o restante é sintonizado em movimento.

É quase impossível que você forneça o serviço A e 90% dos usuários precisam exatamente disso. Normalmente você fornece o serviço A e 90% dos usuários precisam do serviço Z. No entanto, A é a alternativa mais próxima de Z e ninguém fornece Z ... portanto, alguns clientes decidem atendê-lo.

Isso é bom Quando os clientes decidem aceitar o seu produto, você pode alterá-lo de acordo com as necessidades exatas. Em essência, os usuários ajudam a identificar um nicho no mercado. Assim que você puder preencher melhor esse nicho, começará a crescer.

Este é um paradigma produtivo de pensamento, porque encoraja uma abordagem “menos é mais” para o desenvolvimento futuro. A reserva futura não implica um aumento de complexidade, mas uma simplificação máxima. Ser capaz de se adaptar.

Quanto mais simples sua base de códigos, mais fácil é configurá-la para executar outra tarefa.

"Eu odeio código e quero que ele seja o menor possível em nosso produto". - Jack Diderich

Design perfeito requer sacrifício. Geralmente eles estão associados à flexibilidade.

Muitas vezes, é um software imperfeito que resolve os problemas mundiais, uma vez que o software imperfeito é mais flexível. A imperfeição, por definição, deixa espaço para melhorias.

Projete de maneira otimista, o futuro pode surpreendê-lo

Também é importante lembrar que o mundo ao redor não é estático.

Problemas futuros precisam ser resolvidos por tecnologias futuras.

Muitas pessoas não apenas pensam em ferramentas futuras, mas geralmente usam ferramentas de uma década atrás. Eles impõem restrições que há muito foram levantadas.

Deixe-me explicar um problema específico: o design do software distribuído. Um dos motivos mais comuns pelos quais esse software está sendo desenvolvido é porque um único servidor não pode ser dimensionado para as especificações necessárias. Embora isso seja verdade em algumas situações, é difícil acreditar nas perspectivas da maioria dos projetos, especialmente nas startups que quase não têm clientes.

Acho que parte do motivo é que a maioria dos desenvolvedores em 2018 ainda pensa em servidores de 2005. Mas os computadores estão melhorando a cada ano, e muitos fornecedores vendem servidores dedicados baratos.

Por exemplo, aqui está um servidor grande e barato:

• Dois Xeon E5-2680v4 (28 núcleos, 56 threads, velocidade de clock de 2,4 GHz a 3,3 GHz)
• 512 gigabytes DDR4-2400 RAM
• 2 SSDs NVMe de 1,2 TB (cada ~ 3 GB / s de leitura, ~ 1,5 GB / s de gravação)

Aposto que a maioria dos softwares distribuídos requer menos da metade da carga de trabalho desse servidor amador.

Esse servidor custa de ~ 800 a $ 1300 por mês, dependendo da localização. Você pode receber uma dúzia pelo salário de um engenheiro experiente do DevOps em Londres.

Mais agradavelmente, o servidor ficará mais barato pela metade em dois ou três anos.

Os computadores continuam a melhorar e o farão linearmente até o final da década de 2020. Quem sabe quais invenções aparecerão. Até então, podemos até ver a revolução aberta do ferro .

No entanto, as pessoas continuam a desenvolver software para especificações e preços de hardware no início dos anos 2000, embora em 2018 seja necessário desenvolver software para máquinas em 2019.

Isso se aplica não apenas aos servidores. Se você quiser pensar no futuro, pense em todos os periféricos futuros. Estou certo de que os caras que forneceram uma interface de voz para o dispositivo em 2016 estão muito felizes em 2018.

Para quais periféricos você deve se preparar em 2018? O diabo o conhece. Mas eu sei que ela ainda não se tornou popular. Quando se tornar popular, ajudará você a ocupar uma posição de monopólio no mercado, porque você já adaptou seu software para ele.

E não se trata apenas de hardware, o progresso no software é absolutamente incrível. Com o advento do WASM, os navegadores estão se tornando máquinas virtuais universais. Após dois anos, você pode criar um aplicativo de alto desempenho compilando-o para uma única plataforma: WebAssembly.

Apesar disso, as pessoas ainda criam software para computadores domésticos do modelo 2012. Eles usam Babel, embora mais de 99% dos usuários tenham navegadores habilitados para ES6.

Novos idiomas estão aparecendo constantemente, e alguns deles são muito bons. Somente nos últimos 8 anos, Go, Rust, Scala e D apareceram que mudaram completamente o paradigma de programação do sistema. Nos próximos dois anos, parece-me que Julia fará a mesma revolução na computação científica ... e essas são apenas as áreas com as quais eu pessoalmente lido, e o número total de futuras coisas incríveis é simplesmente inacreditável.

Mas eu discordo ...

É fácil aproveitar o futuro. Mas ninguém sabe realmente o que acontecerá em um ano, dois ou cinco anos. Existem algumas previsões, mas elas, é claro, não são ideais.

No entanto, se você realmente deseja criar uma reserva para o futuro, entenda primeiro o que o presente oferece. Além disso, dessa forma, você fará uma previsão conservadora mais precisa com base em dados reais.

O software com uma reserva para o ano de 2020, criado no espírito do início dos anos 2000, não ajudará.

Portanto, não pare de pensar no futuro

Basta começar a planejar corretamente.

Projete levando em consideração não apenas o seu produto, mas todo o ecossistema circundante.

Design para flexibilidade, não perfeição. A flexibilidade ajudará a adaptar o software para o futuro. Ajuda a enfrentar novos desafios e não protege contra o imaginário.