Produzir software é uma atividade recente ( 50 anos mais ou menos) . Ainda estamos vivendo o tempo em que se testam formas de fazer software, vender software e chegar em um modelo coeso. Contudo, neste tempo algumas leis foram empiricamente levantadas. Empiricamente significa que foram levantadas de dados reais de projetos reais e extrapoladas para qualquer projeto.
Estas leis são muito importantes e são para o mundo da criação do software o que as leis de Newton são para a física ou as leis de Asimov para a robótica. As leis de regem o desenvolvimento devem ser a base para novos trabalhos, inovações e progresso da forma como fazemos software. É preciso entender que estas leis não dependem da tecnologia utilizada e por isso são válidas em qualquer tempo.
“O tempo necessário para criar um software completo é infinito“
Esta lei é simples, mas tem consequências muito complexas. Significa que nunca você poderá alcançar o software completo. Isto pode parecer castrador, mas significa realmente que temos que aproveitar melhor o tempo e tentar não criar o software completo, mas o software “completo o suficiente”. O conceito de “suficiente” leva a considerações de necessidade, disponibilidade de recursos e outros constrangimentos. Por outro lado, deixar o tempo ser uma variável em vez de uma constante levará um resultado absurdo. Ou seja, se você tem um software suficiente você deve estipular um período para o seu desenvolvimento.Concluímos , portanto, que o prazo do desenvolvimento nunca é uma variável. É a condição de “suficiente” que é a variável. Dito de outra forma, o prazo sempre é fixo e o conjunto de funcionalidades sempre é variável.
“O trabalho se expande pelo tempo disponível”
Isto significa que em qualquer tarefa, projeto, atividade aquilo que houver para fazer será diluído no tempo que for estabelecido para a realização desse trabalho. Ou seja, em outras palavras dado um certo trabalho e um certo período de tempo, nunca a atividade será realizada no inicio do período , deixando o final do período sem nada para fazer. Isto é outra forma de dizer que : o trabalho nunca estará pronto antes da data final do prazo.
Sindrome do Estudante
“O inicio do trabalho acontece no ultimo momento possível antes do final do prazo”
Isto significa que você designar alguém para uma tarefa e lhe der um prazo, a pessoa irá protelar o inicio da atividade até o ultimo momento possível. Este limite é imposto pela própria pessoa que irá realizar a tarefa. A pessoas faz isto para poder aproveitar o principio do prazo que lhe deram para fazer outras coisas. Se chama “do estudante’ por é exatamente assim que um estudantes se comporta com o estudo ou deve de casa. Sempre é feito na ultima hora. Mas sabemos que nem todos os estudantes fazem isto. Logo, o síndrome do estudante, como outros síndrome pode ser controlar através de treinamento. O síndrome do Estudantes aliado à lei de Parkinson torna um problema em um risco e um potencial desastre. A Lei de Parkinson não pode ser alterada, mas outros fatores devem ser minimizados.
“80% das consequências se devem a 20% das causas”
Este principio tem várias aplicações práticas. A primeira é que 80% dos bugs resultaram de 20% do código. A segunda é que 80% do trabalho será feito por 20% da equipe. O problema do principio é que você não sabe à partida quais 20% causarão quais 80%. É por isto que sempre ha que vigiar por um bom design e uma boa codificação porque você sabe que irá alterar pelo menos 20% do software porque irá causar 80% dos problemas. É também por isto que é tão importante a disseminação de informação e cultura na equipe , pois se acontece alguma fatalidade com os 20% que realizaram 80% do trabalho, a empresa terá um problema muito grave, sendo possível até que não consiga acabar o software.
“A explicação de um fenômeno deve ser baseada no mínimo possível de premissas, eliminando aqueles que não fazem diferença para as predições observáveis”
A Navalha de Occam ( também conhecido como Principio de Parcimônia) é uma ferramenta de raciocínio muito aplicada em ciências naturais. Ela pode ser aplicada no mundo do software de várias formas. Duas são realmente importantes. Durante o levantamento de requisitos aprenda o máximo possível sobre as regras de negocio. Esta fase é chamada Coleta. Depois analise como essas regras de relacionam. Esta fase se chama Analise. Por fim, simplifique e remova as regras que não são necessárias e/ou que derivam de outras regras. Esta terceira parte é chamada Síntese. Hoje em dia as pessoas falam muito em analise. Temos até os Analistas. Mas o que realmente é importante é a síntese. É a síntese que cria um software mais simples porque em vez de implementar 100 regras você implementa 10 que produzem o mesmo resultado. Por outro lado, ao escrever código, o código deve envolver o menor numero possível de parâmetros. Sempre que um parâmetro poder ser inferido de um conjunto de outros, esse parâmetro é desnecessário
A redação desta lei pode ser escrita então em temos mais adequados ao desenvolvimento de software :
“A especificação de uma regra do sistema deve ser baseada no mínimo possível de premissas e parâmetros, eliminando aqueles que podem ser derivadas das outras.”
Esta lei é conhecida na cena de desenvolvimento pelo acrônimo KISS (Keep it simple, stupid. Particularmente eu acho acrônimo ofensivo. Realizar a síntese não é trivial e a pessoas não conseguir fazê-lo não a torna estupida. O principio KISS realmente utiliza a palavra estupido no sentido contrário. O principio KISS parte do principio que a pessoa irá se esquecer de detalhes e do por quê de certas decisões. Ou seja, assuma que você é estupido, e por isso mantenha as coisas simples. Eu acho que a Navalha de Occam é muito mais elegante, e aplicando a Navalha de Occam ao principio KISS podemo facilmente concluir que a premissa que a pessoa é estupida é irrelevante.
“Adicionar pessoas a um projeto não diminui o seu tempo de execução, só o aumenta”
Esta lei é bem conhecida e tem várias outras redações possíveis. A redação mais simples e conhecida de todos nós é :
“A tarefa de gestação de uma criança demorará 9 meses. Não importa quantas mães forem designadas à tarefa”
Basicamente esta lei representa que as tarefas têm um tempo que lhes é inerente e que mesmo com todas as ferramentas do mundo e a melhor inteligencia não dá para realizá-las mais cedo que um certo limite. Por outro lado, adicionar pessoas a um projeto multiplica a rede de canais de comunicação. Se você tem 2 pessoas em uma sala, A e B, você tem 1 canal de comunicação (A-B). Com 3 pessoas você tem 3 canais (A-B, B-C, C-A). Com 4 pessoas você tem12 canais … em geral com N pessoas você tem N*(N-1) canais de comunicação. A cada pessoas adicionada você gera 2(N-1) canais. Para resolver estre problema as empresas tendem a usar um modelo de hierarquia como no exercito. Isto funciona se um dado grande grupo de pessoas faz a mesma atividade. No exercito quando a cavalaria ou a infantaria são mandadas “atacar” cada individuo sabe o que tem que fazer, e o que ele tem que fazer é igual ao que o outro está fazendo. Não ha instruções especiais para cada individuo. Contudo, mesmo no exercito, o grupos de operações especiais não funcionam neste modelo. O modelo usado em comandos especias é um modelo em estrela. O grupo é pequeno, e cada pessoa tem comunicação apenas com um individuo que lhe passa instruções com pormenor. Ou seja, quanto mais especifico são as instruções ao individuo, menos um modelo hierárquico é adequado. No modelo em estrela adicionar uma pessoa cria apenas 1 canal, e não 2(n-1) canais.
“90% de tudo é CRUD”
Esta revelação é chocante. Se você não se sentiu chocado por ela, você não entendeu direito.Lei de novo. Ah! claro, CRUD significa “Create, Retrive, Update, Delete” as 4 operações básicas em um sistema de dados. Várias implicações saem desta revelação. A primeira é que se você não tem um mecanismo de persistência robusto, fácil de usar, você está indo para um buraco negro e profundo. A outra é que, mesmo mecanismos que não parecem CRUD são de fato CRUD. Repare que a revelação não diz que 90% é cadastros e sim que 90% é crud. Cadastros são uma parte do problema, e cadastros em si mesmos são 90% CRUD, mas a revelação é o sistema, como um todo é 90% crud.
A revelação é chamada assim porque dá base interpretativa à Lei dos 90%, que diz :
“Os primeiro 90% do código são responsáveis pelos primeiros 90% do tempo de desenvolvimento. Os outros 10% do código, são responsáveis pelos outros 90% do tempo de desenvolvimento.”
Confuso ? Sim. Por isso que a Revelação de Sturgeon é tão importante e tão profunda. Podemos entender da seguinte forma. Se 90% de tudo é crud, então CRUD é sempre parte de 90% de tudo.Portanto, 90% do projeto é criar o CRUD em sim. Os outros10% é usar o CRUD. Mas os outros 10% são a razão de porque você precisou criar o crud em primeiro lugar, logo 10% são responsáveis pelos 90% do tempo de desenvolvimento.
A leis dos 90% lida na sua forma pura, leva a considerar que o projeto demora 180% do tempo. Claro que é uma provocação, mas a Revelação de Sturgeon torna explica realmente muitas coisas, sem provocação.
“Para cada ação de engenharia acontece uma ação social igual e oposta”
Esta lei é uma paráfrase da segunda lei de Newton também chamada Segunda Lei de Augustine. Esta lei explica várias coisas, mas entre elas a dificuldade que o corpo técnico tem em fazer seja o que for sem a interferência do resto das pessoas do projeto. Quem é técnico se preocupa com mecanismos, variáveis, razões, e emoções que são irrelevantes ao software ou a criação do software. E por simples desconhecimento, qualquer ação que parte dos técnicos é vista com preocupação e descrédito o que leva a uma pressão social de a contrariar. “social” aqui não significa “da sociedade” mas “por meios sociais” em oposição a “por meios técnicos”. É por isto que soluções brilhantes podem ser destruídas por gostos e desgostos do cliente, gerentes, diretores , com base em … Bom, com base em nada , realmente. Não existe nenhuma razão racional, apenas um desconforto em aceitar a ação técnica. O curioso é que nas poucas vezes que uma ação técnica consegue vencer o obstáculo da reação social, as pessoas quase sempre se surpreendem com os resultados.
“À medida que a frequência de falsos alertas de problemas aumenta, a credibilidade de alertas subsequentes diminui”
Quando tudo o que o usuário não espera ver na tela é um bug, mesmo quando é um aviso do sistema dizendo que o usuário fez algo errado (ou seja, mesmo quando é um erro previsto). Quanto todos os bugs são críticos e impeditivos, menos críticos impeditivos eles são de fato. Esta lei representa o desconhecimento que os usuários e clientes têm do software que eles mesmos encomendaram e a tentativa estupida de manipular o fornecedor dizendo que tudo é erro e tudo é impeditivo para. Esta lei é fortemente presente em contratos de risco em que o cliente consegui colocar o fornecedor em uma posição de dívida e recompensa futura. Ou seja, tudo o que o cliente quer mudar, ele considera um erro. Isto porque o contrato considera que apenas quanto todos os erros estão resolvidos é que o software está pronto e o fornecedor irá receber seu dinheiro. Ora, isto é uma falácia (Lei fundamental do software – nunca todos os erros estarão resolvidos) . Assim o fornecedor se colocou em um situação em que perde sempre que o cliente encontra um erro. Então, tudo o que o cliente encontra é um erro para forçar o fornecedor e fazer o que se pede. O mesmo principio é usado com a prioridade. Tudo é impeditivo para que o fornecedor sinta que não irá receber o seu dinheiro se não resolver aquele problema.
Sabendo desta lei os fornecedores devem realizar bons contratos, com estipulação especifica do que significa “impeditivo” e “erro”. Os fornecedores deve aconselhar e treinar o cliente a entender a escala. O fornecedor deve medir a razão “falsos alertas” / “todos os alertas” e a sua frequência. Sempre conversar e mostrar estes números ao cliente explicando que isto está atrazando o projeto e causando esforço desnecessário. Claro, que medidas de minimização do problema devem ser propostas e aplicadas tais como o treinamento, a redação de manuais e o teste acompanhado.
“Dentro de cada grande problema, existe um pequeno problema lutando para aparecer”
Considerado a Lei de Pareto é sabido da probabilidade de um grande problema pode ser originado um pequeno problema. O que a lei de Hoare no diz não isso. O que ela no diz é que depois de resolver um grande problema ou enquanto um grande problema é resolvido, pequenos problemas aparecem. Isto leva à multiplicação dos problemas e por consequência a um aumento no esforço de corrigir o problema original. Por outro lado, podemos interpretar que todo o grande problema é constituído de pequenos problemas.
Esta lei está diretamente relacionada com o problema da manutenção e como o design do sistema têm que ser simples de forma a que cada pequeno problema seja o mais facilmente solucionável, já que é bem provável os encontremos quando resolvemos problemas grandes.
“Uma atividade sempre consome mais tempo do que esperado, mesmo quando você leva em consideração a Lei de Hofstadter”
Está é uma lei recursiva. A recursividade dá-lhe um ar nerd, mas realmente é necessária. Esta lei significa que você sempre irá estimar errado a duração de uma atividade e/ou ela sempre demorará mais do que esperado por si, mesmo quando você conhece esta lei, ou seja, mesmo quando você estima a mais do que a sua intuição. Aconteceu comigo quando escrevi este post. Afinal quão difícil é elencar o top 10 das leis do software. Bem, é mais difícil do que parece…
Existem muitas outras leis e corolários relacionados ao software [1][2]. Tomeis as 10 que são mais genéricas e com as quais me deparo todos os dias. Existem muitas outras especificas de tecnologias, situações, tipos de software , algumas ligadas a harware como a famosa Lei de Moore ou algumas demasiado genéricas para serem elencadas como leis de desenvolvimento como a Lei de Murphy ( “Se algo errado poder acontecer, irá”)
Em próximos posts irei discorrer sobre como estas leis se relacionam ao Scrum tentando demonstrar que porque o Scrum se aproveita destas leis, ele funciona. Também tentarei falar sobre leis mais próxima ao código e ao design que deriva destas leis mais genéricas.
Este post foi reescrito devido à perda do post original em uma atualização. O texto original é bem diferente deste. Não foi minha intenção escrever algo diferente é que simplesmente não tenho como reproduzir o original. Contudo, acho que este texto é muito superior ao outro e convido-vos a relerem.
[…] sabemos pela lei fundamental do software : um produto de software nunca está pronto. O que significa que ao longo do tempo as pessoas […]
[…] leis do desenvolvimento de software são levadas em consideração para criar um processo que não lute contra o inevitável, mas se […]
Bom post, mas sempre é bom ver erros de concordância e de português.
Parabéns novamente.