No artigo abaixo Mauro Sant’Anna aborda a questão da falta de coerência entre os programas de computadores e o mundo físico, gostaria antes de tudo de dizer que concordo com ele, mas ... faltou alguma coisa. Faltou uma analise mais profunda do problema, o artigo peca em apenas mostrar o problema e dizer a solução, e este é um problema não só do artigo, mas do mundo contemporâneo, ele existe na medicina onde o paciente se queixa de dor de cabeça para um médico e leva um analgésico para casa sem nem mesmo saber o que tinha.Quem nunca colocou um “IF mágico” no seu programa sem saber a razão do erro que atire a primeira pedra. Pois bem, vamos pensar um pouco mais sobre o desenvolvimento de software, mas desta vez vamos Pensar, com P maiúsculo sem ficar presos a pré-conceitos, no sentido original da palavra.
Quando estamos criando software, estamos na verdade aplicando regras sobre dados. Agora pense um pouco no mundo lá fora, o que existe alem disto? O mundo nada mais é que a aplicação das leis naturais sobre a matéria. Lei natural: os objetos de menor densidade relativa ficam acima dos de menor densidade relativa. Objetos: Submarinos e aviões. Quando aplicamos a lei sobre os submarinos na água, vemos que estes possuem uma “densidade relativa” maior que a água, portanto ficam por baixo dela. Já ao aplicarmos a mesma lei nos aviões, os mesmos são mais “leves” que o ar, portanto voam. Quando estamos desenvolvendo software, estamos criando nossas próprias regras que são aplicadas sobre nossos próprios dados, assim quando estamos criando software estamos criando nosso próprio mundo! Estamos nos tornando Deuses deste mundo! Seja lá o que isto quer dizer. Podemos criar as leis que quisermos, e aplicá-las nos dados que quisermos, no entanto existe uma restrição. Assim como no mundo, uma lei não deve ir contra outra ( por favor digam isto aos políticos atuais! ) em nosso software uma regra não pode contradizer outra. Isto se chama “Modelo”.
Este é o grande problema do artigo citado, ele não fala do modelo, apenas das regras. Alias, este é O Problema dos softwares
Edson acredita no conhecimento e que siglas como “KISS” são uma desculpa para quem não quer pensar.
Assunto: Submarinos Voadores
Veja uma situação: eu tenho um problema que pode ser resolvido pela criação de um novo software. Até aí tudo bem. Mas como o problema envolve outras áreas da empresa, começam a aparecer outros “interessados” apresentando “sugestões”. Como no desenvolvimento de software qualquer sugestão pode ser implementada “com apenas algumas linhas de código”, tudo parece fácil, especialmente se quem vai ter que criar as tais poucas linhas de código são os outros. O projeto então vai “evoluindo” até que fica irreconhecível e possivelmente nem fazendo mais direito a função original, sobrecarregado pelas “novas ideias”.
Isso é mais difícil de acontecer no mundo real, onde as restrições físicas são mais óbvias. Por exemplo, digamos que estou desenvolvendo um mini-submarino de pesquisas oceânicas e alguém chega e diz que “seria muito útil se o submarino pudesse voar”. Esta pessoa passa então a descrever os múltiplos benefícios de um submarino voador, quem sabe até inspirado em algum episódio do antigo seriado de TV “Viajem ao Fundo do Mar”.
No entanto, esta é uma ideia evidentemente impraticável. Qualquer coisa voadora tem que ser leve, o que significa possuir uma densidade total baixa. Já um submarino é algo que, por definição, afunda na água. Tem que ser ligeiramente mais denso que a água. Na verdade, seu material de construção tem que ser bem mais denso, para compensar o ar que ele inevitavelmente carregará de forma a poupar a vida dos seus ocupantes. A ideia do submarino voador é descartada na hora, a realidade física rapidamente se impõe.
Já no desenvolvimento de software, ideias disparatadas não são tão fáceis de descartar.
Pelo contrário, é comum que as sugestões se acumulem de forma a termos no final um verdadeiro submarino voador, que além de ser um péssimo avião, é um submarino medíocre. Isso é particularmente comum quando o produto é projetado “por comitê”, onde cada pessoa remotamente interessada é convidada a participar do processo.
Pior: como o processo é assim vulnerável, pessoas que tenham motivos inconfessáveis para que o projeto não se realize podem até se aproveitar para injetar necessidades espúrias, de forma a sabotar o projeto. Evidentemente esse não é um problema técnico e sim de gestão. Existem algumas maneiras de combater esse problema. Uma delas é ter no projeto um “gerente de produto” que decide o que será feito e quando. Essa pessoa não só deve conhecer o negócio como também ter tempo para usar o software e discutir com todos os envolvidos. Por causa disso, ela usualmente não é a pessoa com o cargo mais alto - chefe nunca tem tempo livre.
Outra boa saída é entregar versões consistentes e funcionais com frequência - mesmo que incompletas. A entrega frequente traz vários benefícios:
·Os usuários podem utilizar o software antes, usufruindo de seu valor;
·Ajuda a definir melhor que funcionalidade é realmente importante por ter base na realidade;
·Pune os maus desenvolvedores - que terão dificuldades em fazer entregas antes do fim do projeto, sem o famoso “período de graça” inicial, onde mesmo que pouco seja feito é difícil perceber;
·Tira pressões injustas de bons desenvolvedores, que têm seu trabalho reconhecido cedo.
O gerente de produto também ajuda a manter uma visão coesa e consistente do software, algo muito importante ao longo de sua vida, facilitando e barateando futuras manutenções e evoluções.
Mauro Sant’Anna
Acredita no princípio 'KISS': Keep It Simple, Stupid.
Postagens
