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 periodo de tempo, nunca a atividade será realizada no inicio do perido, deixando o final do periodo 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 minimo 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 sintese. É a sintese 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 minimo possível de premissas e parametros, 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 hirarquia 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 usá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 dificil é elencar o top 10 das leis do software. Bem, é mais dificil 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.

O Java 7 traz algumas alterações na linguagem Java,  algumas alterações na JVM e algumas API novas. Além disso temos a primeira alteração no bytecode desde sempre. Podemos dizer que o tema do Java 7 é “Criar caminho para o Futuro” (leia-se Java 8 e 9). Como alterações na Linguagem temos : Swicth com Strings ,melhor inferência de tipos com operador diamante e alterações para invocação de var-args , melhores literais para números,  base binária e melhor suporte a tratamento de exceções (multi-catch , re-throw e try-with-resources) e suporte a unicode 6.0.  Para as API temos a nova API de processamento paralelo Fork-Join  e a nova , muito aguardada , FileSystem API (parte do novo pacote de IO:  NIO.2) .Existem também alguns melhoramentos na API java.util.Locale para  internacionalização como a nova enum Locale.Category que permite distinguir objetos Locale para display e para formatação. A NIO.2 traz também suporte a mais protocolos de cominicação como SCTP , SDP entre outros. A alteração no bytecode é a nova instrução invoke dinamic que traz consigo a nova API de manipulação de métodos. Além disso muitas melhorias na renderização. A lista completa de mudanças na pagina de release da Oracle

Não vou exemplificar cada alteração existem muitos sites sobre isso. Quero, em vez, me debruçar sobre  as causas e consequencias das alterações.

Switch com Strings. Esta funcionalidade é a mais perigosa de todas. Não vai ajudar a escrever programas melhores já que vivemos escrevendo programas sem ela ha 15 anos. Adicionar esta capacidade só vai ajudar a cria Programas Orientados as Strings (POS) ou pior, programas orientados a gambiarra (POG). Uma discussão interessante sobre switch e sua historia aqui. Mas o objetivo desta funcionalidade não é melhorar o Java. Esta era uma requisição de melhoria desde o java 1 que não viu a luz do dia devido ao problema associado à função de hash usada na classe String que foi modificada e melhorada ao longo do anos. É que, para isto funcionar, é necessário usar a função de hash para transformaro switch de string em switch de int que é o que realmente funciona eficientemente, mas para isso o resultado do hash tem que ficar hardcoded no .class. O Java 7 deu este passo estabelecendo que a implementação de hashCode do String não irá mudar mais. Mas será que não ? Eu por mim vou continuar não usando Strings para este tipo de coisa. Aliás uma regra bem válida do Efective Java.

Melhorias na inferência de tipos. O operador diamante é bem vindo já que nos livra de repetir um monte de assinaturas de tipo. Para quem já escreveu mapas de coleções sabe do que estou falando. Além disso usar tipos genéricos em var-args não causa mais um aviso do compilador.  Nada do outro mundo para o programador, mas o trabalho que o compilador faz para inferir os tipos e , no seu melhor, evitar erros, é extraordinário. Uma alteração direcionada a nos fazer escrever menos respondendo às criticas que o java é muito verborraico.

A possibilidade de escrever numeros em base binária é relativamente interessante. Útil se você mexe com protocolos/arquivos binários. A nova possibilidade de separação de algoritmos com underline ajuda bastante a formar os bytes ou as palavras. Uma mudança à primeira vista estética, mas que é direcionada a usar java como uma linguagem de “baixo nível” para ler e escrever binário.

A grande alteração da linguagem são as novas funcionalidades relacionadas ao bloco try-catch. A primeira é a possibilidade de capturar multiplas exceções de um catch só. Isto ajuda a escrever menos blocos de codigo e ajuda a seguir o principio DRY (Don’t repeat yourself – Não se Repita). Contudo criaria um problema caso você pense em relançar a exceção.  A inferencia de tipos entre em jogo aqui também. Ao relançar a exceção o compilador sabe fazer o traking de quais exceções são possiveis dentro do try e portanto quais são possiveis para relançamento.

A outra mecanica que se aproveita do relançamento é o novo try-com-recursos que é uma forma de trabalhar com recursos “fechaveis”. A nova instrução toma conta de chamar o .close no momento certo e tratar as exceções que são lançadas no close.   É um problema quando você acessa o banco, dá erro no resultset você captura e fecha a conexão, mas ai dá erro no fechar da conexão. A exceção que você recebia era a que aconteceu no close e não a que aconteceu no resultset. Isto era realmente um problema e se você quisesse controlar isto. Agora, o java 7 modificou essa regra – desde que use o try-com-recursos  – em que a exceção lançada é a exceção original, e a excação secundária (chamada de exceção suprimida) é adicionada ao stackstrace de forma “paralela” usando os novos métodos na class Throwable addSupressed e getSupressed. O controle de exceção ficou ainda mais robusto.

isto é importante porque é usado no URLClassloader. Este é o classloader mais utilizado que não tinha uma semantica de fechamento, e agora que tem, sem um mecanismo robusto como o try-com-recursos , continuaria dando memory-leaks. A sintaxe não é a mais intuitiva (estão planejadas melhorias para o java 8), mas é uma instrução de controle muito importante e que faltava no arcenal.

O tema do Java 8 será “Multicore” e o do Java 9 “Cloud”.

Para multicore dar certo o fork-join é um framework necessário. Existiu muita polemica se seria util lançar este framework sem lançar closures (lambdas), mas acabou saindo. Lembrar que esta versão do java é mais para desenvolvedores do que usuários e em particular para desenvolvedores que desenvolvem mecanismo em cimado java (como quem desenvolver as ‘vm’ de jruby, scala , etc…) . Com a liberação “adiantada” estas equipes têm mais tempo para se preparar para o mundo com lambdas do java 8.

Para o cloud dar certo, além do multicore, é preciso abstrair o sistema de arquivos. Servidores de aplicação poderão tirar partido disto. A nova API de Filesystem permite trabalhar não apenas com discos da máquina, mas criar sistema virtuais de arquivos , por exemplo, acessar um zip como se fosse uma pasta. Isto é uma tendencia e era aguardado ha muito tempo ( aliás eu já tinha abordado este assunto de arquivos virtuais no MiddleHeaven). Mas API que fará ainda mais diferença – expecialmente para criadores de ferramentas e servidores -  é a API WatchService que permite registrar listeners para escutar quando arquivos são modificados, incluidos ou excluidos. Hoje isto é feito com threads e timers, mas com a nova API estaremos ligados diretamente ao sistema operacional que avisará a API quando algo mudar e a API nos avisará a nós. Espero que as proximas versões de servidores de aplicação se baseiem nestas features.

Resta falar sobre o invoke dynamic. Esta instrução do bytecode permite que se invoque um método sem que se saiba qual a sua implementação. A implementação do método será pesquisada em runtime. É um mecanismo bem complexo que permite criar links dinamicos com métodos em runtime. Isto é ideal para linguagens como groovy e ruby que permitem chamar métodos em classes como se eles lhes pertencessem mas na realidade não estão definidos na classe (  e sim em alguma outra classe ). Esta instrução é orientada a simplificar a vida de quem tem que implementar as vm das linguagens dinamicas e com isto tornar a JVM realmente poliglota.

A API Java foi incrementada para poder manipular métodos de forma programática. Isto é interessante porque é agora possivel criar operações de currying e outras coisas interessantes da programação orientada a funções mesmo ainda sem lambdas.

À parte da swicth de strings que navega contra a maré o resto das alterações é bastante poderosa. O ponto é que toda esta capacidade é em potencial e não muito “pártica” ainda. É mais ou menos como o generic do java 5, demorou um tempo até que as pessoas se abituassem e começassem a fazer coisas interessantes com a ferramenta. O Java 8 promete uma mega alteração da forma de programar em java, e o 9 uma mega alteração na forma como entendemos JEE  , mas o Java 7 lança as bases e traça algumas direções dando ferramentas para aumentar a eficácia dos códigos e o alargamento da base de linguagens que rodam na JVM.

Se começasse um projeto novo hoje, muito provavelmente usaria java 7, não pelo que ele traz de novo, mas como preparação para o java 8 que, se tudo correr bem, irá ver a luz do dia em 2013.

O modelo que iremos usar como base é este (clique para aumentar):

Bom a primeira coisa é o conceito de banco e  agencia. A agencia não é um banco. E um banco não é uma agencia. O banco é uma entidade jurídica, a agencia é uma representação ( uma filial) dessa entidade jurídica. Um banco tem muitas agencias e uma agencia pertence a um banco. Portanto, não é uma relação de herança que queremos usar e sim uma composição.  Um banco tem contas, e as contas estão relacionadas a uma agencia. Portanto, a conta corrente pertence a uma agencia e não ao banco. Como a agencia pertence ao banco é possível encontrar todas as contas do banco iterando todas as agencias que o banco tem. A relação de composição da conta seria no nivel da agencia e não no do banco.

As operações de CRUD não devem estar na entidade, a menos que isto se trate de um modelo conceptual de negocio ( por oposição a um modelo de implementação). Vou partir da premissa que é esse o caso ou explicitar as operação não faria sentido algum.

Endereço é uma coisa complexa por si mesma, mas não me parece que haja um problema na sua modelagem.

O NIF não é um inteiro, é um código. Códigos devem ser representandos com String. O titulo se relaciona a vários clientes no papel de sacado, cedente, etc.. cada um destes campos é um cliente. Não ha necessidade alguma de criar entidades no meio para qualificar a relação. A relação já é qualificada pelo nome do campo no titulo. Acho que esse é o ponto mais estranho do modelo que além de inútil cria bastante confusão.

Nilson, espero seus comentários.

[Editado]
O Nilson enviou outro modelo

Vi que deu uma limpada. Ficou melhor. Mas ainda existe o problema entre o Banco e a Agencia. O Banco não têm uma campo agencia. Ele tem múltiplas agências. E cada agência tem um Banco.

O Java, e mais propriamente a Sun no seu compêndio de boas práticas, deixaram claro que a nomenclatura é vital para o sucesso de um API. A nomenclatura tem várias facetas, e todas elas devem ser consideradas.

Tipografia

A tipografia dos nomes é importante. Em java foi criado o padrão de usar nomes em Camel Case. Você deve conhecer o Upper Case ( Caixa Alta) que significa que todas as letras da palavra são maiusculas – por exemplo : SERVICODECOBRANCA -, o Lower Case (Caixa Baixa) em que todas as letras das palavras são minusculas – por exemplo : servicodecobranca. O Camel Case (Caixa Camelo) é quando todas as letras inicias das palavras são maiusculas e o resto minusculas – por exemplo: ServicoDeCobranca. Note como os seus olhos entendem melhor o camel case do que qualquer outro case já que as maiusculas atuam como separadores naturais.

Outras linguagens adotam padrões diferentes como o uso de underline (por exemplo: servico_de_cobranca) que o java utiliza também em certas circunstancias. A tipografia de uma constante é uma mistura do Upper Case com o uso de underline (SERVICO_DE_COBRANCA).

É importante que todo o seu codigo seja escrito com a mesma tipografia. Muitas pessoas se habituaram a usar o eclipse e as suas milhentas formas de pintar texto para separar as coisas, mas usando uma tipografia padronizada ( a que a Sun criou e recomendou por anos) você não precisa de cores e estilos.

Justaposição

A justaposição é um dos mecanismos que existe nas línguas para criar novas palavras. A justaposição se caracteriza por simplesmente justapor (colocar as palavras juntas) sem nenhum tipo de modificação das palavras. Por exemplo, guarda-chuva e passatempo. Note que as palavras não foram modificadas. Enquanto que outras formas de criação de palavras como a aglutinação levam à modificação das palavras originais. Por exemplo , planalto (= plano + alto) em que o ultimo ‘o’ de planalto desaparece.

A justaposição é a forma mais simples de criar nomes para classes, métodos e variáveis já que não é necessário modificar a palavra original, e, no caso, não nos precisamos preocupar com sinais como o hífen já que o Camel Case separa as coisas para nós.

Língua

É importante escolher a língua do seu código. Isto é mais complexo do que parece. A língua inglesa é mais simples de usar já que em inglês a justaposição é muito natural e soa bem. Em português nem sempre soa bem juntar várias palavras juntas. Além disso nomes de padrões de projeto são em inglês , e como veremos adiante, é comum usar esses nomes ao compor nossas nomenclaturas. DesktopSingleton (Desktop + Single + ion) soa bem melhor que TopoDeMesaSolteirao (Top da Mesa + Solteiro + ião). Poderiamos pensar num DesktopSolteiao ou TopoDeMesaSingleton, mas ai é misturar o pior de cada parte.  Usar inglês também tem a vantagem de não usar acentos e outros dilacrílicos (é por isso que se escreve facade e se lê façade), que embora a língua inglesa os aceite  ( Façade é uma palavra inglesa escrita com ç porque vêm do francês) não é comum vermos usar ( porque os teclados as pessoas que falam inglês nativamente, não têm o caractere ç).

A resistência de muitos a usar o inglês advém de dois problemas : 1) falta de vocabulário e 2) pode violar a regra de que se deve usar um glossário de projeto. O primeiro motivo é fútil e qualquer dicionario pode resolver isso. O segundo motivo é mais sério. Se o cliente fala português nativamente e define seus conceitos de negocio em português porque então traduzir isso para inglês? Algumas coisas até seriam triviais : produto -> product , cliente -> costumer , mas fatalmente cairíamos no Nota fiscal -> ? , Pedido -> ? ou CPF -> ? . Assim muitos preferem usar uma mistura de inglês com português, usando o inglês para código de infra e padrões e o português para objetos de negocio.

O meu argumento é que se você realmente quiser você consegue usar apenas nomes em inglês. O lance é utilizar o domínio em inglês também. Por exemplo, a nota fiscal é um documento que prova que o objeto é seu, que você o comprou. Desse ponto de vista ele é uma “nota de venda”  e a tradução seria “bill of safe”(literalmente nota (bill) de (of) venda (sale)).  Pedido seria Invoice, embora invoice possa ter significados mais refinados ligeiramente diferentes de pedido, mas contém os mesmos itens básicos: quais os itens, quantos, de quem, para quem. Já o CPF é algo próprio do pais e nem sequer do domínio do negocio de compra e venda. Está mais relacionado a impostos. Contudo poderíamos criar um nome que traduzisse o conceito em vez de traduzir o nome, por exemplo Individual Tax Registry Code (ITRC). Rebuscado ? Depende. Para um sistema feito em pais de língua oficial portuguesa para pessoas que falam português nativamente, definitivamente. Mas para software que será usado no estrangeiro ou que pretende se adequar a vários mercados, ou que se pretende que seja open source, talvez não seja tão absurdo.

A moral aqui é que deve ser considerado o objetivo e o publico alvo do software e do código de forma que para os usuários do software o código possa fazer sentido. Isto em DDD se chamaria de usar a linguagem ubiqua, mas na realidade estamos adequando o máximo possível o código ao glossário.  Por outro lado, se você consegue fazer código de infra em inglês por que não código de negocio ? A resposta é que você conhece o domínio “infra” muito melhor, e é natural para si – programador – usar inglês. Apenas isso.

Depois que decidir que língua usar , ou como misturar duas línguas, mantenha-se fiel à escolha.

Substantivos

Vimos várias coisas que ajudam na nomenclatura, mas existem regras para criar os nomes eles mesmos ? Existem.

Classes e Interfaces têm nomes simples que refletem diretamente os conceitos do modelo de negocio. Sem prefixos ou sufixos. Se quer modelar um cliente use “Cliente” como nome da classe. Se for uma interface não use “ICliente” por exemplo. A razão disto é simples : polimorfismo. Se eu digo “Veiculo” você não sabe se é uma interface ou uma classe. Ótimo. É assim mesmo que tem que ser. Se eu usar “IVeiculo” automaticamente estou dizendo que é uma interface, o que viola o proposito do polimorfismo.Além de que aquilo que hoje definiu como interface, amanhã pode virar um classe. O modelo evolui. O uso do I é uma remanescencia da notação hungara e é usado na corrente .NET já que essa corrente herdou várias coisas dos antepassados VB, Delphi e do codigo do windows, como comentei antes. É lícito usar o I em .NET porque essa é a convenção nesse ambiente, mas em pura orientação a objetos , e no java, não.

Se eu precisar criar um objeto utilizando o padrão Builder então justaponho os nomes como ClienteBuilder ou VeiculoBuilder. Normalmente os builders são mais usados com interfaces, mas isso não obrigatorio. Aqui a lógica é utilizar o nome do padrão como sufixo e aproveitar o nome do conceito. Usando este padrão de nomenclatura teriamos por exemplo ClienteProxy, ClienteRepository, ClienteFactory, etc… Contudo não se utiliza este padrão com singleton nem para as implementações do padrão Service. Não se nomeia ClienteSingleton. Isto pela mesma razão do uso do I em interfaces : quebra o polimorfismo e o que hoje é singleton, amanhã poderá deixar de ser.

Na questão do padrão service, definimos uma interface como o contrato do serviço e mais do que uma implementação. Cada implementação é especializada por alguma razão e isso distingue uma implementação do serviço das outras.Por exemplo , para o serviço PrintService poderiamos ter um PDFLocalFilePrintService , um SystemPrinterPrintService e um WebRemotePrintService (como exercício, experimente colocar estes nomes em português). Todas as implementações terminam com o nome do serviço mas descrevem o objetivo da implementação. É claro que a primeira implementação irá criar um PDF em disco local, a segunda usará uma impressora de fato e a terceira algum serviço de impressão via web ( sem dizer se será em uma impressora ou arquivo). Isto se aplica também ao padrão DAO (que é uma especialização do padrão de serviço) onde teremos coisas como JDBCClienteDAO ou BigTableClienteDAO ou LDAPClienteDAO. O uso de Impl com o sufixo (ClienteDAO e ClienteDAOImpl, por exemplo) além de ambíguo e desinformador (como é a implementação ?) é pura falta de imaginação.

A mesma regra de nomenclatura pode ser seguido em geral com interfaces onde antes do nome da interface é dito algo sobre como aquela implementação é diferente das outras. Exemplos classicos são ArrayList , LinkedList e HashSet e LinkedHashSet ( este é duplamente qualificado)

Este regra de momenclatura também funciona bem quando você quer juntar conceitos que não são necessáriamente padrões de projeto, mas que você definiu um conjunto de classes com um proposito semlhante, por exemplo ClienteManager se vc criou o conceito de Manager ou XMLTextTransformer se você criou o conceito de TextTransformer. Não necessáriamente estas classes herdam de Manager ou TextTransformer, pode ser uma classificação puramente conceptual. (Se for puramente conceptual recomenda-se que crie uma interface marcadora e faça todos os objetos que partilham o mesmo conceito implementá-la. Leia Herança e Interfaces para mais detalhes deste assunto)

Uma variante do padrão de sufixo indicando padrões de projeto, embora não utilize o nome de um padrão é o sufixo “Utils”. MathUtils ou DateUtils ou ClienteUtils. Este tipo de classes contém apenas métodos estáticos é final e sem construtor publico. Em certos casos é possível utilizar a variante no plural do nome como Clientes ou, retirando exemplos do próprio java : Collections e Arrays. Contudo é mais raro que esta forma de nomenclatura soe bem ou encaixe em qualquer situação.

Para classes abstratas é útil utiliza Abstract como prefixo AbstractCliente ou AbstractPrintService. Este padrão pode ser usado mesmo quando a classe não é abstrata no sentido técnico ( não é definida como “abstrat class”) mas é abstrata no sentido do modelo ou do negocio. Ou seja, olhando para o nome sabemos que não é suposto instanciarmos esta classe e sabemos também que devem haver classes herdando dela. Uma classe com Abstract no nome pode herdar de outra com Abstract no nome, contudo sabemos que no fim da linha de herança existirá pelo menos uma classe não abstrata que poderemos utilizar. Este padrão é especialmente util quando o nome a seguir a abstract se refere a uma interface, por exemplo, AbstractList do java.

Especialmente para interfaces muitas vezes elas caracterizam não entidades ( substantivos) mas ações que podem ser feitas (advérbios). Em inglês é muito fácil transformar qualquer palavra em adverbio e aqui é um dos exemplo onde é vantagem utilizar o inglês. Para um ação como Print, teriamos Printable (que pode ser impresso) ou mais complexo como Mergeable ( que pode ser jeito merge). Em português também funciona se usar o prefixo “-vel” ou suas variações como “Juntável” , “Imprimível” , “Fundível”, mas é aqui que começa a ficar esquisito. Na API do java temos Serializable e Clonable como exemplos desta forma de nomenclatura.

Um outro padrão de projeto que tem uma nomenclatura diferenciada é o Adapter. Aqui estamos tentando usar uma classe com a “cara” de outra. Para o adapter é bom usa a regra [InterfacePublica][ObjectoPrivado]Adapter. Por exemplo,  InjectorSpringContextAdapter. Daqui podemos inferir que se trata de um objeto no padrão adapter, que implementa uma interface chamada Injector e usa um SpringContext por baixo dos panos. Ou seja, o contexto do spring está sendo adaptado ao contrato de um Injector.

Resumo

Nomenclatura coerente das suas classes e interfaces é uma boa forma de documentação do ccódigo, ajuda a mantes os conceitos de negocio e os conceitos tecnicos frescos, evita ambiguidade e, se bem usada, ajuda a identificar a camada a que pertence a classe.  São regras simples que todos podemos seguir, e com isso ajudar que todos entendamos o código uns dos outros.

No mundo profissional software é feito em equipa. A equipe de desenvolvimento não são apenas os programadores. São todos aqueles que participam de alguma forma no desenvolvimento. Desde do arquiteto até o testador, passando pelo programador,  pelo gerente e até pelo representante do cliente.

O problema é que nem sempre a equipe é tratada com respeito. A principal razão para isso é que a equipa não exige respeito.  Às vezes por falta de conhecimento do seu valor ou do seu papel no grande esquema das coisas, às vezes por modéstia e às vezes por que não estão nem ai. O problema maior acontece quando ela não exige respeito porque sua qualidade é pobre.

A qualidade da equipe  de desenvolvimento é um fator a ser considerado independentemente da plataforma de desenvolvimento escolhida. Uma equipe bem treinada, afiada, com acesso a uma base de código útil que ela entenda e domine, pode ser a diferença entre o sucesso e o fracasso dos projetos.  Sim, projetos , plural.

A equipe de desenvolvimento não pode ter muitos membros, pois é sabido que apenas aumentando o número de elementos em uma equipe os problemas de comunicação crescem em relação ao quadrado do numero de pessoas na equipa. Isso leva à confusão e à necessidade de longas  reuniões constantes para que todos estejam no mesmo nível.  O tamanho da equipe é, portanto,  fundamental.

Outro fator é a rotatividade. Se os membros da equipe constantemente são substituidos a qualidade sofre porque mais tempo tem que ser passado ensinando os novos membros como as coisas funcionam. Quanto menos padronização mais dificil é essa tarefa. Um outro fator que advém de uma elevada rotatividade é a dispersão de conhecimento.  Digamos que temos 4 membros na equipe que conhecem o negocio e a base de código, se sair um por mês em 4 meses todo o conhecimento que eles tinham acumulado se perdeu. Os novos integrantes da equipa não terão o mesmo insight sobre o negócio e terão que ser retreinados.  Além disso não saberão quais decisões tecnicas foram tomadas e porquê foram tomadas levando à reescrita de novo codigo ou ao abandono do que já existe e à criação de um novo software.

Outro ponto fulcral é a capacitação dessa equipe. A experiência é importante, o conhecimento das tecnologias envolvidas é importante. É possivel criar um software com uma pessoa, e é possivel criá-lo com 8 juniors trabalhando 50 horas por semana, mas não é possivel fazer isso com a mesma qualidade e rapidez que com 4 sêniors trabalhando 7 horas por dia.  Existe um fator de eficiencia inerente à capacitação tecnica e  à própria experiencia. O sénior não vai passar 90% do seu tempo testando ideias , algoritmo ou tecnologias. Ele já fez isso antes. Ele irá passar 90% do tempo implementando features reais.  Uma equipa eficiente tende a ser pequena e a ter uma razão senior/junir elevada. Claro que, como não poderia deixar de ser, isso está longe da realidade.  Só é preciso ter cuidado quando você contrata a produção de um software que ela não esteja inteiramente na mão de juniors que por definição são menos preparados tecnicamente e com menos vivência no ramo.  Contudo, o treinamento de pessoas é importante e a equipa também não deve apenas ser formada de sêniors.  E lembre-se sempre que lá porque uma pessoa faz programas à 20 anos não significa que saiba criar aplicações hoje e muito menos que saiba gerenciar a produção delas.

Além de tudo isto, o mais importante é que todos aceitem bons valores e rejeitem maus valores e que haja concenso sobre quais valores adotar. A Extreme Programing assenta básicamente sobre valores de onde são estrapoladas práticas e é um bom exemplo de porquê valores são mais importantes que experiência. Experiencia adquire-se. Se aprende e se ensina. Valores, ou se têm, ou não se têm. É demorado e custoso incutir valores em alguém. Isso fica além do aprendizado simples e requer uma educação completa, e portanto, cara. Contratar pessoas com os valores certos, é mais importante para o custo e sucesso do que contratar pessoas com experiência. A experiencia deles pode simplesmente enganar você.

Muito já foi falado sobre os bons valores que devem ser abraçados pela equipe, mas conhecer as tentações dos maus valores e como as evitar pode ser ainda mais útil. Em outras palavras, mesmo que a equipe não faça  bem, desde que não faça mal, já é um passo em frente.

Podemos enumerar sete falhas, sete anti-valores, os sete “pecados”  mais comuns dos membros da equipe de desenvolvimento:

Pressa

Decisões apressadas levam à degradação da qualidade do software. Isto é normalmente originado por um subjugação ao prazo irrealista do projeto que causa um stress e uma pressão sobre a equipe para entregar o software – de qualquer jeito- até ao prazo. O risco disto é imenso, pois qualquer pequeno erro feito agora causará prejuízos imensos depois. Claro, que, os causará ao cliente e não a software house, ou pior, a software house cobrará para resolver esses problemas.  Assim, é lógico que, do ponto de vista do fluxo de caixa, seja preferível entregar cedo e com muitos defeitos ao invés de tarde e sem defeitos. Os clientes são os que sofrem, mas devido à lábia de alguns vendedores, os clientes nem se dão conta que estão sendo enganados. O charlatanismo ainda é um problema no mundo da produção de software, como o foi de medicina ha não muito tempo atrás.

A pressa viola o comprometimento com um prazo.O prazo tem que ser realista. Isto significa que tem que ser alcançavel mesmo quando existem imprevistos e sem periodo extra de trabalho. A pressa acontece normalmente porque alguem mentiu em informações que formaram o prazo ou o prazo foi ajustado artificialmente por alguem sem comprometimento de toda a equipa. O prazo não é uma promessa, é um tempo máximo. O software será entregue até dia X. Isto significa que pode ser entregue antes. E é isso que deve acontecer. É por isso que o prazo não deve definir o custo.

Apatia

A ausência  de preocupação em  buscar soluções para problemas que aparecem durante o desenvolvimento, parecendo existir uma espécie de má vontade natural em solucionar os problemas, não procurando soluções que outros já utilizam ou mesmo soluções novas.  Neste caso, a tendência natural é eliminar o problema fazendo algum tipo de malabarismo – mais conhecido como gambiarra – que permite que o problema simplesmente “desapareça”. Claro que como nada é mágico, essa “solução” acaba trazendo mais problemas no futuro. Devido à apatia constante, a equipe não vê relação entres esses problemas e as gambiarras que fizeram antes, criando mais gambiarras para resolver os problemas que encontraram. Isto gera um novelo de ajustes mal pensados que não resolvem problemas, ao contrário, criam outros problemas, levando a um novelo ainda maior num ciclo viciado pela não-preocupação da equipe.

Visão-curta

A recusa em utilizar soluções já encontradas por outros e largamente utilizadas com sucesso. Estas soluções podem ser desde boas práticas de programação até  a utilização de técnicas de gerenciamento, como Scrum ou algo simples, como ter muitas equipes pequenas ao invés de ter uma equipe grande. A velha “não vamos fazer isso agora porque não precisamos” é o ex libris da visão-curta.

Preguiça

Escolher a “solução mais fácil” repetidamente e sem analisar as consequências da decisão.  Normalmente o “mais fácil” significa “o mais rápido” ao invés de “o que tem melhor razão custo-benefício”. Avaliar as soluções pelo tempo que demoram a ser implementadas é a prova de que a pessoa é preguiçosa, ela está tentando avaliar quanto tempo livre terá para ficar fazendo nada, ou invés de estar preocupada com a qualidade do software. A rapidez da implementação depende de muitos fatores e nomeadamente da experiência de quem vai implementar (um sênior provavelmente implementa em muito menos tempo que um júnior) e das ferramentas, bibliotecas e frameworks envolvidos. Se é algo que já está quase pronto da plataforma de aplicação é rápido, se é preciso criar, é lento. Um outro exemplo comum é escolher implementar uma funcionalidade no software ao invés de na plataforma de aplicação, sob a razão de que no software será mais rápido. Sempre que a palavra “rápido” é usada está em causa a preguiça de alguém. A análise e decisão entre funcionalidades não se dá pelo tempo de implementação de cada uma e sim pelo tempo de implementação de todas as funcionalidades do software. Se a funcionalidade X implementada da maneira “A” demora vinte vezes mais que a “B”, mas diminui o tempo de Y e Z por oito vezes, provavelmente será a escolhida.

Avareza

Esta tem várias formas. Resistir ao compatilhamento do código com a equipe ou até achar que o código é seu e não da empresa onde trabalha é um sinal claro. Mais sútil é achar que sabe como o software tem que ser feito à margem da documentação, do cliente, e pior, dos outros membros da equipe. Porém, mais sútil ainda é escrever e organizar o código da forma que acha certa sem pensar no que são as melhores práticas, ou a prática comum do resto da equipe. Pouca abstração é um sinal disto porque a pessoa só abstrai o que é necessário para ela e não pensa que uma abstração maior poderia ser útil para outras áreas do software. Falta de comunicação e decisões baseadas em crenças pessoais são um outro sinal da avareza.

Ignorância

É a falha em procurar entendimento. Mantém-se as pessoas estúpidas, comentendo erros a longo prazo que voltarão potencializados para atacar e pôr em risco o software. A ignorância  também se apresenta no nível gerencial e até vindo do cliente. Ao falharem em entender alguma coisa, o gerente ou o cliente não pedem explicações,  mas  decidem fazer as coisas de outra forma, levando a retrabalho e a um sobresforço da equipe. Isto é comum quando não se entende porque o programador passou dois dias implementando algo que não consta dos requisitos. Em vez de perguntar e tentar entender a razão técnica, o gerente automaticamente decide que a pessoa está enrolando. A Ignorância apresenta-se também pela falta de treinamento da equipe em tecnologias novas e até pela falta de abertura de que a equipe procure esse conhecimento. “Faltar um dia para assistir uma conferência ou convenção? Nem pensar!” “Ficar uma semana fazendo um curso de Java ? ‘Tá louco?”

Orgulho

O orgulho vem várias faces. Para a equipe é  a síndrome de “não-foi-inventado-aqui” em que a equipe quer reescrever tudo o que já existe, procurando uma perfeição que não pode ser encontrada no que já existe pronto mas foi feito por outros. A recusa em utilizar frameworks e bibliotecas de mercado simplesmente porque não foram feitas aqui. Claro que nem todas podem ser usadas e nem sempre existem coisas já prontas para o que precisamos, mas a recusa a procurar por elas é a marca do orgulho. Outra forma de orgulho, mais pessoal, é a pessoa se vangloriar de alguma experiência que teve para justificar a decisão que tomou sendo mais comum o resalte dos anos de “experiência”, o famoso “Eu trabalho com isto há 30 anos”. Embora seja muito interessante para a biografia do sujeito, isto é irrelevante ao problema já que ter trabalhado com Clipper à 20 anos não o prepara para utilizar Java hoje em dia. A tecnologia evolui todos os dias, assim como as boas práticas e os paradigmas, a experiência longínqua não serve de nada agora. Isto não significa que a pessoa não possa utilizar o que sabe, o que aprendeu, apenas que ela não pode usar isso como trunfo para impor a sua decisão.

Os sete pecados são um assunto interessante e se está querendo saber mais leia Anti-Patterns – Refactoring Software, Architectures and Projects in Crisis (ISBN 0-471-19713-0) em que este tópico foi baseado.  Recomendo.

Criar um software é um trabalho colaborativo tanto da equipe de desenvolvedores, como da gerência e, principalmente, do cliente. O cliente precisa saber o que pode dar errado num projeto de software e vigiar para que não aconteça. Não faz sentido que a gerencia de um projeto de software seja da software house apenas. É como colocar uma venda nos olhos do cliente. Se ele sabe vigiar problemas com todos os outros fornecedores porque não com o o fonecedor de software? Cuidado com os defeitos e a cobrança para resolver defeitos. O cliente entende muito melhor e  mostra-se muito mais flexível quanto mais por dentro ele tiver do andamento do projeto. Seja honesto com o cliente. Aplique o triângulo de projeto sem medo. Ele compreende isso, pois ele usa o mesmo triângulo quando negocia com os clientes dele, no ramo dele.

Repeite o cliente, respeite a equipe e tudo dará certo.

Esta nunca me pareceu forma de dividir ou distinguir as habilidades das pessoas. Aliás sempre achei o nome “programador” ofensivo para quem é mais que isso, embora reconheça que sim existem programadores. O ponto é que quem desenvolve software não é apenas um “programador” ele tem outras habilidades. Eu já fiz várias entrevistas e sempre procurava determinar o quantidade de aptidões e o nível dessas aptidões nas pessoas. Existem pessoas que simplesmente têm talento para testar e nenhum para desenvolver. E outros é ao contrário. Poucos têm as duas coisas em equilibrio. Portanto, não se pode esperar tudo de todos. Mas a pergunta que ficava sempre na minha cabeça era : “afinal o que estou procurando nesta pessoa”. E não estou falando de empenho e vontade de  aprender. Estou falando de vertentes, de perfis. Afinal quantos e quais perfis existem ?

A resposta é simples. Existem quatro : Especialistas, Generalistas, Generalistas com especialidades e fanfarrões.

“Programar” é uma coisas que o desenvolvedor faz , de entre as muitas possíveis. É uma especialidade. Quem apenas sabe programar e o faz bem e apenas faz isso, então é um Programador no verdadeiro sentido da palavra. É um especialista em programação. Um especialista em programação não apenas programa, ele programa seguindo diretivas, boas práticas, padrões e convenções de forma que outras pessoas também programadores saibam ler o codigo que escreveu e o saibam interpretar ( reconhecer as razões que levaram a pessoas a escrever o codigo daquela forma). Mas um software não se faz só de código. Se faz de levantamento de requisitos, analise, design, arquitetura, modelagem, teste, grafismo, ergonomia, etc… Cada uma dessas coisas em si mesma pode ser umas especialidade. Afinal todos ouvimos falar nos DBA e AD que comandam – apenas – banco de dados, de pessoas que ficam fazendo diagramas UML ou escrevendo casos de uso, os “testers” que são – em tese- pessoas especializadas em teste, etc…

No mundo do software tradicional é muito comum dividir o trabalho pelas especialidades e esperar que cada um faça sua parte para no fim juntar tudo. O problema é que se esquecem de que “juntar tudo” também é uma tarefa em que se pode ser especializado (designer) e é por isso que os projetos tradicionais falham.

Todos sabemos o que é um “Especialista de Dominio” (domain specialist). É uma pessoa especializada no dominio. Esta especialização é bem útil durante a construção de um software dirigido a um domínio especifico, e quanto mais complexo o domínio, mais necessárias são estas pessoas. Elas não necessariamente produzem software no sentido de por a mão na massa do código, mas ajudam a todos a entender o porquês e por que nãos das coisas que o software deve fazer.

Por outro lado, um generalista é uma pessoa que sabe fazer de tudo um pouco. Não se trata aqui de que o especialista faz com mais qualidade que o generalista. Não é esse o ponto. O ponto é que o generalista sabe fazer mais coisas que o especialista. O quão bem as sabe fazer advém da experiencia , esforço e talento de cada um. Um generalista não tem que saber tudo. Não é necessário desempenhar todos os papeis para ser um generalista mas mais do que dois ou três.

O iniciantes começar no mundo do software preocupados em saber programar, usar as bibliotecas etc… sem nunca dar atenção a coisas como modelagem ou levantamento de requisitos. Muitos passam sua vida sendo apenas programadores deixando com outros especialistas as outras atividades. Isto é comum em “fábricas de software”.

Como disse antes quem trabalha no modelo de fábrica com um bando de especialistas encadeados em uma linha de produção se esquece que alguém tem que conhecer todas as partes do processo, do produto e do resultado de forma a avaliar como a linha de produção se portou. Senão ficam todos a olhar uns para os outros peguntando a cada um como a parte dele deveria funcionar. Isto causa imenso ruido na informação relevante, perda de informação e até inclusão de erros.

No modelo ágil se pede que as equipes sejam multidisciplinares. Muitos interpretam isto como “muitos tipos diferentes de especialidades”, mas significa de fato “pessoas com várias aptidões” ou seja, generalistas. Um generalista pode fazer muito mais num período de tempo que vários especialistas.  A pessoa pode conduzir o ciclo inteiro. Levantar um requisito, implementá-lo, testá-lo reportar ao cliente e começar de novo. Implementar pode significa escrever java, html, javascript, usar a biblioteca A ou B, mexer com banco de dados, SQL, configurações, produzir documentos, uml, etc… Agora imagine dois, três , quatro , generalistas e compare com equipes de dez, quinze, vinte , cinquenta especialistas.

Quando imagino especilistas imagino o cara sentado numa mesa com aqueles oculos especias com muitas lentes procurando os detalhes. Eles são excelentes nos detalhes. Eles enxergam a “small picture”. Os generalistas enxergam a imagem maior (“big picture”). De longe, como uma águia que procura o problema e desce rapidamente na terra para matar o problema.

Uma equipe para ser produtiva tem que ter uma mistura saudável de especialistas e generalistas, sendo que é melhor ter generalistas com especialidades.

Mas cuidado, não se confunda “generalista” com fanfarrão, ou com o cara que diz que faz tudo mas não é bom em nada. Para ser um generalista legitimo, ha que fazer direito várias coisas. Os famosos bombeiros ( o cara que fica apagando fogo de um lado para o outro) não necessariamente é um generalista. Especialmente se ele que começa os incêndios.

Não ha nada de mal em ser um bom especialista, seja de domínio, de tecnologia , de modelagem , etc… nem ha nada de errado em ser um generalista. Contudo imagine que tem mais chances de sobreviver num ecosistema em constante mudança ? Por exemplo, à 40 anos atrás DBA era o cara. Os sistemas existiam em stores procedures. Hoje que o banco de dados é commodity e temos o NoSQL ( Not Only SQL) esta profissão – como especialidade única – coloca a pessoa em risco de não trabalhar mais. Não ha como negar que especialidade é sinônimo de limitação. Por outro lado, um generalista está limitado pela sua capacidade de saber os detalhes. Porque ele não sabe ou procura os detalhes pode fazer as coisas mais levianamente que um especialista faria.

Ser especialista ou generalista é inerente ao profissional , mas da mesma forma que uma pessoa apenas boa no serrote ou na glosa não pode se considerar um carpinteiro, da mesma forma uma pessoa que só sabe programar ou só sabe trabalhar com bando de dados, ou só sabe modelar, não se pode chamar de desenvolvedor. Ao entrar no mundo do trabalho voce pode entrar como especialista ou como generalista, é você que escolhe. É comum ver as pessoas entrarem como iniciantes e nem saberem sequer programar, quanto mais levantar requisitos e fazer testes, mas se nunca tentar a pessoa não sabe se é boa ou não nessas tarefas.  Por outro lado, ninguém é sênior sabendo apenas programar. Maior nivel de aptidão (skill) significa também mais aptidões.

É isto que diferencia os desenvolvedores. É isto que tem que procurar durante as entrevistas. É nisto que tem que pensar ao formar uma equipe. Você quer muitos especialistas, muitos generalistas, ou é melhor ter apenas alguns generalistas com especialidades ? Por outro lado, como membro de uma equipe, como você pode ser mais útil ?

A meu ver o mundo da especialização e das fábricas está mudando para o mundo generalista com especialidades e modelo de oficina. Em uma oficina de carpintaria qualquer um sabe serra e usar uma glosa. Senão, o produto sairia muito caro. Isto não significa que de vez em quanto uma peça especifica não tenha que ser feita fora, por alguém que percebe mais : um especialista… mas não é comum.

O conceito de herança, era, segundo os criadores do Java abusado pelo uso de herança múltipla. O que em C++ era visto como reaproveitamento de código, em Java é visto como a falha em entender o que é herança para começo de conversa. A más linguas dirão que por causa da necessidade de usar herança múltipla o java inventou a Interface e portanto permitindo-a e proibindo-a simultaneamente.

Pois são coisas distintas e embora a sintaxe possa ser enganadora, o conceito não o é.E por isso mesmo, por ser verdadeiro ao conceito e deixando de lado o facilitismo programático o Java mostrou que é possível construir grandes coisas, complexas coisas, completas coisas sem herança múltipla.

A herança se baseia no conceito de classificação. Um objeto pode apenas pertencem a uma classe ou a uma linhagem (herança) de classes, mas nunca a duas classes ou a duas linhagens. É como um ser humano ter duas mães. Impossível. Impossível não pela natureza, mas pela própria definição de mãe. É um problema lógico, não um problema biológico.

O conceito de herança é baseado na identidade da natureza do objeto. Ou seja, não na identidade do objeto em si, mas na entidade do grupo (classe) a que pertence. Se um objeto é um Animal não pode ser uma Planta. Se é Alto não pode ser Baixo. Se é quente, não é frio, etc… Aquilo que o objeto é dentro da sua classe é imutável e corresponde a uma forma de o distinguir dos outros na multidão.Um objeto pode ser um Gato e ser um Animal, e um Cão pode ser um Animal, mas um Cão nunca será um Gato. Inerentemente estamos abstraindo o conceito de Cão e Gato, para encontrar algo que eles têm em comum e chamar a isso o conceito de “Animal” que se destingue do conceito de Planta, por exemplo. Mas “Animal” não é algo que exista no mundo real. Não é algo que se pode tocar, é apenas um conceito.

Objetos concretos, instanciáveis e que vivem na memória são concretos, mas os conceitos que os definem e os distinguem são apenas fruto da nossa inteligencia, da nossa abstração e compreensão desses conceitos. Afinal, quem nunca pensou que pessoas física e pessoa jurídica são duas classes diferentes de “pessoa” ? (Podemos ver que não , necessariamente, são)

Aquilo que o objeto é só pode ser uma coisa. O Objeto não tem múltiplas identidades, nem é esquizofrênico. Aquilo que ele é , é completamente definido; mesmo que por um conceito abstrato. É por isso que o conceito tão poderoso, é também tão escasso. Uma vez que você escolher o que o objeto é, ele o será para sempre e mais do que isso, nunca será nenhuma outra coisa.

O conceito de Interface é muito diferente. Não importa o que é o objeto, mas como ele sabe se comportar ou do que ele é capaz. Em diferentes contextos, o mesmo objeto se comporta de formas diferentes e é capaz de coisas diferentes. Estas perspetivas diferentes do mesmo  objeto são aquilo que define uma forma de outros objetos trabalharem com aquele objeto, ou melhor, outras classes de objetos trabalharem com aquele objeto , naquele contexto. O que o objeto é, realmente não interessa, desde que ele se comporte como esperado.

Em Java chamamos isto de interface. Em sociologia isto é chamado de “Contrato Social”. Um acordo que ninguém fez, mas que todos cumprem. A Interface é um contrato com o resto da sociedade das classes de objetos. É um contrato, uma confirmação eterna de que aquelas capacidades serão possíveis. A Interface, ou “contrato” é usada para diferentes coisas conforme o contexto e a finalidade, já que ela não designa o que o objeto é, mas o que ele pode/sabe fazer. Em primeiro lugar temos a interfaces marcadoras. Interfaces como java.io.Serializable que designam que o Objeto pode ser usado em certo contexto, mas que ele não tem nenhuma ação particular (método). Ele simplesmente segue as regras esperadas por outros. Em seguida temos as interfaces funcionais. Ou seja, interfaces que na realidade definem assinaturas de funções através de métodos de um objeto. Por exemplo, Comparable. Depois temos os contratos de serviço; muito usados em WebServices, EJB, e outros mecanismos orientados a serviços. A interface define os métodos que podem servir um propósito sendo que o estado do objeto é irrelevante. Temos ainda as interfaces que definem métodos que auferem algumas responsabilidade explicita ao objeto, como Clonable, por exemplo. Por fim, temos as interfaces taxonômicas que criam classificações alternativas e paralelas às das classes como por exemplo, CharSequence e List, que ao mesmo tempo que se utilizam o conceito de contrato passam a ideia de “identidade”.

Em inglês a nomenclatura de interfaces é sempre um advérbio de modo (as interfaces acabam em “able” que a forma mais simples de criar advérbios de modo). As interfaces taxonômicas que se utilizam de nomes abstratos.  Em português é mais difícil criar estes nomes. Securable (that can be secured) é simples , embora, “Segurável” parece esquisito. Mas ambos significam “que pode ser/ter seguro”. É por estas e por outras que prefiro modelar em inglês, até porque não escrevemos se-faça-enquanto e sim if-do-while.

A interface de contrato é extremamente útil porque permite que um mesmo objeto interaja com outros em diferentes contexto e ambientes. Aumenta o polimorfismo e isso é sempre bom (“Programe para interfaces”). Já as interfaces taxonômicas, igualmente uteis em muitos aspetos já permitem definir hierarquias não tão rígidas quanto uma classe enquanto mesmo assim não proibem de criar linhagens mais fechadas. O exemplo mais claro disto é a API de coleções que é toda baseada em interfaces, sendo as classes abstratas que as implementam meros utilitários programáticos que não incluem nenhum sentido de identidade da natureza da classe. Esta é, aliás, uma forma muito útil de definir suas hierarquias. Comece com um interface, e explore o conceito. Quando você descobrir que as implementações sempre repetem alguns pormenores é hora de criar uma classe abstrata no meio para ajudar na limpeza do código. Quando verificar que afinal sempre precisará desses pormenores então você encontrou a sua classe principal da linhagem.

Claro que ainda ha quem não esteja satisfeito com o problema de não poder definir métodos em interfaces. Afinal o bytecode não proíbe isso, apenas o compilador.  Então, temos alternativas como os mixin do Scala e as definições default do Java 8(? ou será 7? já nem sei depois de tanto vai e volta da Oracle). O ponto é que a simplificação é muito poderosa e mesmo assim podemos fazer grandes coisas com ela. Mesmo sem os truques dos mixins, existem centenas de API java para fazer quase tudo o que imaginar. O que significa que com outras estrutruas talvez fosse mais fácil escrever, mas com certeza não seria tão fácil modelar.

O Java deu vários passos à frente depois de dar um passo atrás em relação ao C++. A famosa máxima “menos é mais” , se aplica aqui, com toda a sua classe.

Ora, Leader , em português Líder é alguém que tem o papel de guiar mas tem comando sobre outros. Enquanto que Lead (Condutor) é apenas o que tem papel de guiar e estar à frente. Estar à frente significa ser o porta-voz.

A cultura local absorveu o conceito de forma errada substituído aquilo que era intencionalmente apenas um Condutor para aquilo que se espera ser um Líder e expressões como Lead Architect viraram Líder de Arquitetura ou Arquiteto Líder e Lead Designer virou “Líder Técnico”. Note a dupla perda de significado já que Designer é o responsável pelo design, ou seja pelo conhecimento de como todas as partes se integram e trabalham juntas dentro do software. A palavra “Técnico” é extramente pobre para convir este significado. Quanto a mim não tem, sequer, nada que ver.

As empresas ,então, procuram lideres técnicos. Mas o que faz um lider técnico ? A resposta é simples :”lidera a equipe de técnicos” no sentido de “comanda” ou “é responsável por” ou ainda, em alguns casos , “responsável por domar a equipe de técnicos conforme os preceitos da empresa”. Ora, isto não tem nada que ver com software e o conceito de Lead Designer e sim com a arcaica hierarquia pseudo-militar que as empresas tanto gostam de usar. Tem mais que ver com o conceito de “Team leader”, que é outra coisa completamente diferente. Para começar “Team leader” não é um cargo, é um reconhecimento. Muitas vezes o erro vai mais longe e se confunde Arquiteto com “Líder Técnico” o que causa vários desastres quando o líder técnico não sabe de arquitetura ou quando o arquiteto não sabe de liderança.

Depois estas mesmas empresas não entendem porque seus projetos têm problemas e existem conflitos. É porque a hierarquia da empresa  não corresponde com as responsabilidades necessárias a fazer um software nem com as capacidades das pessoas em cada nível.

Acentuo que “líder” não é um cargo, é um direito, uma conquista. Uma conquista de respeito. As pessoas seguem a um líder não porque ele as ordena, mas porque elas confiam nele. O comando vem depois de que a pessoa já deu provas que as suas ideias, ações e valores sempre resultam em bons resultados para essa mesmas pessoas que confiam nele.

Parafraseando Platão, A força do Homem é medida por aquilo que ele faz com o Poder. Mas o carácter do Homem é medido por aquilo que ele faz sem Poder. Ou seja, líderes não se criam, eles nascem. E depois que eles provam o seu valor é lhes dado o poder de comando. Contudo, isto que é válido na vida militar ou politica, não é válido na vida técnica.  Lembre-se que nem os militares nem os políticos são técnicos - ou seja, não seguem nenhuma disciplina racional especifica. Militares seguem ordens e são bem treinados para executar qualquer tipo de ordens e Políticos simplesmente convencem pessoas pelos seus interesses. Não ha ciência por detrás destas atividades e por isso a importância de lideres que tenham a capacidade de agregar pessoas junto a eles : carisma.

Tudo bem que o carisma pode ser usado em qualquer área, inclusive em equipes de software. É especialmente útil quando a pessoa não conhece a parte técnica e se baseia na engenharia social para parecer e alcançar aquilo que não é e não tem. Ou seja, o carisma poder ser uma boa forma de enganar os tolos. Em uma equipe de técnicos o trabalho acaba se resumindo à prática da construção de algo que funciona. Ora, carisma não faz as coisas funcionarem, é o conhecimento técnico e a experiencia que tornam possível levar ideias à prática e tornar requisitos em software.

Mesmo assim, as empresas procuram pessoas carismáticas que possam ser líderes de equipe técnica, ignorando o seu conhecimento. Isto provoca um efeito comum de quem comanda a equipe não saber fazer ele mesmo o que comanda aos outros. É aqui que o paradigma de divide entre o que é o mundo corporativo, militar e politico daquilo que é o mundo tecnico e prático. Nos outros mundos as pessoas aceitam e até – de certa forma – esperam que seus superiores não saibam realizar o que pedem. O general pode ter ampla visão das consequências do seu pedido e o soldado nenhumas, da mesma forma que o general pode não ter qualquer noção do tipo de capacidade fisica e mental necessárias a levar a cabo a missão e o soldado vivê-las diariamente. Em software, o software é sempre criados pelos desenvolvedores que são técnicos que conhecem as consequências do que lhes é pedido e sabem como as realizar. Nem todos podem ser assim, mas ha muito que têm esta capacidade. Diferentemente dos soldados.

É por isto que irrita que uma equipe de software seja comparada a um exercito. Me irrita ainda mais do que se comparada a um chão de fábrica. Sempre existe o conceito de que as pessoas não sabem o que estão fazendo e apenas estão ali para seguir ordens. Se isso fosse verdade coisas como “parecer tecnico”s não existiram.

As empresas de hoje, ajudadas pela incompetência funcional dos RH em entender o mundo do software, procuram as pessoas erradas para os cargos errados. Aliás não sabem exatamente que cargos seriam necessários e os confundem com algum tipo de hierarquia militar. As empresas que não fazem isto ( ou não o fazem tão Às claras) têm mais competitividade ( vide Google que ao mesmo tempo que ha responsabilidade ha latitude). Todos se esquecem que criar software é uma atividade intelectual e cujo treino está em saber mais e pensar melhor, e não em saber pouco e pensar mais.

As equipes de software apenas precisam de um Guia. Um porta-voz que fale por elas e que faça a mediação com outros envolvidos. Alguém com mais experiencia que possa decidir impasses  técnicos e ajudar as pessoas a saberem mais e pensarem melhor. Não precisam de alguém que as comande. Precisam de um Condutor, alguem à cabeça das operações , um Lead , e não alguém que comanda cegamente , um Leader.

Tal como o problema do Junior e Sênior que foi completamente vilipendiado pelas empresas e RHs também os conceitos relativos ao papeis das pessoas em projetos de software o foram. Espero que com o tempo as pessoas cresçam mais conscientes dos seus papeis e exijam mais respeito pelas empresas contratantes e saibam escolher entre as empresas que dão valor real às qualidades realmente necessárias para trabalhar com software.

Espero que um dia exista uma expressão me português que signifique o mesmo que “Lead Designer” e não tenha conotação de hierarquia militar.

A palavra “Design” refere-se à moldagem de abstrações para alcançar um objetivo prático. Podem ser abstrações de textura e cor da roupa (Fashion Designer), as abstrações de formas de objetos (Car Designer) ou até de cabelos (Hair Designer) mas podem também ser as abstrações de construções mentais como aquelas usadas em Orientação a Objetos ou em código de programação. A palavra é de difícil tradução para o português já que não distinguimos desenho no sentido de “esboço” como “desenho animado” de desenho no sentido de plano ou projeção. O inglês e o espanhol são mais ricos com duas palavras diferentes (design/drawing e deseño/dibujo). É por isto que a expressão “design pattern” é em português “padrão de projeto“. Só que “projeto” pode significa outra coisa no mundo do software e se quisermos falar de “Project patterns” a tradução seria a mesma. Isto é um problema para os linguistas, mas nos deixa com um problema também: a falta de percepção da diferença entre fazer esboços e planejar.

Comumente ouvimos falar de arquitetos de software. Um cognome popularizado por Gates nos seus últimos momentos na microsoft e popularizado no mundo java pelo conceito de separação de papeis e com a famosa certificação. E por isso todos almejam ser arquitetos. E o que faz um arquiteto de software ?

Normalmente as pessoas ou dirão que um arquiteto faz diagramas (desenhos no sentido de esboços) ou que é responsável por decisões referentes a requisitos não-funcionais como segurança e performance. Alguns dirão ainda que são lideres ou responsáveis por equipes, mas isso não é verdade já que arquitetos normalmente atual como especialistas que finda sua contribuição ao projeto migram para outro. A visão tradicional do arquiteto como alguém que faz esboços em papel daquilo que será a realidade do software é uma imagem bem presente. Ouvimos, até, falar de “software blueprints” ou “plantas de software” no sentido de desenhos imensos que estabelecem o como as coisas serão. Esta comparação entre o arquiteto civil e o arquiteto de software é muito querida a aqueles que comparam fazer software com fazer pontes e edifícios.

No lingo do software falamos de andares e nodos que podemos comparar com edifícios , se realmente quisermos, mas essas abstrações estão muito longe daquilo que os programadores fazem no dia a dia: escrever software. São abstrações importantes para transmitir ideias como distribuição e organização de responsabilidades, mas muito pouco uteis no dia a dia. Se formos usar a comparar com edifícios temos que dizer que a planta é algo bem longe do trabalho do pedreiro que dia após dia ergue o edifício.

O Designer não está preocupado com esboços e bonecos em papel, está procurando uma harmonia entre as partes constituintes os materiais que tem à disposição e o objetivo ultimo do objeto que está desenhando. Está preocupado com um sentido estético que não apenas agradável à visão, mas principalmente à capacidade humana de entender o abstrato, as relações, e se maravilhar pela simplicidade de uma boa ideia. O objetivo do designer é que menos adições levem a mais efeitos. Em software isso significa menos código, menos classes, menos conceitos, levem aos mesmos resultados , ou a melhores resultados.

Da minha experiência projetos precisam de designers, pessoas que têm na cabeça como o software foi, é e será e como chegar lá. Arquitetos são apenas as pessoas de demonstram aos leigos como chegar lá, e programadores são quem chega lá. Sem designers na equipe os programadores não sabem que padrões seguir ou que código escrever, nem que objetivo estão tentando alcançar porque não ha um desenho, no sentido de ‘não ha um plano”. Por outro lado, muitos designers na mesma equipe pode ser problemático. Seria como dois pintores pintando o mesmo quadro ou dois escultores esculpindo a mesma pedra. Funciona se eles estiverem em sincronismo, mas se não, é um desastre.

Hoje se inventou o papel de Lider Tecnico e ha algumas coisas que esta pessoa deve alcançar, e muitas delas são as mesmas das que um Designer teria que alcançar, como derivar em termos tecnicos o significa dos requisitos e assegurar uma visão técnica clara do projeto , mas um Designer não tem atribuições de gerencia como ser responsável pelo o que a equipe é ou não capaz de fazer. Lider Tecnico é apenas uma expressão para “Responsável pelos resultados da equipe que sabe falar tecnikês com a equipe” e por isso é normalmente uma pessoa diferente do Gerente. No mundo ágil não ha tanto este sentido mais burucrático do termo, mas ainda fica a responsabilidade pelos resultados. Em termos ágeis o lider tecnico é responsável pelo débito tecnico da sua equipe. Ser um bom designer pode ajudar muito um lider tecnico, mas nem todo o lider tecnico precisa ser um designer. Pode, por exemplo, apenas ajudar a equipe a concretizar a visão do designer. Afinal estes são todos papeis, de que estamos falando, e não de pessoas. Portanto os papeis podem ser acumulados ou não.

Se um Arquiteto está para o modelo tradicional de fazer software e para as Fábricas de Software ( afinal só de pode produzir em massa o que está esquematizado em algum lugar) O Designer está para o modelo moderno de fazer software e para os Ateliês de Software. Talvez a analogia mais próxima seja a da fabricação de carros. Existe um fase de atelier onde o carro é desenhado, no sentido de conceptualizado e planejado. Isso é esquematizado em esboços e depois produzido em fábricas. A diferença é que em software só temos a parte da concepção porque o código que escrevemos para idealizar algo, já é o produto final e ‘produzir em massa” é apenas gravar mais CDs ou publicar para download. Algo que o mundo tradicional ainda não entendeu, já que continuam achando que fabricar software é um processo semelhante a uma linha de produção. Pobres coitados.

Bom, agora que sabe o que é um designer de software talvez queira reconsiderar se realmente você quer ser um arquiteto que fica escrevendo um monte de documentos e fazendo um monte de diagramas, ou se quer um de designer que sabe moldar o código à sua vontade. Afinal, a vantagem que o designer de software sobre os outros designers de outras áreas é que ele trabalha com material etéreo que ele mesmo pode criar, como, quando e quanto quiser. É muita liberdade criativa …

Ao contrário que podem lhe dizer, e podem lhe ensinar nas faculdades por ai, software não se faz em fábricas nem se planeja no papel. Se visiona e se molda, como um estilista que mentaliza o resultado que quer obter e molda o pano até que o resultado físico seja igual ao que ele mentalizou.

Bons desenhos.

Aproveitei o embalo dos cursos que fiz na Sun para programador certificado (1.4, bons tempos) e fiz um curso lá chamado OO226 que trata de Analise Orientada a Objecos. Foi muito bom porque permitiu que se forma-se em mim o conceito de como analisar com objetos é diferente de programar com objetos. Muitos dos objetos de negócio nem sempre chegam a ser objetos de código, alguns são apenas campos, propriedades ou alguns são até ações que acontecem. O curso não era baseado em nenhuma metodologia de mercado e isso foi excelente porque não me viciou a pensar em certo mecanismo como a muitos que são formados nisto e saem da faculdade com RUP na cabeça ou algo que lhe valha.

Um coisa ficou bem clara: eu estava em desavantagem nenhuma porque nem quem era da área tinha informação real e fidedigna de qual processo/metodologia seguir. Na época já se ouvia falar de XP, mas não muito se Scrum e já estavamos em 2004.

De lá para cá, tenho dedicado muito tempo a tentar aprender sobre processo de desenvolvimento. A meu ver as coisas se separam em : Levantamento de Requisitos e Desenvolvimento. Levantamento de Requisitos é essencial que seja feito e muito bem feito. Requisitos mal levantados causam verdadeiros desastres. Todos os autores advertem sobre isto. O Chaos Report mostra os numeros do que acontece e mesmo o Cone de Incerteza leva isto em consideração. Não ha desculpa para não fazer um levantamento cuidadoso.

Claro que levantamento de requisitos não é simples. Requer técnica. Por isso, um livro que acho excelente é Software Requirements Patterns em que nos é ensinado o valor do requisito bem levanto e nos é dito que uns requisitos levam a outros num padrão. Requirement Patterns são os Design Patterns do levantamento de requisitos.  Um outro é Software Requirements que nos leva a entender como se faz um levantamento de requisitos e que ferramentas existem para nos ajudar. Uma interessante é o processo Wideband Delphi que é o antepassado do Planning Poker ( e você que pensava que os agilistas tinham inventado isto… )

Tudo isto porque eu fiquei obcecado em entender porque em todos os lugares que trabalhei as pessoas teimavam em estimar horas e cobrar por hora. Um modelo que para mim nunca fez sentido até hoje. Consultando a vasta referencia bibliografica no mundo do desenvolvimento rapidamente entendi  que em lugar algum de fala ou ensina sobre este modelo. Então porque o usam ?

Os ensinamentos clássicos dos livros de muitos autores de todo o mundo é largamente conflitante com a forma como se implementa o processo de cobrança e estimativa. Mas por costume e tradição as pessoas continuam fazendo o que sempre fizeram mesmo depois de terem vários problemas com o modelo. Este não abandono irracional de costumes e tradições que não têm nada que ver com os ensinamentos clássicos nos leva a um tempo quase que de era medieval do desenvolvimento de software onde ha muito mito e pouca ciência.

Por exemplo, uma mecânica tradicional que não faz sentido algum para mim: O programador cobra por hora para desenvolver o software. Ele estima quantas horas serão necessárias e fecha um preço por hora. Se mais horas forem necessárias para completar o projeto, ou porque o escopo aumentou ou porque o prazo é fixo, é cobrado um extra. Mas se o software tem bugs e é necessário corrigi-los o programador cobra extra. Extrapole isto para empresas e entenda que as empresas sobram dos clientes a sua falta de qualidade. Porque não simplesmente cobrar mais caro para começo de conversa e não cobrar por bugs ?  A resposta a isso é, para muitos, o velho “o mercados não está bom” … hummm… algun dia esteve bom ? algum dia vai ficar bom ?  O fato é que a empresa deve ter uma imagem e um nome a zelar, mas isso é desnecessários quandos os clientes que utilizam os seus serviços são enganados todos os dias sem perceber. Se o cliente comprasse uma casa ou automóvel com defeito ele reclamaria o seu dinheiro de volta, mas com software tudo está bem, quando acaba bem ( com um software utilizável mesmo que com bugs).

Hoje em dia com o movimento ágil muitos licenciados tomam conhecimento de mecânicas e processos mais semelhantes ao que seria de esperar e mais perto dos ensinamentos clássicos. Por exemplo, quando o programador/empresa estimam o esforço em horas e tornam o prazo igual ao esforço eles estão cometendo dois erros. Primeiro, não estão separando as dimensões de escopo e tempo e segundo estão estabelecendo uma taxa de realização à priori.

Se temos 1000 horas de trabalho a realizar e nos comprometemos a realizá-las em 1000 horas, estamos estabelecendo uma taxa de 1h de esforço/ 1h de relógio. Ou seja, o programador em 1h de relógio não faz nada mais do que programar. Não bebe, não come, não lê email, não fala com ninguém, ou seja, é uma máquina. Mesmo com os 30% a mais que é tradicionalmente colocado a mais ( as pessoas nem sabem porquê) , nos daria uma taxa de 10/13 (= 0,76). Com o cone de incerteza iríamos para algo como 1/4 (0,25) que seria mais apropriado. O problema, aqui é que o prazo está relacionado ao custo e este ao preço. E o preço está relacionado à competividade. Entenda que no mercado brasileiro a competividade ainda acontece apenas no campo dos preços, ninguém olha a qualidade. E isto é sobretudo verdade em licitações. Onde ganha quem oferece fazer mais barato ( não quem oferece fazer melhor).

Em ágil esta taxa de realização é a Velocidade e é a razão entre o escopo realizado e o tempo para o realizar.  Mas mesmo aqui, com todas as ajudas, as pessoas ainda cometem erros.

Em agil o prazo é fixado por um numero fixo de sprint que equivale a dizer por uma data pré-acordada. E o esforço é estimado em pontos de estória. Como ágil é baseado em inspeção, então é facil verificar se vai caber ou não. E medidas devem ser tomadas. Contudo, perante os fatos as pessoas tomas as ações tradicionais : adicionar pessoas, cortar na qualidade, ou tentar negociar aumentar o prazo. Mas porque nunca tentam negociar os escopo ?

Basicamente porque de alguma forma se comprometeram a realizar todo o escopo. Mesmo que não por contrato mas para agradar ao cliente, ou não mostrar que as estimativas foram furadas. Ou seja, por simples medo.

É este medo que impede as empresas e as pessoas que são desenvolvedoras a alimentar mitos medievais e manter práticas tradicionais enquanto esquecem os clássicos. Hoje ha muita gente tentando pegar o trem do ágil, mas muitos com a mesma intenção que pegaram o do RUP e outros antes dele : porque é “in”, é da moda. É o mesmo que as empresas quererem ser verdes. É bem visto. Mas isso não significa que realmente cumpram com o que dizer e sejam o que publicitam. É o mercado, vale tudo. Inclusive dizer que se é o que não se é.

Depois de tudo, para mim, o jeito clássico é tem muitos prós. Alguns contras, como ser normalmente burucrático e é aí que o movimento modernos mudou o cenário mostrando que é possível aplicar o que é clássico mas sem a chata burocracia.

Talvez não saibamos, ou possamos saber o que é certo, pois tal como em ciência a verdade está por ai escondida. Contudo é fácil e simples saber o que não é certo e tal como em ciências, vamos excluindo as hipoteses erradas. Os modelos tradicionais são hipoteses erradas. São mitos com roupagens que mudam. O cara diz que fazia RUP e agora faz Scrum, mas no fim ele faz é waterfall mesmo. Mas ai de quem ouse dizer que ele faz waterfall.  O rei vai nu.

Você que ainda não enxergou , que tal passar pelo médico e ver se tem algo errados com o seu pensamento lógico. Afinal as células cinzentas não usam a lógica apenas para criar código. Se você já enxerga que o rei vai nu, o que faz no dia a dia para melhorar a situação ?