Porque as Jóias de Software são raras

Encontrar atualmente um software que seja uma “jóia” é algo a ser considerado raro, principalmente se levarmos em consideração a sua estrutura simples e organizada, projetado para atender corretamente as funcionalidades com uma boa reusabilidade como sugere Parnas(1996).

Existem diversos questionamentos a respeito do qual seria a melhor a construção de um software, portanto, alguns autores que conseguiram atingir esse objetivo buscam sugerir o que devemos fazer para seguir essas ideias e torná-las mais práticas. Algumas publicações de artigos deveriam ser vistas por todos os profissionais que desenvolvem algum software a fim de que possam se orientar e refletir nos exemplos de sucesso, para ter insights e ideias inovadoras.

Porque não conseguimos reproduzir então essas ideias advindas desses autores? Será que a cultura em que estamos inseridos tem nos permitindo realizar mudanças? Quais caminhos devemos seguir se queremos desenvolver softwares como “jóias”? Apesar de todas essas referências ainda não temos produzido softwares conforme pregam os criadores destas “jóias”.

Um dos fatores que atrapalha a criação de uma “jóia” como um software e o fato das pessoas e ferramentas modificarem constantemente as funcionalidades existentes de forma a adicionar novas integrações sem avaliar o impacto que elas possam ter, alterando assim o seu comportamento e tornando ainda complexo a sua estrutura.

A compatibilidade conforme Wirth(1995) aborda pode estar concentrado em um único motivo: “o deginer” que está ruim. O que leva um software a ficar incompatível seria o excesso de inclusão de componentes sendo um “peso” para a inclusão de elementos necessários para um produto compatível e adequado se tornando mais “magro”. A grande preocupação em torna o software mais saudável, principalmente em relação ao mercado e que ele deve continuar atendendo ao que era utilizado por seus usuários, ou seja, devem ser mantidas as funcionalidades existentes.

As limitações da estrutura também afetam o software, ou seja, o hardware interfere muito para ele também ser uma “jóia”, pois, se no momento de tentar simular e tivermos que fazer a re-adequação da sua estrutura, estará fazendo retrabalho do que não foi previsto para que alcance as necessidades do nosso usuário.

Oferecer novos recursos e não sobrepor seria o ideal para o software, visto que a maioria deles não foi criada do zero, ou seja, não ficamos “reinventando rodas” para elaborar uma solução que atenda a um usuário em relação aos seus pedidos.

Portanto, não adianta apenas modificar se não forem oferecidos novos recursos, e que não seja considerados e mantidos os recursos antigos, tirando apenas a “gordura” que ele possui tornando-o muito diferente do que ele realmente precisa ser.

Entender a adequação de um design em detrimento de uma linguagem no desenvolvimento de um software é algo que precisa se pensado, principalmente se formos analisar que as linguagens utilizadas ainda não são totalmente conhecidas e disseminadas pelos desenvolvedores, ou seja, ainda necessitamos de uma mão-de-obra qualificada por parte dessas pessoas que fazem a construção de um software.

Não podemos também dispensar que para um software ser construído deve ser elaborado através de um Projeto, ou seja, o planejamento do que fazer pode evitar problemas na construção dessas “jóias” como: utilização dos princípios de decomposição; utilização das estruturas hierárquicas; utilização dos desenhos para as interfaces;

Além disso, alguns professores de engenharia de software segundo Parnas (1996) sugerem algumas regras básicas para que possamos alcançar esses objetivos: projetar antes de programar; documentar o seu projeto; rever e analisar o projeto documentado; analisar a coerência da aplicação com o projeto. Essas regras devem ser aplicadas tanto para as questões do software, quanto para o hardware.