Ao aprender piano, somos solicitados a buscar a perfeição. Cada nota, cada toque, tem que ser tão elegante quanto o compositor original. Na escola, se obtivemos 90%, às vezes nos perguntam por que não conseguimos obter os últimos 10%.
Entrando no desenvolvimento de software, às vezes, carregamos essa mentalidade. No entanto, à medida que percorro o desenvolvimento de software, percebo que a busca pela perfeição nos faz mais mal do que bem.
Aqui está o porquê.
Não existe uma maneira perfeita de codificar
“Código nunca é ‘perfeito’. Código é sempre ‘bom o suficiente’.” — Matthew Jones
Na programação, temos literalmente inúmeras maneiras de alcançar o que pretendemos. Quanto maior o escopo do projeto, mais padrões de arquitetura podemos alcançá-lo, sem falar na maneira como codificamos.
Cada abordagem tem seus prós e contras e, dependendo da situação, difere. Eu vi inúmeros debates sobre argumentar por que a outra abordagem não é ideal etc., pode-se dar inúmeros cenários “e se” que nunca acontecem. Drena tempo e energia.
Por que não se contentar com qualquer coisa que funcione para o escopo atual e seguir em frente. Pode ter algumas deficiências e limitações. Podemos melhorá-los na próxima iteração ou talvez isso mude no futuro, o que leva ao próximo ponto.
Leia também: Aprender Programação do Zero: Por Onde Começar!
Os requisitos mudam com frequência
Podemos ter um roteiro completo do software que queríamos construir. Podemos planejá-lo e arquitetá-lo com o produto final em mente, enquanto entregamos a primeira iteração ao nosso usuário.
Infelizmente, geralmente, após entregar a primeira iteração, o proprietário do produto nos retorna dizendo que o mercado mudou. Precisamos divergir nosso plano para as novas necessidades.
Supondo que, se tivermos arquitetado solidamente para o objetivo final, assumindo que o requisito não mudará, muitas vezes ficaremos desapontados. O que arquitetamos pode precisar mudar na próxima iteração.
Lição aprendida, faça o suficiente para a iteração atual e esteja pronto para a mudança. Para software, o melhor arquiteto é a facilidade com que ele pode ser rearquitetado.
Leia também: Livros PHP: 5 Melhores Livros para Iniciantes
Não existe software perfeito
“Se a depuração é o processo de remoção de bugs de software, então a programação deve ser o processo de colocá-los”.
― Edsger W. Dijkstra
Então, embora ter um produto de qualidade seja importante e ter uma cobertura de teste sólida seja vital para garantir o desenvolvimento de software sustentável, não há como garantir um lançamento de software sem bugs.
Mesmo que tenhamos um processo de controle de qualidade, não há como testar até que não haja mais bugs. Portanto, é importante saber quando temos testes bons o suficiente para o lançamento do nosso software.
Além de ter uma forma de testar de forma otimizada, vamos ter também um plano de Garantia de Qualidade Reativa.
Leia também: A AMD e a MediaTek cooperam para introduzir o Wi-Fi 6E em PCs
A tecnologia continua evoluindo
Hardware arquitetado para durar;
Software arquitetado para mudar;
A mudança é a única coisa que dura.
Estando no desenvolvimento do Android há cerca de 88, eu diria que a maneira como fazemos o desenvolvimento do Android muda a cada 2 anos. Novas linguagens, padrões de arquitetura, frameworks e ferramentas continuam a surgir.
No desenvolvimento de software, quase não há como construir software que possa superar a tecnologia fornecida. Mesmo que a tecnologia tenha essa capacidade, talvez não tenhamos aprendido tudo para colhê-la completamente.
Então, em vez de nos esforçarmos para produzir o que achamos idea. Vamos aproveitar o que é possível atualmente e enviar o produto primeiro em um status bom o suficiente.
À medida que avançamos para a próxima iteração, aprendemos, melhoramos e evoluímos junto com a tendência da tecnologia.
Leia também: Engenharia de Software: O que é?
Não podemos fazer todos felizes
“Eu não posso te dizer a chave para o sucesso, mas a chave para o fracasso é tentar agradar a todos” – Ed Sheeran
“Devemos construir este recurso ou aquele? Talvez devêssemos ter os dois, mas isso aumentará o tempo de desenvolvimento e complicará os testes.”
“Devemos usar Java ou Kotlin? Temos muitos desenvolvedores já familiarizados com Java, mas Kotlin é a próxima linguagem de programação popular a atrair talentos.”
“Oh, nós temos um bug! Mas também temos um recurso para entregar. Em qual devo trabalhar primeiro?”
Então, você entendeu a mensagem. Vá para o que é melhor, ou procure um compromisso do que é bom o suficiente. Você não pode obter os dois.
Existem outras prioridades
“Steve (Jobs) nunca codificou” – Steve Wozniak
Às vezes, nós, desenvolvedores, pensamos que o negócio gira em torno da codificação. Na realidade, ambos estão interligados.
É importante construir e enviar código de qualidade que seja escalável e sustentável. Mas é pragmático fazer o que é apropriado para a situação atual.
Por exemplo, uma organização tem uma base de código legada que ainda está atendendo aos negócios. Dessa forma, uma maneira é descartar e reescrever todo o software do zero usando a mais nova pilha de tecnologia. Então, osso é o melhor do ponto de vista técnico, não deixando nenhum código legado para reter.
No entanto, do ponto de vista da organização, isso pode comprometer o negócio em termos da necessidade de mudança rápida para o que está disponível hoje.
Portanto, levando em consideração o que temos e o que pode ser feito, teremos que nos contentar com algo bom o suficiente para sobreviver, enquanto sustentamos o negócio.
O tempo de colocação no mercado precedeu a perfeição
“Lance cedo, lance com frequência e ouça seu cliente” — Eric S. Raymond
O acima é uma importante prática de desenvolvimento de software hoje. Eu acrescentaria mais um item a ele “Lançar cedo, lançar com frequência, lançar pequeno”.
Não há problema em ter um recurso incompleto, desde que seja bom o suficiente para ser usado. Uma versão com pequenas alterações também diminui a probabilidade de introduzir novos bugs ou problemas. Enquanto também recebemos feedback incremental do usuário sobre as alterações.
Como faremos alterações de qualquer maneira e rapidamente, vamos torná-lo bom o suficiente para cada iteração de lançamento e melhorá-lo de forma incremental.
A vida é perfeitamente imperfeita
Na realidade, não só a perfeição não é ideal no desenvolvimento de software, como também não é prática em muitos aspectos da vida real.
Portanto, em vez de buscar o desenvolvimento de software perfeito, vamos apontar para o desenvolvimento de software pragmático.
Leia também: Marketing Digital e Hotmart: O que são?
