Leis gerais do desenvolvimento 

Dec/11
10

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.

1. Lei Fundamental Do Desenvolvimento de Software

“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.

2.Leis de Parkinson’s

“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.

3.Lei de Pareto

“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.

4. Navalha de Occam

¬†“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.

5. Lei de Brook

“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.

6. Revelação de Sturgeon

“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.

7.Lei da Ação-Reaçã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.

 8. Lei dos Falsos Alertas

“√Ä 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.

 9. Lei de Hoare

“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.

 

10. Lei de Hofstadter

“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.

 

4 comentários para “Leis gerais do desenvolvimento”

  1. 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.

  2. […] sabemos pela lei fundamental do software : um produto de software nunca est√° pronto. O que significa que ao longo do tempo as pessoas […]

  3. […] 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 […]

  4. Bom post, mas sempre √© bom ver erros de concord√Ęncia e de portugu√™s.
    Parabéns novamente.

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos