O desenvolvimento de software é algo antigo, mesmo antes de Turing tivemos muitos outros. Podemos descer até Babage se for o caso, mas desde sempre sabemos que: “Desenvolver software não é fácil!”.

No passado os programadores, engenheiros e arquitetos de software sofriam com limitações tecnológicas. Poderíamos pegar computadores mais antigos como exemplo. Mas, vamos usar algo mais “atual”: o primeiro PC-XT tinha míseros 128 kB. A maior parte dos arquivos que você lida no dia á dia hoje são muito maiores que isso.

Mas, graças a Moore já não sofremos tanto com este tipo de problema. O celular que você tirou do seu bolso e que está na sua mão neste exato momento enquanto você lê este texto tem infinitamente mais poder de processamento que o computador que levou o homem a lua. Hoje já falamos até em computadores quânticos!

Nos anos 60/70 os programadores já tinham uma visão de agilidade graças a Brooks, então veio o famigerado modelo cascata erroneamente atribuído a Winston Royce que acabou dominando nos anos 80/90. Processo esse que mais atrapalhava do que ajudava. Tudo porque era custoso adaptar o projeto no meio do caminho as novas realidades que iam sendo descobertas durante o desenvolvimento do projeto.

Sorte que na mesma época em paralelo tínhamos muitos outros programadores como Kent Back, Robert C. Martin, Martin Fowler entre outros que entenderam que estava tudo errado em como os softwares estavam sendo criados e então vieram com o Manifesto Agil e algum tempo depois com o Manifesto Craftsmanship buscando resgatar e evoluir os princípios da agilidade. O fato é que a metodologia Agil aplicada da maneira correta já se demonstrou eficiente na solução dos processos de gerenciamento e entrega de software.

As linguagens de programação do passado também eram outro ponto de certa complexidade. Turing programava em binário. Imagine desenvolver os sistemas complexos com milhões de arquivos que temos hoje em dia em assembly. Na época quando os programadores iam criar novos sistemas eles criavam tudo do zero! Ele não tinham bibliotecas de acesso a bancos de dados. Eles não tinham bancos de dados. Eles não tinham um Framework abstraindo pra você toda a estrutura de MVC ou qualquer outro padrão. Eles não tinham Git. Eles não tinham se quer sistema operacional.

Para nossa sorte estes mesmo programadores e muitos outros depois deles com muitos anos de estudos e trabalho, criaram para nós toda a estrutura que temos hoje para criar software nos dias atuais. Softwares dos mais diferentes tipos e tamanhos. Felizmente sua IDE hoje autocompleta a maior parte dos termos que você digitar nos mais diferentes tipos de linguagens. Hoje em dia temos frameworks como Laravel, Spring, Django entre muitos outros que já abstraem pra você toda a estrutura básica da aplicação que você vai criar. Definitivamente hoje temos infinitas ferramentas para os mais diversos problemas de codificação que existiam no passado.

Observe que hoje em dia vivemos um verdadeiro apogeu do desenvolvimento de software. Podemos ir mais longe? Provavelmente! O próximo passo quem sabe sejam as inteligencias artificiais que estejam ai para nos substituir. Não acredito nisso tão cedo. Porque? Porque desenvolver software não é simples! Apesar de termos computadores extremamente potentes, Termos processos que nos ajudam a gerenciar e entregar software de maneira a se adaptar as mudanças do dia á dia. Termos linguagens de programação de alto nível que quase simulam a linguagem natural do dia á dia. Termos frameworks que nos entregam mais dá metade do software já pronto, mesmo com tudo isso desenvolver software não é simples!

Não é simples porque a proposta do software é resolver problemas reais do mundo real e isso envolve questões humanas a qual estes processos e ferramentas não conseguem controlar. E este é o grande ponto! As pessoas que gerenciam, desenvolvem e que de alguma maneira lidam com projetos de software dos mais diferentes tipos e tamanhos não se dão conta disso.

Os times de negócios na maior parte das vezes acham que criar software é um processo linear e repetitivo. Eles acreditam que é como numa linha de produção onde os programadores apertam os mesmos parafusos todos os dias. Eles acreditam que não precisam entender as questões técnicas que se colocam como desafios durante a criação do projeto e deixam isso totalmente para o time técnico. Eles nunca compartilham suas visões de negocio com o time técnico. Donos de produtos que baseiam suas decisões apenas em mocks feitos no photoshop e que não levam os desafios técnicos em consideração ou nem se quer confiam nos seus times técnicos estão fadados ao fracasso!

Verdadeiros donos de produtos sabem que criar software envolve um alto grau de complexidade, tanto a nível técnico, UX ou até mesmo no entendimento do produto que se está querendo criar. Eles confiam nos prazos e estimativas colocados pelos times técnicos e sabem se adaptar quando necessário. Eles sabem que não precisam entender no detalhe as questões técnicas, mas eles buscam entender o máximo possível para saber tomar as melhores decisões para o seu produto e consequentemente para o seu cliente final! Pois eles sabem que desenvolver software não é fácil!

Por outro lado os times técnicos infelizmente muitas vezes se colocam apenas como meros digitadores de código, sendo que os mesmos deveriam se colocar como o que são: artesões. Sim a codificação de um software é algo que envolve criatividade, entendimento de problemas, percepção de mundo e busca pela excelência. Coloque 10 programadores para desenvolver um software e teremos 10 maneiras diferentes de resolver o mesmo problema.

Times técnicos de verdade assumem o papel de profissional ao qual se espera deles na hora de propor soluções. Eles sabem a importância de se ter estimativas honestas, sabem quando levantar a mão antes que os problemas explodam e sabem respeitar os prazos acordados. Eles defendem a todo custo que a qualidade do código seja de alto nível. Eles se adaptam quando necessário mas, nunca entregam merda! Eles sabem o porque estão codificando o que está aberto agora na IDE deles. Eles sabem muito bem o valor do que eles estão codificando para o negocio. Eles ajudam o time de negocio a pensar nas melhores soluções para o negocio! Eles sabem que o software que eles estão criando sera utilizados por pessoas do mundo real. Eles sabem quando dizer não! Pois eles sabem que desenvolver software não é fácil!

Ou seja, por mais que tenhamos computadores potentes, técnicas de gerenciamento e linguagens de programação extremamente simples. A melhor maneira de se garantir um produto de qualidade e que traga valor para quem vai utiliza-lo é garantir que os envolvidos na criação dele tenham ciência de que desenvolver software é um processo não linear e complexo e que eles entendem isso e sabem se adaptar a está realidade.

Está aberto a discussão. Como você vê estes pontos? Como é no seu dia a dia de criação de software?

Aguardo seu comentário!