Em  posts anteriores falei de como se sabe se um processo é tradicional ou não e como se define o processo clássico.  Hoje falarei do processo ágil.

O processo ágil é muito semelhante ao processo clásico, mas se apoia em algumas permissas diferentes que injetam muita simplicidade no processo e os desburocratizam.

O primeiro passo é não confundir o “Processo ágil” com o “Movimento Ágil”. O movimento ágil é um conjunto de pessoas que partilham de um conjunto de conceitos e valores que querem ver ser usados na prática. O Manifesto Ágil é o simbolo deste movimento. Contudo o movimento ágil não foi inicado com o manifesto ágil. No final dos anos 90 algumas pessoas começaram a adotar metaforas diferentes para o processo de software. Até aqui a metáfora favorita é a da construção de uma casa, ou um avião. A metáfora passou então a ser a de uma linha de montagem, e não uma linha qualquer, uma linha japonesa de montagem que podemos identificar como a guerra ao desperdicio. Desperdicio de tempo, dinheiro, planejamento,  documentação, preocupações, etc.. Com isto nasceu o processo Lean. Mais tarde o processo Scrum.

O processo ágil é então o resultado de uma mudança de paradigma em que as pessoas queriam ver mais produto e menos “planejamento”.  Isto não significa que não ha planejamento, mas ha o minimo necessário. Esta diretiva de “o minimo necessário” é o amago do processo ágil. Ao contrario nem o processo clássico ou o tradiiconal parte de um conjunto de diretivas/axiomas e essa é a principal diferença para o processo ágil.

As 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 aproveite do inevitável. Ou seja, use a correte, não reme contra ela.

O primeiro destes inevitáveis é a mudança. A mudança é inevitável. O que significa que a mudança de escopo é inevitável. Devido a isto o processo ágil pega o processo clássico e define que todos os projeto serão plan-driven e que não existem projeto time-driven ou feature-drive. Ou, dito de outra forma, as mecanênicas de um plan-drive permitem controlar qualquer tipo de projeto, inclusive o time-drive e o feature-drive. Isto significa que num processo ágil sempre consideramos que o cliente quer algumas features em algum tempo. Isto força o cliente a priorizar muito bem o que quer e quando quer. Por isso as verificações que no processo clássico são feitas em certos gates, no processo ágil são feitos continuamente.

O processo ágil começa da mesma forma que o tradicional ou o clássico: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e propõe que o cliente aceite conversar com alguém da área de projetos.  A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.  Normalmente um analista e um domain expert.  Não envia apenas uma pessoa. Isso seria um erro. E não envia  mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro. Até seguimos o processo clássico. A diferença está em que todos os requisitos são gravados como historias. As historias têm uma forma padrão de serem escritas. Isto faz com que os requisitos sejam mais padronizados na sua forma o que permitirá depois indentificar requisitos iguais ou que estão contidos em outros requisitos. Historias não se comparam apenas  acasos de uso podendo conter informações não funcionais.  A estas historias pode ser atribuido um risco como no processo clássico e um tramanho. A diferença é que o tamanho não é atribuido pela equipe de levantamento ou de projeto.

Em um processo ágil a equipe de execução não é escolhida à posteriori. A equipe é envolvida desde um principio. Aqui ha uma diferença grande para o processo clássico e o tradicional.

O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa.Tudo é escrito em forma de historias para posterior análise.

Não é relevante neste ponto saber o que o cliente quer antes do quê e para quando. Esse aspeto será tratado depois.

De posse das historias, elas foram uma lista. Esta lista é reorganizada. Vários stakeholders podem ter dito a mesma coisa com palavras diferentes. Alguns detalharam mais, outros menos. O objetivo é ter uma lista de historias limpa de repetições e ambiguidadas. Questionamentos são enderaçados ao cliente.

Depois da lista limpa, ela é repassada com a equipe de execução. Neste ponto o erro ainda é grande e o cone de incerteza é levado em consideração. A equipe usa um processo interativo de pontuação do tamanho das historias. Este é um processo semelhante ao Wideban Delphi do processo clássico, mas mais simples e rápido. Este processo é conhecido como Planning Poker. Nesta fase cada pessoa da equipe de execução atribui uma pontuação minima e máxima à historia.  Esta margem, junto com o cone de inserteza irá nos dar um tamanho máximo e minimo para a lista de historias.  Estes pontos são chamados pontos de historia e obdecem a um conjunto de regras.

O processo de Planning Poker junto com a escala de pontos  provê uma forma mais imparcial de contabilizar o tamanho da lista de historias.

A grande diferença para o processo tradicional é que a estimativa é em tamanho não em tempo. Para o processo clássico a diferença é que se escolhe uma unidade nova para estimar o tamanho. Estamos aqui efetivamente dimencionando os requisitos e não a implementação. Esta mudança de paradigma é obvia para alguns e alienigena para outros, mas é necessária no processo ágil.

Sabemos então que a lista de historias do cliente tem um tamanho entre A e B, já com os devidos erros e desvios. A posta feita ao cliente é a seguinte : Você terá direito a gastar B pontos de historia. O nosso preço é P por ponto de historia o que significa que o preço do projeto é BxP.

Este mecanismo é extremamente transparente e muito semelhante à proposta tradicional de “Você tem direito a gastar H horas de projeto. O nosso preço é P por hora o que significa que o preço do projeto é H*P”. Isto diz ao cliente porque o preço é aquele e diz como o preço irá variar se ele decidir modificar alguma coisa. Como a mudança é inevitável é importante que o cliente saiba as regras do jogo. Isto , ao contrario do processo classico de gerenciamento de mudanças, deixa o cliente mais livre e mais à vontade.

Contudo para evitar desperdicios, a proposta não termina ai.  A proposta inclui dividir o projeto em pelo menos 3 partes. A prática de repartir o projeto em releases (publicações) já é padrão no processo clássico. Aqui estamos apenas forçando que o projeto seja dividido em 3 releases. Desta forma o cliente é obrigado a priorizar para o primeiro release o que realmente é o coração do sistema, o resto são upgrades ou extensões. As historias são então destribuidas pelos releases, não pelo tamanho, mas pela prioridade que o cliente lhe dá. A Prioridade, assim como o Risco e o Tamanho é uma propriedade das Historias. Veja que no modelo clássico já era assim, já falavamos em prioridades. A diferença é que não atribuimaos um numero para isso. Era sempre subjetivo. Em um processo ágil a prioridade é um numero que pode identificar em qualquer momento qual a historia que é para realizar primeiro.

O processo ágil funciona bem perto do cliente. Nem todos os clientes aguentam esta forma de trabalho, mas o modelo é o mais simples possivel. Uma lista de historias subdividida em 3 ou mais releases. Um conjunto máximo de pontos que têm um preço e a possibilidade de remover, adicionar ou reoganizar as historias a qualquer momento. Qualquer alterção que tenha que ser feita no software para corriger, reverter ou emendar é considerada uma historia e vai consumir pontos. Mas o cliente é livre de comprar mais pontos quando quiser.

O andamento do projeto será medido com comparando as balizas que sãos os releases. O release em si mesmo é dividido em sprints e as tarefas são realidas e aprovadas em um sprint. Isto permite saber claramente o que está pronto para entrega e o que não. A razão entre o numero de pontos realizados por sprint é a velocidade. Estrapolando a velocidade é possivel saber o quanto vai ficar de fora do sprint e já ir replanejando continuamente sem ter que esperar que todas as features estejam implementadas para poder testar ou redirecionar o projeto.

O processo ágil é, portanto, marcado pelos seguintes aspetos:

• Aceitar que a mudança do escopo é inevitável
• Aceiter que o custo advém do desperdício
• Não se  faz nada sem estimar antes e as estimativas não são viciadas. Para não viciar as estimativas processos que colocam a equipe de execução à cabeça como o Planning Poker, são usados.
• Não existe fases de projeto. Existem releases. Com datas e listas de features a serem realizadas.
• Não são feitas promessas. É estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a não esperar. Tudo é feito de comum acordo e sem mecanismos de submissão.
• O cliente é respeitado. É informado de todos os problemas e todos os riscos. O cliente tem controle absoluto sob o rumo do projeto. Ele decido o que realizar e quando. A priorização constante leva à diminuição de desperdicios e a alcançar os objetivos do cliente mais cedo.
• Conhecimento das capacidades e funções dos membros da equipe não são necessários porque a equipe, ela mesma, vai acabar provendo a estimativa original os dados de andamento através da velocidade. O que ha a fazer é simplesmente guiar o cliente e permitir que ele faça correções.
• Sempre que ha um problema qualquer pessoa pode levantá-lo e alertar.

O processo ágil ainda é estricto em certo aspetos como o processo clássico e demanda, como o clássico um certo grau de comprometimento e não sair mudando as regras sem as conhecer. Não é   um processo Stage-Gate com o clássico. Avaliações e mudanças de planos são feitas constantemente. Contudo, como no processo clássico, tudo isto e feito com base em numeros e dados e não em chutes ou promessas.

Dentro do processo ágil existem várias variantes cada um delas dando mais importância a um aspecto ou outro. Algumas como o XP (Extreme Programming) aliam as práticas do processo ágil com boas práticas de engenharia de software para tentar obter o melhor de dois mundos. Outras, como Lean, ainda focam no fluxo do processo e ainda tem um resticio do processo Stage-Gate ( afinal o modelo Lean é baseado em linhas de produção que são stage-gates por definição), outras adotam Stage-Gates conceptuais como Kanban ao mesmo tempo que permitem um controle ágil.

Ágil não representa o abandono dos valores clássicos, nem de suas práticas. Bem pelo contrário. O processo ágil é genéticamente artilhado para cumprir com uma série de leis e permissas resultado da analise classica e ainda sendo simples de usar. Muita gente acha que ágil é o abandono da documentação e do levantamento de requisitos. Nada mais longe da verdade. O ponto é que ágil se preocupa em não desperdiçar, e isso significa que não podemos documentar tudo a toda a hora nem ficar levantando requisitos o resto da vida. Ha um conceito de “bom o suficiente” ou “minimo suficiente” que basta para o trabalho em mãos.

Com o fim da triologia de processo, espero que fique mais claro para todos as diferenças, para que da proxima vez que ouvir falar em processo tradicional ou ágil saiba do que está falando.

Se você entendeu o que escrevi, você deve ter entendido que dizer que você usa um processo tradicional é na realidade uma forma de insulto profissional pois, a realidade não é nada bom usar um processo tradicional. É que as pessoas que usam tradicional e acreditam nele ouvem “tradicional” mas entendem “clássico” e é não exergar a diferença, que os torna tradicionalistas.

O processo clássico se destingue do processo tradicional principalmente pelo compromisso dos intervenientes com aquilo que estão tentando produzir e com a comunidade que produz a mesma coisa. Aprender com as lições dos outros é importante num oficio que tem apenas 50 anos. Ainda ha muito a ser descoberto em termos de saber qual a forma mais eficiente, eficaz e barata de criar um software. Repare que “barato” tem que ver como o custo e não com o preço.

O software tem que ser barato para quem o cria e livre de risco para quem o cria. Não necessáriamente o preço tem que ser pequeno ( Quanto custa o seu preço ?).

Veja que existem muitos pontos em comum entre o processo tradiciona e o clássico. Isto acontece porque quem usa o processo tradicional normalmente acha que está usando o processo clássico. Ou pelo menos essa é a sua intenção.

O processo clássico começa da mesma forma que o tradicional.: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e propõe que o cliente aceite conversar com alguém da área de projetos.  A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.  Normalmente um analista e um domain expert.  Não envia apenas uma pessoa. Isso seria um erro. E não envia  mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro de forma a que seja possivel estimar o risco do projeto e o tamanho do escopo.

Repare que no tradicional o risco é ignorado e o tamanho do escopo é irrelevanta pois será fixo.

O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa. O que ele quer agora, o que ele não quer agora e o que ele nunca irá querer. Quanto mais as palavras “sempre” e “nunca” são usadas em um requisito maior o risco do requisito.

O risco do requisito é importante para saber o quão estável é aquele requisito.

Daqui a equipe de projeto determina o prazo minimo,  máximo e expectável do projeto ( o mais provável). Determina também quais áreas/requisitos irão precisar de mais detalhamento e em que grau. Por exemplo, um requisito padrão como login, normalmente é estável e precisa de poucas entrevistas. Um requisito como integração com legado é um requisito complexo, de alto risco que precisa de mais entrevistas.

A equipe de projeto detremina também as capacidades que a equipe de execução terá que ter. A tencologia, a estrutrua, a infra-estrutura, o processo usado, a necessidade de comunicação, o nivel de qualidade, o tempo disponivel (baseado no time-to-market) , etc… são constrangimentos ao tipo de equipe necessária. 4 séniors são uma equipe pequena , facil de gerenciar, que produzem boa qualidade e baixo numero de erros, mas mais cara. Uma equipe de 8 juniors é mais barata, mas produz mais erros e é mais dificil de gerenciar face à falta de maturidade.

É vital que o levatamento direcione as perguntas. A conclusão mais importante de todas é saber se o projeto será time-driven, feature-driven ou plan-driven. Em um projeto time-driven existe um requisito temporal que limita o projeto. O chamado time-to-market. Se o cliente precisa do software para uma certa data especifica, como o natal, uma feira , etc.. e se a falha em ter o o software nessa data aborta o projeto. Os projetos tradicionais são todos time-driven, mesmo quando não existe de fato um time-to-market, mas um desejo do cliente em uma data alvo.

Feature -driven acontece quando o tempo não é relevante mais sim as funcionalidades. Aqui se estabelece que o software só está pronto quando tiver as features A, B e C e todos funcionarem sem problemas. Basicamente o que interessa é cumprir o escopo e não nenhum prazo em especifico.

Plan-driven acontece quando o cliente está interessado em determinar um sub-conjunto de features em um certo prazo. O projeto é dividido em releases e cada uma tem um objetivo util e comercial para o cliente. Basicamente o software é feito em forma de upgrades, mas com uma versão 1 que se pode utilizar em produção.

A somar a todas as estimativas ha a consideração do cone de incerteza. Numa fase preliminar como esta e com um cliente com quem nunca se trabalhou, a incerteza é bem grande e deve ser considerada.

Depois de pesar todos estes fatores, determinar o perfil da equipe de execução, o risco e tamanho dos requisitos e o plano de entrega a área de projetos produz um documento de visão acompanhados da proposta de prazo e custo.

O comercial então terá que avaliar a viabilidade deste projeto. Talves não seja rentável executar este projeto. Se não for, uma discussão com o cliente e o departamento de projetos pode levar a uma simplificação do projeto, dos requisitos, uma extenção dos prazos, etc.. de forma a tornar o projeto comercialmente viável.

Feito isto o departamento comercial  propõe ao cliente algo como “Podemos fazer um sistema de XPTO para si entre N e M meses por P reais”. Veja que um prazo máximo e expetável são apresentados e não uma data fixa.

Existem várias formas de escrever um contrato e não necessáriamente os dois limites do prazo vão aparecer explicitamente. Isto porque os clientes ficam confundidos quando veêm duas datas e assumem a menor. Um forma de por isto de uma forma mais digerivel é usar um contrato assim :

“Podemos fazer um sistema de XPTO para si em N meses por P reais. Com um prémio Z que decai até M meses.”

P é o custo do projeto com um lucro embutido. Z é um valor calculado tal que seja igual a P ou maior até um percentual do periodo entre N e M. Este percentual depende do risco e da confiança em N. Ou seja, quanto mais confiante menor este percentual.

Existem muitas formas. O ponto é considerar que a data expectável tem uma probabilidade menor que a data máxima. A empresa e o cliente são recompensados se a data expectável for correta, caso contrário a empresa é penalizada. Este conceito de penalizar a empresa e não o cliente é completamente desconhecido no processo tradicional.
Supondo que o cliente concordou com os termos temos agora um projeto com prazo, preço e escopo definido.

A mudança de escopo é feita segundo um processo de mudança de escopo normalmente recorrendo a um comité e todas as alterações para cima são cobradas pela empresa provedora. As alterações para baixo são colocadas em um “banco” para serem descontadas na seguinte mudança para cima. Isto só acontece porque todo o requisito tem um risco e um tamanho associados.

O próximo passo é detalhar o levantamento já iniciado e em paralelo começar a desenhar uma arquitetura e infra-estrutura.  Nesta fase (analise) o levantamento mais detalhado pode levar a alterações no escopo que podem levar a alterações no resto do projeto.  Todos os requisitos são detalhados e partidos em requisitos menores até que seja possivel transformar o requisito em tarefas de execução.

Durante esta fase de analise os requisitos são também analisados e sentitizados de forma a chegar num numero minimo de requisitos que atendem os requisitos iniciais.Com a arquitetura testada e aprovada e os requisitos detalhados um documento de especificação é produzido.

Em paralelo a equipe de execução é montada e os requisitos são partidos em tarefas, por ela. As tarefas são cotadas com um tamanho por um processo como o Wideband Delphi, por exemplo. A gerencia de projeto usa estes numeros para corrigir a sua estimativa inicial. Se menor, o plano original é mantido. Se maior, o cliente é acionado para modificar a prioridades dos requisitos de foram que se o tempo explodir, apenas as features menos relevantes ficarão de fora.

Passa-se então à execução. Durante a execução, novos requisitos são introduzidos, alterações são necessárias, o comité de mudança é acionado e os requisitos são constantemente analisados e sintetizados. Em paralelo os planos de teste começam a ser construidos.

Passa-se então à execução dos testes. A equipe de QA tem o documento de requisitos e os planos de teste para se guiar e não precisa inventar casos ou cenários que não estejam ali. Contudo, falhas, hiatos funcionais ou de implementação levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

A taxa de testes com sucesso versus a taxa de bugs são computadas pela gerencia e considerando o cone de incerteza obtemos uma nova estimativa de sucesso ou não do projeto. Novas priorizações são feitas pelo cliente.

Emquanto os testes estão sendo feitos,o cliente revisa os requisitos finais com a equipe de requisitos. Modificações, disparidades, hiatos levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

No fim deste processo, os testes terão garantido a qualidade tecnica do produto e a revisão dos requisitos terão garantido que o software faz o que o cliente quer. Finalmente temos a fase de homologação em que o cliente usa de fato o software. Quaisquer pedidos de modificação são comparados com os requisitos. Quando o pedido não base com o requisito ele não é realizado. Esta não é uma fase onde o cliente pode inventar coisas novas. Alterações que não sejam devido a bugs serão simplesmente deixadas para outro projeto no futuro.

O processo classico não começa com promessas irrealistas. As coisas são medidas e estimadas by the book ( seguindo os livros). O andar do projeto é medido em certo pontos o cliente faz os ajustes. A empresa nunca prometeu realizar tudo, mas sim cumprir o objetivo inicial ( time-driven, feature-driven ou plan-drive).  Ou seja, a empresa está comprometida em cumprir um plano e não em cumprir o desejo do cliente. O cliente é livre de mudar o plano, basta que pague a diferença.

A equipe é contratada depois que se sabe o que o sistema irá fazer. Os requisitos já estarão detalhados o suficiente para quando a equipe existir ela poder realizar a quebra em tarefas. O risco de escolher uma equipe junior uma sênior, ou um misto é imputado nas estimativas e não é deixado ao acaso. Nada é deixado ao acaso excepto o real andamento do projeto. O projeto é devidamente documentado para que nem o cliente nem a empresa tenham duvidas sobre o que é para fazer e o que não é. O resto é superfluo, não necessário, e relegado para um próximo projeto.

A equipe sabe exactamente o que tem que fazer e pode ser organizada da melhor forma para cumprir esses objetivos no minimo tempo possivel já que o objetivo interno da empresa é alcançar a data expectável (e não a data máxima, que está no contrato). Internamente o projeto é guiado de uma forma e com um objetivo, enquanto que externamente ele é guiado de outra forma com objetivos iguais mas tempos mais dialatados

O processo classico é, portanto, marcado pelos seguintes aspetos:

• Não se  faz nada sem estimar antes e as estimativas não são viciadas. Para não viciar as estimativas processos padrão explicitos na literatura são usado.
• As fazes do projeto são respeitadas e executadas à risca: Negociação, Levantamento, Analise, Desenvolvimento, Teste  e Homologação.
• Não são feitas promessas. É estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a não esperar. Tudo é feito de comum acordo e sem mecanismos de submissão.
• O cliente é respeitado. É informado de todos os problemas e todos os riscos. Todas as suas decisões são guardadas para futuro uso ou confrontamento. Se o cliente se enganar, ele se enganou. Se nós nos enganarmos, nós nos enganámos. Sem problemas.
• O escopo é controlado rigidamente e qualquer desvio afeta o resto do projeto. O plano é modificado e o contrato com ele.
• Conhecimento das capacidades e funções dos membros da equipe. Responsabilização pela equipe que montou.
• Sempre que ha um problema qualquer pessoa pode levantá-lo e alertar.

O processo clássico é bem estricto. É um processo Stage-Gate com a possibilidade de em cada gate haver uma avaliação do projeto e novos planos serem feitos e novas direções sendo tomadas. Contudo tudo isto e feito com base em numeros e dados e não em chutes ou promessas.

Este processo é extremamente rígido e para funcionar a contento as pessoas que o usam tem que ter uma certa experiencia. É por isso que é importante seguir o processo by the book. O que acontece na prática é que as pessoas leêm os livros mas logo interpretam ou subjugam o que o livro diz para o seu caso sem nunca ter dado uma chance ao processo canónico. É isto que gera a inventividade dos processos tradicionais. A intenção das pessoas é boa, mas sua arrogância é maior e se acham capazes de desafiar o que os autores levaram anos para descobrir e documentar. O exemplo clássico é desconsiderar o cone de incerteza, ou sequer saber o que ele é. Outro é não forçar um processo de mudança de escopo como deve ser com medo que o cliente se assuste quando a empresa disser que não irá fazer tal coisa e o cliente vá embora.  Os medos e inseguranças das empresas de software levam a que rapidamente alterem o que está escrito e começem o processo tradicional. É um mecanismo semelhante ao que acontece com a biblia. um escrito, mil interpretações.

Por outro lado, seguir as regras by the book não significa que as tenha que seguir mesmo quando estão erradas ou não correspondem com o seu caso. Contudo é preciso ser humilde e disciplinado para apenas mudar a regra quando so dados demonstram que ela não é eficaz no seu caso, e que, por algum motivo, o seu universo amostral é estatisticamente  diferente daquele usado pelo autor do livro.

O processo clássico deixa margem de manobra para alterações, só que ele exige provas de a mudança é necessária. Como a maioria dos gerentes faz um pessimo trabalho coletando dados do projeto nunca ha como provar nada e é aí que entra o chute, a artimanha e a politica. E mais uma vez a porta está aberta para o processo tradicional.

Sendo um processo rigido e dificil de seguir, embora muito simples de entender, o processo classico fácilmente se trasnforma no processo tradicional porque os intervenientes não têm a indole moral ou a retidão necessária para executar o processo como deve ser.  Contudo, se você perguntar, muitos irão dizer que estão usando a tecnica A ou B do autor X ou Y, mas se olhar de perto não estão. Simplesmente porque subverterem o que a tecnica significa e deturparam o seu significado

Se seguir o processo como deve ser, verá que ele é muito lento e burucrático. A burocracia advém do fato de constantemente ter que saber se o requisito A ou B está ou não no escopo e algumas vezes isso é subjetivo. Isto levou algumas pessoas a considerar que se dá muita importancia ao processo e pouca ao interesse do cliente ou da execução do software. Ou seja, o cliente é honorado pelo seu próprio desconhecimento do software que ele quer. mas se o cliente soubesse o que ele quer, ele mesmo teria feito o software sem contratar a empresa.

Daqui nasceram tentativas de melhorar o processo classico deixando o seu core de boas práticas, medições, auferições, mudança de planos mas modificando as regras de forma a que o processo fosse mais simples, menos burucrático, mais ágil.

Da próxima falarei do processo ágil. Até lá.

O processo tradicional normalmente começa com transformas prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e faz uma oferta direta de negócio se oferecendo para fazer o software. Por meio de licitação ou por conversação direta o departamento comercial só precisa estabelecer dois parâmetros de forma a convencer. O prazo e o preço. O departamento comercial, sem nenhuma noção do que o software será, como será, qual a equipe, qual a tecnologia, qual a complexidade, etc… simplesmente prometa ao cliente algo como “Podemos fazer um sistema de XPTO para si em N meses por P reais”. Normalmente estas variáveis são tunadas para agradar ao cliente. Por exemplo, se o cliente diz que quer o software para o natal e falta 3 meses para o natal, o prazo será  – você adivinhou – 3 meses. Independentemente se é possível ou não. O departamento comercial é sempre otimista porque depois de fechar o contrato não é da sua responsabilidade que ele se cumpra. Se algo der para o torto, o problema é do departamento de projetos e desenvolvimento. Nunca do comercial. O comercial também gosta de jogar com o  dinheiro. Se a empresa cliente é grande, inchamos o preço – a chamada gordura – ( que é diferente do conceito de lucro)  , se o cliente é modesto o preço é mais baixo. Mais uma vez o custo do projeto é irrelevante. Nem sequer se toma em consideração quantas pessoas estarão na equipe, por quanto tempo e quanto cada uma ganhará.

Algumas empresas tentam fugir deste modelo. Elas acham que se tiverem uma estimativa isso torna as coisas mais cientificas. Assim, o departamento comercial fala com o departamento de projetos. Normalmente um dos gerentes de projetos , e pede para que ele faça a estimativa. Mas já lhe fala que o prazo é N meses e o custo é C. Perante isto o gerente simplesmente criar um grant chart no projet que mostra como as pseudo-fases do projeto encaixam nesses meses. Normalmente as fases são : Levantamento, Analise ,  Desenvolvimento, Teste , Homologação. O gerente então adoça o caldo prometendo que no fim de cada faze um conjunto de artefactos será entregue ao cliente em troca de pagamento. Isto basicamente significa que – sem nenhuma noção se vai dar certo ou não  – o gerente compromete uma equipe que ainda não existe em entregar artefatos ( documentos,  diagramas, codigo, entregáveis de qualquer especie) que ele desconhece num prazo que ele não sabe se é suficiente. A desculpa é : depois arranjamos um cara que possa fazer isso no tempo que nós queremos. E se ele não for capaz, pressionamos.

O departamento comercial fica maravilhado com isto porque suas estimativas de preço e prazo estavam certas (uau!). Afinal o gerente não falou nada que estamos enganados, nem que prometemos mundos e fundos. Aliás ele ainda prometeu mais coisas e se ele fez isso é porque está confiante com o preço e prazo que inventamos. Confiante sim. Certo não.

Sendo assim o departamento comercial fica ousado e jura de pés juntos que o prazo e o preço serão cumpridos e por isso propõe o desafio de um prémio. Se o software for entregue na data prevista ou antes, o prêmio será X. Com um decaimento progressivo se entregue depois. É obvio que esta estrutura de pensamento em que ninguém se dá ao trabalho de saber o que afinal irá ser feito e como, está voltada ao fracasso.

Sabendo disto as chamadas fábricas de software apelam para o que chamam de “Definição de escopo”. Afinal isso é a única variável no processo já que o prazo e o custo são chutes do comercial e não baseados no custo e esforço. “Sistema de XPTO” não é suficiente para estas empresas. Eles querem saber, o que compõe um sistema de XPTO. O cliente responde que é o conjunto do modulo A com o B e o C. A empresa pergunta o que é o A , o B e o C. O ciente responde que dará mais detalhes durante a fase de levantamento.Isto é um  artificio do cliente. Na cabeça do cliente está se passando um filme diferente. Na cabeça dele a empresa que constroi o software é de um de dois tipos. Ou é uma empresa que contrata adivinhos e portanto sabe o que ele quer, ou tem gente experiente trabalhando nela e portanto essas pessoas sabem o que o cliente quer. Ter que responder o que elas já sabem é inutil e aliás demonstra que a empesa não é tão boa como diz. A empresa também acha que perguntar de mais é sinal de fraqueza e que pode levá-lo a perder a paciência e a cancelar o projeto. Então, “vamos fazer a estimativa com o que sabemos e por alguma margem de erro em cima” – diz alguém no departamento comercial , de projetos ou até mesmo da diretoria quando algum gerente mais preocupado está tentando avisar que o barco está afundando antes de ir para o mar.

Assim se faz. uma micro-levantamento que foi possivel executar com 5 ou 6 bullet points é apresentado em um power -point ao cliente, com o gráfico do project o preço e o custo que o comercial havia decidido.

Se a sorte quiser, o cliente aceitará a proposta. Entenda que tudo está nas mãos da sorte, não da capacidade ou da competência dos envolvidos, já que ninguém sequer ousou olhar para o software que irão produzir. Aqui começa o problema do processo tradicional. Promete-se tudo de olho no dinheiro e num conceito chamado “por o pé na porta” que significa que tudo é menos importante que tornar um prospect em um cliente e isso deve ser conseguido custe o que custar. Não importa se dentro de N meses quando o software explodir o prazo e o orçamento a imagem da empresa vai para o buraco. Porque nesse ponto o departamento comercial irá chantagear o departamento de projetos para fazer algum milagre para por as coisas nos eixos. Normalmente estamos falando de horas extra. Afinal é a única coisas que estas sabem que existe num projeto: tempo.

Veja que isto poderia ser um projeto de qualquer tipo de área. A estas pessoas tanto faz se é um software ou uma horticultura que estão construindo. Porque na cabeça delas basta arranjar um profissional que saiba fazer o que eles prometeram. E a arrogância nãos lhes permite enxergar que o que prometeram era completamente irrealista.

O processo tradicional começa com promessas irrealistas, mas o descalabro não acaba aqui. O próximo passo é montar a equipe.

Aqui começar contas interessantes. O gerente do projeto chuta que com R recursos ( não pessoas, recursos) sendo 98% juniors 1% plenos e 1% séniors dará para realizar o projeto no prazo e no custo. em outras palavras : contratamentos um bando de mão de obra barata e alguns sêniors para serem o culpados de tudo e alguns plenos para realmente fazerem alguma coisa funcionar. Isto porque um sênior que é sênior não vai tolerar certas coisas e acabará saindo do projeto quando poder. O pleno foi instigado pelo gerente que tem potencial para ser sênior e se ele o demonstrar será aumentado. Veja, um pleno é um cara que tem capacidade tecnica quase como um sênior para ainda pensa como um junior. Por isso é facilmente seduzido pelas artimanhas da gerencia.  Lembrar que no processo tradicional todas as promessas são irrealistas. Inclusive as que dizem respeito aos “recursos”. Tudo não passa de um tecnica de manipulação. A velha cenoura que você nunca comerá. Isto faz dos “recursos” burros.

Obviamente com uma equipe meia boca o projeto só tem um fim possivel : desastre. A fase de levantamento é engolida pela fase de negociação ( que todo o mundo no processo tradicional esquece) , a fase de analise é regida por um cronograma em vez de um risco do desconhecido e chegamos no desenvolvimento. AH! afinal o que interessa é programar o software. Esta atividade também é regida pelo cronograma em vez do estado de conclusão das tarefas e passamos aos testes. Aqui uma equipe chamada de QA (Quality Assurance – Assertividade de Qualidade)  é chamada para verificar que o software funciona. Aqui as coisas mais engraçadas acontecem. Por exemplo, a equipe de QA não sabe como o sistema deveria funcionar e testa no feeling. Não ha documentação que diga o que o sistema tinha que fazer ou como reagir em certos casos. Todas as mensagens em tela são considerados erros e impedivos para continuar testando embora a mensagem apenas informa que o usuário fez merda ao imputar certo dado … etc… Enfim, o QA sempre é uma piada. O que deixa os desenvolvedores putos da vida porque do ponto de vista deles, eles é que sabem como o sistema funciona, mas a gerencia só observa a palavra dos testers. E claro, além disso tudo ha a correção de bugs.

Afinal uma equipe medíocre, cujo objetivo nisto tudo é apenas o dinheiro no fim do mês e uma promessa de promoção, mas que sofre para caramba e trabalha 3 vezes mais que todo o resto da empresa sofre muita pressão e por consequência, se engana muito. Dai os bugs. É certo responsabilizar o júnior pela sua falta de competência ? Não. É certo culpar o Sênior por não ter treinado o junior ? Não. Primeiro porque ha juniors que se acham os donos do pedaço e  segundo porque ninguem paga ao sênior para treinar ninguem. Treinar é coisa de Coach, e isso é outra função e outro salário.

Mas assim é tudo uma zona. Como será possível uma empresa trabalhando assim chegar a algum resultado ? Não é. Só que todos se enganam mutuamente de uma forma tão bem orquestrada que tudo continua na mesma. O rei vai nu. Todo o mundo sabe, mas ninguém tem coragem para fazer nada. Isto significa que as pessoas acabam vivendo descontentes e acabam abandonando a empresa por outra, na esperança que a próxima será diferente. Não nunca é.

Porque você acha que em software todo o mundo é PJ ? Porque a rotatividade é enorme, e a empresa sabe disso. Logo ela diminui os custos de rotatividade ( contratação/ despedimento) usando o mecanismo de PJ. O que isto diz sobre as empresas ? Elas são ruins e sabem disso.  Uma empresa que acha que vai manter seus funcionários (nao “recursos”) aposta neles. Treina. Cumpre o que promete. Ouve. Muda. E com isso mantém o nivel de descontentamento baixo e a moral alta.  Como disse o fundador da Honda :”As pessoas não vêm para o trabalho para trabalhar, elas vêm para se satisfazerem”. Isto é especialmente verdade em trabalhos intelectuais como é a construção de um software. É bem diferente do trabalhador que trabalha para comer.

O processo tradicional é, portanto, marcado pelos seguintes aspetos:

• Falta e estimativas com base em dados relativos ao sistema que será realizado
• Incorreto conhecimento sobre as fases do projeto de software. Ignorância de processos, regras, resultados, estudos , etc … publicados em livros ou outros meios da comunidade de software (os gerentes leêm revistas de negócios, não de software)
• Promessas irrealistas a todos. Sejam clientes, funcionários, chefes ou subordinados
• Falta de compromisso com as necessidades do cliente.  Não importa o que ele quer. Importa quanto queremos receber dele e quando.
• Conhecimento que o escopo irá aumentar, mas insistência teimosa em adotar um modelo de escopo fixo.
• Falta de conhecimento de como funciona uma equipe de software e achar que qualquer bando de pessoas é uma equipe
• Falta de controle ao longo do processo para saber se realmente chegaremos na meta e preferencia por enganar todo o mundo a pensar que vai dar certo. Parecem desconhecer o ditado que “se pode enganar a todos a algum tempo, e a alguns todo o tempo, mas não a todos todo o tempo”. Os gerentes são mestres a enganar poucos todo o tempo porque apenas se reportam a 1 ou 2 pessoas acima deles e quando chega a hora da verdade a culpa é da equipe que era ruim. Mas lembrar que a qualidade da equipe nunca foi medida, nunca foi um fator.
• Falta de respeito pelos profissionais de desenvolvimento que são tratados como gado e não como pessoas inteligentes com capacidades intelectuais especificas como abstração espacial e matemática .
• Total descaso se alguém tentar provar que o rei vai nu. Isso é já sabido e incômodo de ser comentado.

Com certeza você já participou de um algum projeto em alguma empresa que trabalha assim. Aliás , quando é que você trabalhou em uma empresa que não trabalha assim. No Brasil este modelo é tão comum que é um vírus. O único antidoto seriam empresas novas, adotando outros processos que pudessem levam estas à extinção.  O problema é que: 1) sempre existirão desenvolvedores de péssima qualidade posando como sêniors, sempre existirão plenos mercenários que só estão ali pelo dinheiro e juniores crédulos e ingênuos. Isto que a comunidade de desenvolvedores não tem uma sólida e firme base moral  e ética de valores que lhes permita distinguir o certo do errado, o abuso da necessidade; 2) as empresas não querem treinar ninguém. Querem mão de obra que faça o que eles pedem, nas condições que eles pedem, por muito absurdas e imbecis que sejam; 3) clientes que não enxergam que estão sendo enganados.

Em processo tradicional a empresa acha que está tirando vantagem tanto do cliente como dos fornecedores ( desenvolvedores). Mas na realidade, os desenvolvedores juniros estão de passagem, fazendo curriculum para a próxima entrevistas. Os sêniors estão de saco cheio de tanta imbecilidade e falta de profissionalismo de todos os envolvidos que fazem orelhas moucas e os plenos ainda se enganam a si mesmos com um ideal e uma promoção. No dia que cai a fixa, eles vazam. O cliente por outro lado está tirando vantajem da empresa pagando muito menos do que deveria como conseguiu colocar uma corda no pescoço da empresa e é só apertar um pouquinho que a empresa faz qualquer coisa, de graça. Quem está parasitando quem neste modelo ? É na realidade uma simbiose de parasitas num ciclo de vida complexo em que todos acham que ganham, mas todos realmente perdem.

Agora imagine quanto perder o usuário do software que sai de um processo destes. E se num hospital o paciente é a prioridade, em software é o usuário.

Da próxima falarei do processo clássico. Até lá.

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.