Há alguns meses, surgiu uma questão a respeito da qualidade. Enquanto pensava na afirmação, "Com certeza a qualidade interessa a todos, sempre", e fazendo um paralelo com o nosso dia a dia, percebi que esta frase não é verdadeira. Nem sempre queremos qualidade, ou estamos com possibilidades de pagar por ela.
Ontem, bebendo um chopp com um amigo do trabalho, ele me disse: "Cara, a única coisa que não é passível de discussão é qualidade". E eu respondi: "Não é bem assim". Dada a minha fama de desenvolvedor psicopata, obviamente, a minha afirmação gerou um certo espanto, que ficou clara na expressão dele.
Este assunto é delicado e gera controvérsias. Trazendo para o mundo real, vou citar um exemplo, que acredito ser pertinente.
No nosso dia-a-dia, na verdade, nem sempre estamos atrás da qualidade. Pretendo, neste ano, comprar um autorama de Natal para meu filho de 4 anos de idade. Entretanto, não sei qual seria a reação dele ao brinquedo e nem sabia se ele seria capaz de brincar. Então, na semana passada comprei um mais barato para ver se no Natal poderia comprar um "de verdade".
Este foi apenas um pequeno exemplo, com um caso onde a qualidade foi postergada. Existem outros no cotidiano, como a compra de um carro, de roupa, relógio e por aí vai.
Voltando ao desenvolvimento de software, acredito que o problema central seja a visão superficial de alguns clientes no que diz respeito à qualidade de software. Para estes clientes, qualidade significa correctness e uma boa interface (beleza e usabilidade).
Na minha visão, esta definição de qualidade está incompleta, pois é superficial. Como o Yoshima falou no Maré de Agilidade e eu já venho dizendo desde o início deste blog, a maior fase do tempo de vida de um software, normalmente, é a manutenção. Assim, a qualidade de código é importante, pois está intimamente ligada a esta fase. Mas o cliente não tem visibilidade direta disso, o que pode sugerir pouca importância do código bem desenvolvido.
Por não ter esta visibilidade, não fica claro para o cliente que, pagando menos, ele pode obter correctness e um boa interface, mas um péssimo código, o que vai dificultar muito a fase de manutenção.
Uma possível analogia no mundo fora do desenvolvimento de software, seria comprar uma Ferrari com um motor de Fusca. Neste caso. o desempenho do carro deixará claro o motivo daquela Ferrari ter sido tão barata. Da mesma forma, o baixo desempenho na fase de manutenção (dificuldade de alterar, incluir e excluir requisitos) pode indicar o motivo daquele software ter sido tão barato.
E você? Quais são as suas reflexões sobre a qualidade de software?
