Não é Máquina Atolada. A Performance É Que Foi Prô Brejo...

Wasting Time in the Lab - 07
Foto: Kenneth Kully

Uma cena real entre tantas que acontecem todos os dias: Digito o código para uma pesquisa relativamente simples, num sistema rodando no servidor de uma rede local.

No momento, o sistema tem apenas 11 usuários no total (maioria nem está sentada no computador), numa estrutura supostamente feita para suportar centenas ou milhares de transações simultaneamente.

Depois de dois segundos a coisa já está irritante. Cinco, dez, quinze, dezoito... vinte e oito... trinta e cinco segundos depois, finalmente, volta a tela de consulta, um simples retorno de poucas linhas, a partir de uma tabela que deve ter uns dez registros, e olhe lá.

Outra transação que vai procurar dados de cadastro mais completos, noutra tabela com algumas centenas de milhares de registros, não me interessa quantos na verdade, demora também intermináveis segundos.

E não se trata de máquina "atolada" (carregada demais). Sobre isto veja a matéria: Adicionar hardware não compensa software lento.

Será que o pessoal esqueceu que existe uma coisa chamada continuidade de pensamento? Se o usuário que está no terminal demorar para ter sua resposta, vai inevitavelmente perder a linha natural de raciocínio. Resultado: menor produtividade, alavancada pelo mau resultado do software, neste caso.

Claro que a culpa podia ser do hardware, isto acontece também. Mas já abordamos performance em posts anteriores e, em pleno século XXI, fazer software que ofende até a paciência dos mais ancestrais anciões, é no mínimo, uma demonstração torpe do mau uso dos recursos  de que dispomos.

Para quê tanta sigla bonitinha, framework daqui e dali, metodologia de escolinha do Professor, se o resultado é francamente ruim?

Olha gente, temos um mercado internacional, global, conectado via internet. Amplo acesso a informações e possibilidades inúmeras de pesquisa e troca de informações com outros profissionais para se fazer um trabalho decente.

E porque tantas e tantas vezes vemos este péssimo resultado nas nossas empresas? Muitas vezes é para que um empresário sem nenhum escrúpulo, ou apenas incompetente, pressione suas equipe até arrancar sangue, mas apenas conseguindo resultados medíocres, porém ganhando alguns poucos tostões nas costas dos demais, quando poderia ter uma lucratividade muito maior.

Ou quem sabe para que algum líder de projeto mirabolante coloque todas presunções possíveis, agregando tanta tralha no sistema que a coisa se arrasta.

Ou passando um paninho naquele velho remendo de sistema, sem nunca se importar em corrigir, muitas vezes, pequenas coisas que melhorariam, e muito, o resultado.

Eu alterno as funções de desenvolver e de usar software. E olha, quando eu estou sendo o cliente, me pergunto se as pessoas lá do outro lado, lembram que usuário também existe.

Velocidade de sistema é um fator crítico. Infelizmente a quantidade de MIPS (milhões de instruções por segundo) parece servir mais para mascarar serviço mau feito do que para fornecer resultados efetivos, e rápidos.

Novas versões de ferramentas de software e  hardware ajudam um pouco, mas a construção do produto final ainda é a principal responsável por um produto bem feito.

E ainda tem empresário que reclama porque as suas equipes são dispersas ou dormem no computador.

Muitos, talvez nem tenham percebido.




Leia também:

• Adicionar Hardware Não Compensa Software Lento
• Performance: Quando A Culpa Não é do Banco de Dados
• Como ser um bom programador

Imagem: "Okinawa Soba", sobre a lentidão no sistema.

05/04/2010

.'.