A origem dos erros em aplicações

A tecnologia já faz parte do nosso dia a dia e esse grande envolvimento das pessoas com o uso do software tem provocado uma verdadeira corrida nos desenvolvedores de aplicações para criar projetos e atender a grande demanda por software. As coisas normalmente vão muito bem até que em determinado momento aparece algum erro “BUG” ou o software passa a ficar lento em algum momento e/ou para de funcionar.

Eu não conheço ninguém que goste que goste de ligar para um central de atendimento e falar com o “robô”. Imagina agora o cliente ligando para a área de TI e recebendo a resposta “Na minha máquina funciona”. Essa é clássica entre os programadores. Mas também existe o outro lado onde o cliente liga e fala que está tudo parado. Após parar toda a equipe para investigar descobre-se que o monitor está desligado.

Os erros nas aplicações consomem muito dinheiro, tempo nas empresas e principalmente a satisfação das pessoas. Construir uma grande solução sem se preocupar com a operação “sustentação” é certo que os problemas vão se tornar o grande gargalo do negócio. O TCO (Total cost of ownership) aplicado na manutenção de um grande software atualmente se torna a ruína da própria empresa que simplesmente para de inovar, para de vender, para de conquistar novos clientes pelo fato de ter todos os esforços direcionados a conseguir mitigar os bugs que se multiplicam a cada modificação.

Hoje ao sair para almoçar estávamos conversando sobre que caminho seguir para o local do almoço e tínhamos duas ruas para escolher. A rua principal um pouco mais longa, porém limpa e bem cuidada e um atalho em outra rua que geralmente está muito suja. Durante o caminho eu estava comparando se fosse um software. Você escolhe o melhor caminho fazendo tudo certinho, validando, integrando ou escolhe o caminho mais rápido “sujinho” resolvendo do jeito que tem que resolver e correndo o risco de não resolver o problema e/ou criar outros novos, mas pelo fato de parecer mais barato e rápido toma essa decisão.

A maioria dos projetos de software iniciam no modo feliz e ao longo das não entregas passam a se tornar conflituosos, desastrosos e depois de um longo tempo entram em modo caos onde todas as partes já estão em conflito (usuários, equipe, patrocinadores) em um processo meio que em loop trabalhando, trabalhando sem ver os resultados.

Os gestores ignoram por padrão a qualidade, a estratégia da aplicação e demais processos de engenharia de software necessários ao reuso, padronização, estabilidade e principalmente manutenibilidade seja por falta de conhecimento ou por escolha. Em uma conta rápida dizem ser custo pensar em estratégia sendo que isso se resolve depois. Esse custo de fazer depois nunca entra no projeto até por que se torna absurdamente mais caro a medida que o processo cresce.

Algumas correções são  inviáveis conforme o tamanho do projeto face que problemas estruturais grandes na maioria das vezes estragam o software e devem ser descartados. Esse desperdício é uma verdadeira draga de recursos em qualquer empresa e uma situação muito comum em projetos de software.

Durante muitos anos venho discutindo o tema com executivos de diversas companhias, desenvolvedores, arquitetos e engenheiros de software e outros participantes do ecossistema de software e hoje temos um consenso claro que o mercado mudou e não reflete a realidade de 20 anos atrás.

A era do “Consumidor 5.0”, mobilidade, computação em nuvem e serviços tem se associado uma fase “Digital Transformation” vivida nas empresas que demandam por mais eficiência, práticas ágeis, ciclos curtos e principalmente alta qualidade para garantir uma operação continua com o mínimo de downtime e um menor tempo de recuperação cada vez mais agressivo.

Ao longo desse artigo já discutimos alguns pontos de erros principalmente da ordem cultural sobre como se construir o software, mas essa grande cadeia produtiva tem várias frentes e estou completamente com mais algumas possibilidades baseadas em evidências reais direto das trincheiras de grandes projetos que influenciam milhões de reais tocando a vida de muitas pessoas.

Ao se falar em software com erros a primeira reclamação que vem na cabeça das pessoas é a divergência de requisitos principalmente se você está falando com um desenvolvedor de software. Esse é um tema que vem sendo superado com a proximidade do cliente e práticas ágeis trocando processos imuteis por colaboração, participação mais próxima, revisões frequentes e melhoria continua.

As novas tecnologias trouxeram novos problemas digitais como a distração e falta de atenção nos projetos. Mas a falta de foco sobre o real problema a ser resolvido é um grande problema, pois você tem uma pessoa com um objetivo e ao final percebe que está implementando outra coisa diferente e esqueceu até da sua missão inicial. Já parou para pensar quantas coisas são produzidas indevidamente sem valor de negócio para o cliente?

Existe uma grande teoria sobre programadores júnior e sênior. Muitos gritam que precisam de bons programadores (melhores do mundo) e outros que a equipe é completamente júnior. Ao programador júnior falta a experiência, porém se for um profissional engajado ele testará melhor a sua implementação diferente de um sênior com amplo conhecimento que pode tomar ações mais rápidas, porém seu excesso de autoconfiança o impedirá de testar completamente um cenário deixando passar bugs críticos. Eu defendo um equilíbrio entre equipes e um amplo compartilhamento de conhecimento e sensibilidade de urgência favorecendo a qualidade e eficiência.

Um mau que afeta muitos profissionais e eu chamo de “Cegueira programática” parece que funciona como um vírus que contamina outras pessoas do projeto e tem como principal característica achar que tudo que ele faz é a melhor e única solução do mundo ignorando e rejeitando qualquer opinião independe do valor de negócio. Não importa o problema a ser resolvido e sim o que ele está achando que tem que ser feito. Não preciso ir longe para te mostrar exemplos de implementações “pessoais” e não do negócio.

Um fato que classifico como grave e de grande incidência é o que chamo de “
Compreensão antecipada do problema” e se manifesta pela característica de nem esperar o cliente terminar a contar o problema e já entender que tem uma solução. Esse é um fato corriqueiro nos projetos de software e recomendo você observar independente do lado que esteja. Um programador trabalha muito acelerado e pela própria empolgação natural já pensa em como resolver o problema sem terminar de compreender o objetivo.

Até esse momento eu procurei trazer alguns pontos não tão técnicos para uma melhor compreensão de todos, mas exitem coisas básicas que assustam qualquer pessoa que desejem entrega um software.

Durante anos ganhei muito dinheiro em consultoria para resolver problemas de conexões abertas da aplicação com o banco de dados. Um problema muito comum entre os programadores Web que usavam ASP clássico e remanescente ainda até os dias atuais em projetos que não usam um ORM (object relational mapping) deixando por exemplo deixando o controle da conexão com o desenvolvedor que não fecha. Em um cenário de muitos usuários rapidinho vai estourar o número limite de conexões ao banco de dados deixando a aplicação lenta e o banco de dados travado. Levanta a mão se você é da área de TI e nunca viu um cenário desse em algum lugar.

Com a popularização dos webservices como ponte de integração entre sistemas e hoje mais popularizado com o uso de API’s tornou-se fundamental para os aplicativos mobile e os programadores passaram a incluir requisições a esses serviços contanto claramente que estarão disponíveis sempre deixando de verificar erros de indisponibilidade o que provoca quebras nas aplicações e um caso simples de “erros fantasmas”.

Outro dia eu sai do sério quando um profissional me disse que estava fazendo uma requisição externa a um serviço e estava de boa, pois nunca ia parar de funcionar a máquina. Acho que nem um profissional iniciante tem que falar uma besteira dessas. Não deu outra, tempos depois um impedimento grave impedindo a receita do cliente pelo serviço fora que poderia ser evitado em uma validação simples contra erros timeout ou indisponibilidade.

Outra fonte boa de renda ALTA em consultoria é aplicações de alta performance. É difícil fazer as pessoas entenderem que os processadores das máquinas e cpus não estão a disposição de um único inquilino e sim Multitenancy em um farm web. Em um projeto web por exemplo um erro cometido em um cenário é multiplicado pela quantidade de usuários. Antigamente era diretamente ligado a usar indevidamente recursos como “Session” no ASP/ASP.NET e hoje até como você estrutura o seu código pode afetar no resultado.

Hoje até um loop paralelo e/ou instâncias indevidas dentro da aplicação comprometem o resultado em grande escala. E se você acha que por estar nas mais novas tecnologias como “ASP.NET MVC” estará protegido? Não se engane que o mais comum é tentarem transportar erros antigos para a plataforma nova trocando apenas a tecnologia em um momento de tentar sempre fazer o mesmo. E posso garantir que se você iniciar um projeto sem uma estratégia é o que vai acontecer.

Em um momento de evolução, agilidade e transformação impulsionada pelo mercado e processos ágeis como DevOps é até estranho falar em controle de versão. Hoje ainda as empresas olham apenas para o controle do código fonte e não a gestão do código e sua integração com o ciclo de vida da aplicação. Um erro comum em 90% dos projetos de software é o cliente pedir uma correção e receber a correção com mais bugs e mais funcionalidades sendo que o objetivo era apenas corrigir aquele bug pontual. Portanto não confundir ter um controle de versão com ter garantia de liberar o software certo para cada cliente.

Estamos falando em um momento orientado a API’s, serviços online, mobile e situações de performance podem comprometer o negócio. Não adianta você falar que recursos computacionais são baratos e infinitos. Difícil é convencer o patrocinador do projeto a gastar dinheiro desnecessariamente. Quanto mais tecnologia, maior a expectativa por eficiência e o software é o coração e deve funcionar a 100%.

No início desse artigo eu reforcei a importância do investimento em qualidade e estratégia. Erros como esses citados nós atacamos durante todo o ciclo do projeto. Se eu pudesse resumir o que é um software em poucas palavras posso dizer “O software é um ser vivo, apaixonante e rebelde com impactos imensurável na vida das pessoas”. Para você ver até filosofei um pouco, mas de ver os ciclos se repetirem tanto e tantas empresas desperdiçando dinheiro com ciclos repetitivos e desgastantes venho provocando a discussão com frequência juntando as pessoas com a mesma linha de pensamento para construímos uma nova geração de aplicações.

Os momentos de crise disparam as melhores conversas e reflexões do que pode ser feito para não repetirem os mesmos erros. As empresas já não dispõem de investimento ilimitados para manutenções e entregas intermináveis e isso tem contribuído para uma nova percepção que algo diferente precisa ser feito para ter novos resultados. As tecnologias evoluíram muito mais rápido que os próprios paradigmas de como se construir software.

Hoje dispomos de estratégias, aceleradores, técnicas modernas, automação, validação, ferramentas avançadas de diagnósticos que permitem novas repostas a problemas antigos e necessidades novas. Construa um fluxo de qualidade continuo e verá que o resultado ROI (Return on investment) será muito mais rápido e eficiente eliminado o retrabalho recorrente por falta de qualidade que quebra qualquer planejamento e satisfação de todos do projeto.

Eu não conheço ninguém que goste que goste de ligar para um central de atendimento e falar com o “robô”. Imagina agora o cliente ligando para a área de TI e recebendo a resposta “Na minha máquina funciona”. Essa é clássica entre os programadores. Mas também existe o outro lado onde o cliente liga e fala que está tudo parado. Após parar toda a equipe para investigar descobre-se que o monitor está desligado.

Os erros nas aplicações consomem muito dinheiro, tempo nas empresas e principalmente a satisfação das pessoas. Construir uma grande solução sem se preocupar com a operação “sustentação” é certo que os problemas vão se tornar o grande gargalo do negócio. O TCO (Total cost of ownership) aplicado na manutenção de um grande software atualmente se torna a ruína da própria empresa que simplesmente para de inovar, para de vender, para de conquistar novos clientes pelo fato de ter todos os esforços direcionados a conseguir mitigar os bugs que se multiplicam a cada modificação.

Hoje ao sair para almoçar estávamos conversando sobre que caminho seguir para o local do almoço e tínhamos duas ruas para escolher. A rua principal um pouco mais longa, porém limpa e bem cuidada e um atalho em outra rua que geralmente está muito suja. Durante o caminho eu estava comparando se fosse um software. Você escolhe o melhor caminho fazendo tudo certinho, validando, integrando ou escolhe o caminho mais rápido “sujinho” resolvendo do jeito que tem que resolver e correndo o risco de não resolver o problema e/ou criar outros novos, mas pelo fato de parecer mais barato e rápido toma essa decisão.

A maioria dos projetos de software iniciam no modo feliz e ao longo das não entregas passam a se tornar conflituosos, desastrosos e depois de um longo tempo entram em modo caos onde todas as partes já estão em conflito (usuários, equipe, patrocinadores) em um processo meio que em loop trabalhando, trabalhando sem ver os resultados.

Os gestores ignoram por padrão a qualidade, a estratégia da aplicação e demais processos de engenharia de software necessários ao reuso, padronização, estabilidade e principalmente manutenibilidade seja por falta de conhecimento ou por escolha. Em uma conta rápida dizem ser custo pensar em estratégia sendo que isso se resolve depois. Esse custo de fazer depois nunca entra no projeto até por que se torna absurdamente mais caro a medida que o processo cresce.

Algumas correções são  inviáveis conforme o tamanho do projeto face que problemas estruturais grandes na maioria das vezes estragam o software e devem ser descartados. Esse desperdício é uma verdadeira draga de recursos em qualquer empresa e uma situação muito comum em projetos de software.

Durante muitos anos venho discutindo o tema com executivos de diversas companhias, desenvolvedores, arquitetos e engenheiros de software e outros participantes do ecossistema de software e hoje temos um consenso claro que o mercado mudou e não reflete a realidade de 20 anos atrás.

A era do “Consumidor 5.0”, mobilidade, computação em nuvem e serviços tem se associado uma fase “Digital Transformation” vivida nas empresas que demandam por mais eficiência, práticas ágeis, ciclos curtos e principalmente alta qualidade para garantir uma operação continua com o mínimo de downtime e um menor tempo de recuperação cada vez mais agressivo.

Ao longo desse artigo já discutimos alguns pontos de erros principalmente da ordem cultural sobre como se construir o software, mas essa grande cadeia produtiva tem várias frentes e estou completamente com mais algumas possibilidades baseadas em evidências reais direto das trincheiras de grandes projetos que influenciam milhões de reais tocando a vida de muitas pessoas.

Ao se falar em software com erros a primeira reclamação que vem na cabeça das pessoas é a divergência de requisitos principalmente se você está falando com um desenvolvedor de software. Esse é um tema que vem sendo superado com a proximidade do cliente e práticas ágeis trocando processos imuteis por colaboração, participação mais próxima, revisões frequentes e melhoria continua.

As novas tecnologias trouxeram novos problemas digitais como a distração e falta de atenção nos projetos. Mas a falta de foco sobre o real problema a ser resolvido é um grande problema, pois você tem uma pessoa com um objetivo e ao final percebe que está implementando outra coisa diferente e esqueceu até da sua missão inicial.

Existe uma grande teoria sobre programadores júnior e sênior. Muitos gritam que precisam de bons programadores (melhores do mundo) e outros que a equipe é completamente júnior. Ao programador júnior falta a experiência, porém se for um profissional engajado ele testará melhor a sua implementação diferente de um sênior com amplo conhecimento que pode tomar ações mais rápidas, porém seu excesso de autoconfiança o impedirá de testar completamente um cenário deixando passar bugs críticos. Eu defendo um equilíbrio entre equipes e um amplo compartilhamento de conhecimento e sensibilidade de urgência favorecendo a qualidade e eficiência.

Um mau que afeta muitos profissionais e eu chamo de “Cegueira programática” parece que funciona como um vírus que contamina outras pessoas do projeto e tem como principal característica achar que tudo que ele faz é a melhor e única solução do mundo ignorando e rejeitando qualquer opinião independe do valor de negócio. Não importa o problema a ser resolvido e sim o que ele está achando que tem que ser feito. Não preciso ir longe para te mostrar exemplos de implementações “pessoais” e não do negócio.

Um fato que classifico como grave e de grande incidência é o que chamo de “
Compreensão antecipada do problema” e se manifesta pela característica de nem esperar o cliente terminar a contar o problema e já entender que tem uma solução. Esse é um fato corriqueiro nos projetos de software e recomendo você observar independente do lado que esteja. Um programador trabalha muito acelerado e pela própria empolgação natural já pensa em como resolver o problema sem terminar de compreender o objetivo.

Até esse momento eu procurei trazer alguns pontos não tão técnicos para uma melhor compreensão de todos, mas exitem coisas básicas que assustam qualquer pessoa que desejem entrega um software.

Durante anos ganhei muito dinheiro em consultoria para resolver problemas de conexões abertas da aplicação com o banco de dados. Um problema muito comum entre os programadores Web que usavam ASP clássico e remanescente ainda até os dias atuais em projetos que não usam um ORM (object relational mapping) deixando por exemplo deixando o controle da conexão com o desenvolvedor que não fecha. Em um cenário de muitos usuários rapidinho vai estourar o número limite de conexões ao banco de dados deixando a aplicação lenta e o banco de dados travado. Levanta a mão se você é da área de TI e nunca viu um cenário desse em algum lugar.

Com a popularização dos webservices como ponte de integração entre sistemas e hoje mais popularizado com o uso de API’s tornou-se fundamental para os aplicativos mobile e os programadores passaram a incluir requisições a esses serviços contanto claramente que estarão disponíveis sempre deixando de verificar erros de indisponibilidade o que provoca quebras nas aplicações e um caso simples de “erros fantasmas”.

Outro dia eu sai do sério quando um profissional me disse que estava fazendo uma requisição externa a um serviço e estava de boa, pois nunca ia parar de funcionar a máquina. Acho que nem um profissional iniciante tem que falar uma besteira dessas. Não deu outra, tempos depois um impedimento grave impedindo a receita do cliente pelo serviço fora que poderia ser evitado em uma validação simples contra erros timeout ou indisponibilidade.

Outra fonte boa de renda ALTA em consultoria é aplicações de alta performance. É difícil fazer as pessoas entenderem que os processadores das máquinas e cpus não estão a disposição de um único inquilino e sim Multitenancy em um farm web. Em um projeto web por exemplo um erro cometido em um cenário é multiplicado pela quantidade de usuários. Antigamente era diretamente ligado a usar indevidamente recursos como “Session” no ASP/ASP.NET e hoje até como você estrutura o seu código pode afetar no resultado.

Hoje até um loop paralelo e/ou instâncias indevidas dentro da aplicação comprometem o resultado em grande escala. E se você acha que por estar nas mais novas tecnologias como “ASP.NET MVC” não se engane que o mais acontece é tentarem transportar erros antigos para a plataforma nova. E posso garantir que conseguem.

Estamos falando em um momento orientado a API’s, serviços online, mobile e situações de performance podem comprometer o negócio. Não adianta você falar que recursos computacionais são baratos e infinitos. Difícil é convencer o patrocinador do projeto a gastar dinheiro desnecessariamente. Quanto mais tecnologia, maior a expectativa por eficiência e o software é o coração e deve funcionar a 100%.

No início desse artigo eu reforcei a importância do investimento em qualidade e estratégia. Erros como esses citados nós atacamos durante todo o ciclo do projeto. Se eu pudesse resumir o que é um software em poucas palavras posso dizer “O software é um ser vivo, apaixonante e rebelde com impactos imensurável na vida das pessoas”. Para você ver até filosofei um pouco, mas de ver os ciclos se repetirem tanto e tantas empresas desperdiçando dinheiro com ciclos repetitivos e desgastantes venho provocando a discussão com frequência juntando as pessoas com a mesma linha de pensamento para construímos uma nova geração de aplicações.

Os momentos de crise disparam as melhores conversas e reflexões do que pode ser feito para não repetirem os mesmos erros. As empresas já não dispõem de investimento ilimitados para manutenções e entregas intermináveis e isso tem contribuído para uma nova percepção que algo diferente precisa ser feito para ter novos resultados. As tecnologias evoluíram muito mais rápido que os próprios paradigmas de como se construir software.

Hoje dispomos de estratégias, aceleradores, técnicas modernas, automação, validação, ferramentas avançadas de diagnósticos que permitem novas repostas a problemas antigos e necessidades novas. Construa um fluxo de qualidade continuo e verá que o resultado ROI (Return on investment) será muito mais rápido e eficiente eliminado o retrabalho recorrente por falta de qualidade que quebra qualquer planejamento e satisfação de todos do projeto.

Junte-se a esse movimento de transformação digital, construindo aplicações Enterprise utilizando novas tecnologias para gerar novos negócios. Faça contato e conversaremos na 2PC  respeito.

Ramon Durães
CEO, 2PC IT Services
MVP, Visual Studio ALM
PSM, CSM, PSD, LKU