O dilema do Scrum Master

 O DILEMA DO SCRUMMASTER

http://blog.adaptworks.com.br/en/2012/01/o-dilema-do-scrummaster/ 

·         Alexandre Magno         

·       Não são poucas as empresas e times de desenvolvimento que vem questionando o papel do ScrumMaster. Precisamos realmente de um ScrumMaster? O que faz um ScrumMaster se o time já sabe auto-organizar? E se não há impedimentos, o que ele deve fazer? E se não uso mais Scrum, o que farei com o ScrumMaster? Neste post pretendo discutir esses e outros pontos para tentar desmistificar o trabalho do ScrumMaster.

Por que preciso de um ScrumMaster?

Se você revisitar o paper que “oficialmente” deu origem ao Scrum (Scrum Development Process, Ken Schwaber, 1995) e procurar por alguma referência ao papel de ScrumMaster não encontrará absolutamente nada! Isso porque quando da “criação” do Scrum este papel simplesmente não existia. Mas então por que ele foi criado? Essencialmente, porque Scrum é difícil de ser colocado em prática, a resisência é muito grande, e foi percebido que se não houvesse alguém realmente comprometido e dedicado a fazer isso acontencer, a mudança não aconteceria.

 

Quais as principais dificuldades para colocar Scrum na prática?

Segundo a edição mais recente da pesquisa “State of Agile Survey”, organizada pela Version One, 58% das empresas que disseram usar Agile mencionaram Scrum como o método que utiliza, e mais 17% citaram que usam Scrum e Extreme Programming (XP). Nesta mesma pesquisa, quando perguntados sobre as principais barreiras para fazer Agile funcionar, responderam:

·         [ 51% ] Habilidade para mudar a cultura organizacional

·         [ 40% ] Resistência geral a mudança

·         [ 40% ] Disponibilidades das pessoas com as habilidades necessárias

·         [ 34% ] Suporte da Gestão

·         [ 31% ] Complexidade ou tamanho do projeto

·         [ 29% ] Colaboração do Cliente

·         [ 21% ] Confiança na habilidade para escalar Agile

·         [ 19% ] Tempo percebido para transição

·         [ 13% ] Restrições de orçamento

·         [ 12% ] Nenhum

·         [ 06% ] Outros

Bom, se sua empresa está decidida a aplicar Scrum a ponto de ter alguém com um papel chamado “ScrumMaster”, os impedimentos acima são os principais a serem combatidos por este profissional. Mas aí eu pergunto: quantos ScrumMasters você conhece que estão se envolvendo nos impedimentos organizacionais? quantos estão influenciando a Gestão para conseguir mais apoio? Quantos estão trabalhando com as pessoas para reduzir a resistência a mudanças, trazendo o cliente para dentro do projeto, ajudando áreas resistentes a entender e se aproximar de Agile…quantos?

Infelizmente eu tenho visto pouquíssimos, o que portanto me faz acreditar que grande parte dos questionamentos em volta deste papel seja pelo fato de poucos ScrumMasters estarem conseguindo fazer bem o seu trabalho. Portanto, a culpa é do ScrumMaster, certo? Não necessariamente. Grande parte do problema tem sido o fato  das empresas não empoderarem este papel de forma adequada. Não estão dando a ele a autonomia necessária para se envolver em questões organizacionais que estão impactando aquele projeto.

O que tem faltado aos ScrumMasters?

Segundo Thiago Santos, que atua em papel equivalente ao de ScrumMaster na R7.com, “Faltam mais habilidades humanas, relacionadas a técnicas de facilitação, coaching e motivação de pessoas.”. Além disso, pelos pontos citados no “State of Agile” podemos perceber claramente que falta aos ScrumMasters investir no estudo de gestão e liderança, e ainda no conhecimento organizacional. Se grande parte dos reais impedimentos estão fora do ambiente de projeto e muitas vezes até fora de TI, um ScrumMaster que não conseguir influenciar outras áreas da organização se tornará fraco.

 

Mas se a empresa (ou departamento/área) não deu o nível de empoderação necessária ao ScrumMaster, é dever dele influenciá-la para conseguir isto. “Os primeiros meses foram terríveis, para praticamente todos os impedimentos que apareciam eu tinha que dar a resposta ‘Não tenho como resolver, vou ter que escalar.’. Passei então a investigar porque era tão difícil para a Gestão me dar autonomia, e comecei a ver que não era chatisse ou necessidade de mostrar poder. Trabalhei então nos pontos que descobri tentando mostrar ao PMO como poderiam ter a mesma ‘segurança’ ao me dar um certo nível de autonomia em alguns pontos.”. diz Charles Bennini, brasileiro que trabalha como ScrumMaster no Coutts Bank em Londres.

 

ScrumMasters precisam ainda entender que em sistemas complexos a gestão é diferente do que estamos acostumados a ler nas cartilhas de “boa gestão”. Em sistemas complexos o conceito de auto-organização é natural, e portanto a gestão tem que ser focada no sistema e não no trabalho que as pessoas fazem ou deixam de fazer. Recentemente fiz o seguinte comentário no blog da Lambda3 em uma discussão relacionada à figura do gerente:

Basicamente minha mensagem é: novos gerentes devem esquecer a idéia de gerenciar pessoas…e devem aprender a gerenciar sistemas, “apenas” isso. Uma mudança difícil, mas com impactos radicais. Restrições são necessárias em sistemas complexos – se não estes se tornam caóticos – e é aí onde entra a figura dos “novos” gerentes.

[…]

No meu ponto, o gerente A gerencia X que é o sistema onde B, C, D, E trabalham o sistema onde as pessoas trabalham, e não o trabalho das pessoas.  Mas para garantir que este sistema não caia na falácia da linearidade…e nem no caos; ele precisa trabalhar com as restrições do ambiente, e para isso precisa trabalhar – dentre outras coisas – com os fatores humanos (ufa…rs).

 

É um trabalho full-time?

É comum os livros de Scrum afirmarem que um ScrumMaster deve ser um trabalho em tempo integral. Mas isso, na minha opinião, só faz sentido se ele possuir (ou estiver em busca de) empoderação suficiente para atuar em problemas que envolvam a estrutura da empresa, ou seja, quando ele realmente assumir a figura de um agente de mudança, que na verdade é o que esperamos dele. Mas caso isso não aconteça acho difícil conseguir uma justificativa para mantê-lo em tempo integral, aí o natural vai ser atribuir a ele novas responsabilidades e, comumente, dar a ele um outro título. “Apesar de ser um trabalho em tempo integral, como o título ScrumMaster não representava bem o papel, este passou a ser chamado de ‘Consultor de Projetos’.” diz Thiago Santos da R7.com.

Além disso há ainda a situação de empresas (ou times) pequenas, que possuem uma natural auto-organização e pouca interrupção da cultura organizacional. É bastante comum nestes casos haver o compartilhamento do papel de ScrumMaster com outras funções ou papéis.

O que um ScrumMaster deve estudar

É quase um consenso que o que mais tem faltado aos ScrumMasters tem sido habilidades de gestão e liderança, “ScrumMasters precisam de habilidades menos técnicas e mais interpessoais” afirma Milene Fiorio, Especialista em Agile na Petrobras, que cita que na sua área ScrumMasters são responsáveis por auxiliar os desenvolvedores e resolver os impedimentos, e comumente fazem parte do próprio time de desenvolvimento.

“Logo após servir e dar coaching aos times [de desenvolvimento], os [Certified] ScrumMasters devem considerar servir e dar coaching aos gerentes e líderes da organização” escreveu Jurgen Appelo, autor do livro Management 3.0, no post “What Comes After Certified Scrum Master?”.

Para finalizar, minha recomendação de estudo para ScrumMasters está concetrada em 03 pontos:

· Complexidade Organizacional: Teoria da Complexidade, CAS – Complex Adaptive Systems, System Thinking, o impacto da complexidade nas organizações, organizational design, …

· Gestão e liderança em Sistemas Complexos: Management 3.0 (Leia Você sabe o que é Gestão 3.0?), Beyond Budgeting, Radical Leadership,  …

· Relacionamento de Agile com: Governança de TI, Operações, Área de Negócios, e outras áreas e processos da organização.

PMBOK® do PMI® fracassou. Scrum também vai.

 

O PMBOK® do PMI® fracassou com desenvolvimento de softwares e o Scrum também vai fracassar. Entenda os motivos.

https://www.linkedin.com/pulse/o-pmbok-do-pmi-fracassou-com-desenvolvimento-de-e-vai-batista-santos/

Published on January 28, 2019

João Batista Santos

Chega a ser engraçado em 2019 um cara que é PMP® há 10 anos e trabalha com times ágeis utilizando Scrum há 9 anos, escrever um artigo com este título. Mas mesmo que ninguém admita, fato é que PMBOK®, mesmo com seus PMPs, PMOs, softwares de gestão maravilhosos e toda a governança, não funcionou com projetos de software.

Pois é, “projetizamos” a TI, criamos inúmeros indicadores, novas funções, gestão de mudança complexa e ainda assim falhamos. Será que podemos dizer que “deu errado” mesmo com tantas empresas utilizando e milhões e milhões de projetos entregues neste modelo? Sim, podemos!

Não estou aqui para julgar ou menosprezar o trabalho de tanta gente boa no mundo, que fizeram e ainda fazem projetos neste modelo, mas o fato é que a gestão de projetos no Brasil virou um “me engana que eu gosto”. Em TODAS as grandes corporações que tive contato existiam METAS e indicadores claros que impactavam o dinheiro/bônus de todos em cima das entregas dos projetos. O que criamos? Um bando de gente perseguindo o farol verde no projeto. Ninguém preocupado com o consumidor final, tampouco com o software funcionando e gerando o ROI para qual este projeto foi concebido. Já dizia na Bíblia da Transformação em JB capitulo 4 versículo 8: “Diga-me como me medirás e eu te direi como trabalharei”.E

E no cenário “finge que me engana e eu finjo que acredito” temos Gerentes de Projetos certificados que estudaram pra caramba e já sabem que não vão aplicar nem 15% do conhecimento de gestão de projetos na vida real. Este gerente de projetos também não é, e nunca foi empoderado por executivos. Também criamos o PMO que na essência é lindo, mas na prática virou auditoria de GP e assim segue o jogo corporativo.

Não pode estourar prazo, nem custo, nem escopo, mas para o farol ficar verde, com uma change request pode mudar tudo 😊.  Breaking News! “O projeto vai atrasar e não bateremos a META, depois de 1 ano de projeto só descobrimos isso há 1 semana da entrega”. Ok, já sabemos como lidar, sempre acontece isso, vamos lá, tomem nota: War-Room, força-tarefa, carteirada, “crachazada”, madrugada, final de semana, reunião de status diário, checkpoint 2 vezes por dia, deixa a família de lado, abaixa a cabeça, liga o GO HORSE::MODE INSANE e “vualá”, projeto “entregue” verde.

Alguém já viu esse cenário acima? Sabe o que vai para produção e consequentemente para a sustentação? Um lixo. Sabe o que se cria? Projeto pra “evoluir” o projeto (que na verdade é pra refazer). O mundo corporativo se enganou e ainda se engana neste modelo. Por que esse modelo não funciona? Posso elencar uma lista de motivos, mas vou fazer uma analogia de software com construção civil para falar de um dos principais motivos: “requisitos”.

Eu como prefeito gostaria de fazer um viaduto que passe por cima da rua A, ligando a rua B com a rua C, com isso eliminaremos o cruzamento e consequentemente melhoraremos o trânsito em 45% na região.

Claro que existem incertezas neste projeto, mas a grande maioria facilmente mitigável com todo conhecimento da engenharia civil moderna.

Perguntas:

Existe alguma possibilidade de no meio da construção do projeto, com meio viaduto construído:

Alguém dizer que ele tem que virar para algum lado ao invés de ser um cruzamento que vai reto? Resposta: Não.

Sair alguma norma de órgão regulador dizendo que o projeto agora tem que ser diferente, utilizando plástico ao invés de cimento? Resposta: Não.

O seu concorrente, prefeito da cidade vizinha lançar um viaduto disruptivo e por isso você precisará fazer um APP para o seu viaduto e colocar uma roda gigante no topo dele para atender os habitantes? Resposta: Não.

Frente as mudanças de mercado, eleição do Bolsonaro, aprovação da reforma da previdência, esse viaduto não fazer mais sentido e agora ter que mudar pra um túnel com trilhos para trem? Resposta: Não.

Se este viaduto fosse um software, TODAS estas respostas são ou poderiam ser SIM.

Isso só falando de requisitos, fora tantos outros fatores de insucesso de projetos, sendo o maior deles a comunicação. No gerenciamento de projetos o gerente de projetos faz estimativas, reporta, faz status e o time (se é que tem time) “só” executa. O time é induzido pela hierarquia a dar boa notícia, não existe franqueza nem transparência, todo mundo tem medo de dizer que vai atrasar, custar mais ou mudar. A comunicação, quando existe, não é real, nem franca. Mas.... Porém... Entretanto...

Chegou o salvador da pátria, a bala de prata! Metodologias ágeis... Framework Scrum... Agora vamos fazer o dobro na metade do tempo e vamos trocar o Project por Post-iT, Kanban e Jira.

Pessoal o Scrum não está funcionando na maioria das empresas assim como o modelo anterior não funcionava e exatamente pelos mesmos motivos. Scrum é fácil de entender e MUITO DIFÍCIL de implantar corretamente. As pessoas estão focando todas as energias em Kanban, post-it, reunião diária, fazer o GP virar Scrum Master e o Analista de Requisitos virar PO. Receita pronta do FRACASSO (se você fez isso ou está fazendo, ainda existe esperança de mudar).

Como você tem tanta certeza que o Scrum não vai funcionar JB?

Sabe o Scrum Guide que é “tipo” o “PMBOK do Scrum” (risos) com 17 páginas? Ótimo! Lá tem essa resposta, mas na parte que ninguém se preocupa, pois não é glamurosa, e vai de encontro diretamente com o que o Executivo e Gestor de TI menos sabe fazer, GESTÃO DE PESSOAS. Ali no comecinho do Scrum Guide tem os 3 pilares do Scrum e os valores do Scrum.

PILARES

Pilar é um elemento estrutural usado para sustentar e distribuir o peso. Ou seja, sem os pilares uma construção não se sustenta e o Scrum sem os pilares também não se sustenta.

Pilares do Scrum: Transparência, inspeção e adaptação.

Pgora vou dar exemplos de que não existem os pilares do Scrum na vida real dos projetos no Brasil na maioria das grandes empresas:

Transparência – Você acredita que somos transparentes hoje nos nossos projetos? Estimamos a realidade? Acordamos a realidade? Comunicamos a realidade? Reportamos em todas as esferas a realidade? Todo mundo sabe e pode saber o que está acontecendo nos nossos projetos? Não, tudo na base do corporativismo e mentiras.

Inspeção – O trabalho sendo desenvolvido é inspecionado diariamente em todas as etapas como em uma linha de produção? Não! Somente depois que acaba o desenvolvimento existe um time que testa sem muita referência e aí surge a frase maravilhosa TA PRONTO, só falta testar. E o tempo de teste cai de 10 dias pra 10 horas e a qualidade é ignorada para atingir o farol verde.

Adaptação – Change request, comitê, aditivo contratual, e-mail, formalização, chancela do presidente, de acordo do papa, formalização de 5 diretorias, tudo em 3 vias autenticadas no cartório, pronto, agora pode mudar o requisito. Custo real da mudança R$ 5.000,00 custo do processo de gestão de mudança R$ 35.000,00.

VALORES

Em ética, valor denota o grau de importância de alguma coisa ou ação, com o objetivo de determinar quais são as melhores ações a serem tomadas ou qual a melhor maneira de viver (ética normativa), ou para determinar a importância de diferentes ações. https://pt.wikipedia.org/wiki/Valor_(%C3%A9tica)

Valores do Scrum: Coragem, Foco, Comprometimento, Respeito e Abertura/Franqueza (a tradução que você preferir para Openness).

Ou seja, antes de tomar alguma ação você precisa analisar se esta ação fere algum valor e sempre tomar decisões baseada nos valores. Isso vale para pessoas, culturas, empresas e para o Scrum.

Agora vou dar exemplos de que não existem os valores do Scrum na vida real dos projetos no Brasil na maioria das grandes empresas:

Coragem – Todo mundo sabe que não dá, mas ninguém tem coragem de dizer. Quando acontece o obvio, problemas, aí começa a caça às bruxas (quem é o culpado?), war-room, go horse e vocês já sabem o final da história.

Foco – O mesmo time que está “dedicado full-time” em um projeto também atende outros 5 projetos, sustentação e reuniões de novos projetos.

Comprometimento – Não existe compromisso com uma data que o time não deu, de um requisito que o time não entende, custando algo que o time não concorda.

Respeito – Nesse quesito até onde eu vivi consegui ter o mínimo, único desrespeito é passar projeto pra sustentação sabendo que está passando uma bomba. Costumo chamar isso de tráfico de drogas rs..rs..

Abertura/Franqueza – Se você falar a verdade será visto como o pessimista, não veste a camisa, desmotivado.

Ou seja, não fazemos o básico, vivemos na gestão do medo, baseamos tudo na mentira, todo mundo sabe que é mentira, mas não tem coragem de dizer a verdade, principalmente para gestores e executivos.

Já viram ou ouviram falar de uma área de TI que sem base nenhuma pra pedir orçamento do ano faz “estimativas de grau zero” (nome bonito para “um chute pessimista com 100% de gordura”). Após isso, quando chega perto do último quarter e não gastou todo orçamento, aí faz uma “força tarefa de gastos” pra conseguir realizar o orçamento para não ter menos orçamento no ano seguinte? (eu já ouvi falar uma vez, acho que foi em Londres, uma lenda sobre isso).

A transformação organizacional só vai acontecer se formos justos e sinceros. Temos que aprender a desenvolver, testar, errar e mudar (PDCA?). Temos que aprender a aceitar o erro, aprender com ele e mudar rápido. Enquanto não aceitarmos o erro e medirmos os times por farol verde ele sempre será verde, mesmo que seja mentira.

Antes de pensar em times ágeis, escalar o Scrum, pense e reflita sinceramente se vocês já conseguem hoje ter os pilares e valores do Scrum na essência na sua empresa.

Sim?

Então ficou mais fácil, agora só falta:

Desburocratizar;

Deshierarquizar a empresa dando poder para o time;

TREINAR o time todo em Scrum (se possível certificar com CSM e CSPO);

Engajar o “C-Level” da empresa;

Fazer um planejamento organizacional com o RH.

Vale ressaltar que lugares que já possuem os pilares e valores do Scrum na cultura da empresa (como muitas startups onde o CEO é parte do time que executa), se você usar qualquer método, processo ou framework terá resultados incríveis, não apenas com o Scrum. No fim do dia estamos falando de gente e poucas pessoas entenderam isso.

Seu código é um vaso de plástico

  

Seu código é um vaso de plástico

https://www.linkedin.com/pulse/seu-código-fonte-é-como-um-vaso-feito-de-plástico-leonardo-k-shikida 

Programação Defensiva, Orientação por Objeto, Linguagens para as Massas. O título original desse post ia ser este.

Uma das minhas grandes birras com o Facebook é que ele é propositalmente ruim de fazer busca em conteúdo antigo. Então todo o conhecimento ali é perene. Porque não interessa ao facebook referenciar coisas antigas e estragar o cache deles. Facebook vive do fluxo, igual ao Tweeter.

Falando disso porque o Kiko começou uma discussão bacana sobre Java e suas burocracias e gente boa fez comentários pertinentes, mas eles irão se perder para sempre no conteúdo não-indexável do Zuck.

O artigo está aqui e os comentários estão aqui.

Ele já escreveu algo sobre código legado que também vale a leitura.

Eu queria falar um pouco aqui sobre a computação como linguagem, mas não como linguagem de programação, mas como linguagem de intenções e interpretações. O código fala, então parto do artigo do Kiko sobre código legado (a melhor definição que eu conheço de código legado é o código que está em produção. Entrou em produção, tornou-se legado, igual ao carro zero que virou carro usado ao pisar na estrada).

Ao contrário de muita gente de hoje em dia, eu aprendi Orientação por Objeto primeiro e uma linguagem orientada por objeto depois. Eu sou das antigas, aprendi C e Pascal e depois foi aquele parto para aprender Java. Acho que a experiência mais assustadora de Java é seu Hello World verboso e a primeira coisa que me veio à cabeça foi "por que? por que tanta coisa para dizer tão pouco?".

Diga-me então você, desenvolvedor. Por que?

Foi um semestre de orientação por objeto ministrado pelo legendário professor Bigonha (uma das estrelas do departamento da ciência da computação da UFMG, uma combinação de conhecimento e didática incomuns) apoiado num livro clássico do Bertrand Meyer, uma das cabeças por trás de Eiffel, e por conseguinte, de Java. Nenhum livro me influenciou mais na vida computeira que este livro. Se eu pudesse escolher um livro somente, seria este.

A computação se tornou social quando o primeiro programa de computador foi escrito a quatro mãos. A gente aprende rápido sobre a importância da segunda opinião na primeira sessão de debug em que você pede ajuda ao seu colega para achar o bug que seu olhar viciado não vê, e aprende a odiar o próximo quando recebe o código de outra pessoa para dar manutenção (o famoso "código bom é código meu").

Dizem que código deveria ser escrito como se um psicopata que sabe onde você mora fosse dar manutenção nele. E também dizem que a documentação do código é o código em si. Provavelmente a verdade está perto destas duas coisas.

Para permitir código feito por muitas pessoas ao mesmo tempo, criamos o aspecto social do código que é a sua organização, para podermos lidar com sua complexidade. Não criamos apenas padrões de codificação (que carregam consigo parte da cultura daquela linguagem), mas também criamos um processo de evolução da própria linguagem, que torna a linguagem de programação não apenas uma ferramenta, mas uma instituição, que decide sobre sua evolução, sobre a entrada de novos recursos (features), sobre a manutenção do código legado ou sobre a difícil escolha de abrir mão dessa compatibilidade em nome de mudanças estruturais no código (veja Perl).

Tudo numa linguagem de programação tem uma intenção. Tudo o que foi feito teve uma razão de ser. Tanto no seu programa quanto na sua linguagem.

Fora o livro do Meyer, uma das coisas que mais ajuda é tirar certificações. Certificações em si tem pouca importância prática, mas se forçar a estudar para tirá-las é inestimável. Não porque ela te força a aprender como a linguagem é, mas porque ela te leva a refletir porque ela é como é.

Uma vez, um colega de trabalho, muito mais inteligente do que eu, resolveu codificar na mão uma classe que já existia nas Collections do Java. Não porque ele era burro, nem porque era cabeça dura. Ele simplesmente fez isso porque ele achou que codificar aquele "util" era fácil o suficiente e iria resolver o problema dele. Mas eu chamei outro colega de trabalho (também mais inteligente do que eu) para me ajudar a convencê-lo de que aquilo não era uma boa idéia. 

Não porque ele ganhava em reutilizar código (reutilizar código exige aprender algo novo e isso nem sempre é mais rápido que codificar a sua solução), mas porque usar Collections naquele caso era programar para o outro, programar dentro da cultura da linguagem Java. Programar usando algo que o outro já sabe, que ele está familiarizado.

O processo de familiarizar com outra cultura é difícil e mexe com nosso orgulho. Eu gosto de me iludir achando que sou melhor eticamente, moralmente e tecnicamente que as outras pessoas, mas uma análise criteriosa certamente me dirá o contrário. É o que eu chamo da regra do 60/90. Por causa de uma pesquisa relatada neste livro (uma literatura pseudo-científica divertida para se ler no aeroporto e não ser levada tão a sério) que dizia que 90% dos pais se consideravam bons ou ótimos enquanto 60% dos pais consideravam os outros pais medíocres. :-)

Um dia eu fui parar numa fábrica de software CMMI-5 (uma das épocas mais felizes da minha vida, de verdade). Lá tinha um padrão de codificação que estabelecia regras que iam desde a obrigatoriedade do uso de chaves em IFs até a nomenclatura de métodos. Um dos arquitetos de lá me falava sobre a importância da conformidade de todos com o padrão. "Para quando outro desenvolvedor pegar seu código, ele achar que é o dele e não precisar pensar".

Para uma fábrica de software, ou para qualquer comunidade de computeiros que trabalhe junto, não precisar pensar na hora de pegar o código alheio é um benefício muito grande perto do problema de descobrir tudo de novo diante do código dos outros. É como viver em sociedade. Escolhemos abrir mão de pequenas liberdades individuais em prol de algo maior e comum (a medida em que isso ocorre geralmente consiste na diferença entre uma posição política e outra). 

Não bastasse haver um padrão, haviam reuniões periódicas de peer-review onde seus erros eram apontados pelo dedão do grande irmão da empresa. Minha primeira reunião desse tipo me trouxe obviamente revolta. Como ousavam questionar meu código diante daqueles padrões estúpidos. Ok, não era com essas palavras, mas era como eu me sentia, e tempos depois, quando EU era o revisor, eu me lembrava de tudo o que eu tinha sentido quando era o novato que se sentia invadido.

Isso porque, até o momento em que você programa com outras pessoas na sua equipe, seu código é seu castelo. Você fez com o seu suor, seu conhecimento, do jeito que você gosta. Dizem que a pornografia é o conto de fadas masculino, porque ali, tudo acontece do jeito que você queria. Pois bem, o código de uma pessoa só é sua própria pornografia computeira, digamos assim :-).

Eu faço questão de deixar claro os sentimentos porque não estamos falando do código e dos design patterns. Estou falando deste animal vivente que é o computeiro, provavelmente você, que está lendo.

Noutra ocasião, também discuti com outro colega de trabalho (que admiro até hoje) sobre o fail early. Não lembro exatamente sobre o que eu estava fazendo de errado, acho que eu estava tentando tratar as exceções enquanto isso impedia o sistema de expor suas falhas. Ele ganhou a discussão e eu aprendi algo novo.

As tais metodologias ágeis são baseadas nesta concepção da computação como um fenômeno social, de equipe. No fundo, o que ela prega é que a equipe resolva seus conflitos, internamente e com o cliente. Ela cria pequenos artefatos e rituais que, emboram pareçam o pão fatiado para computeiros, provavelmente já foram estudados à exaustão por alguém da sociologia, depois de visitarem muitas tribos indígenas. Computeiros deviam ler sobre sociologia. Já tivemos um presidente sociólogo mas nunca um presidente computeiro.

Agora entra a programação defensiva. Programar de forma defensiva é programar para os outros. Para o outro. É largar a sua pornografia para adotar a pornografia do processo :-). É ser social. É deixar claro para o outro o que você queria com aquele código.

Uma vez, eu peguei um sistema para desenvolver que era uma bomba. Não havia forma fácil de fazê-lo, mas a fábrica só podia contar com pouca gente boa e muita gente júnior então o código não podia ser difícil a ponto de impedir sua manutenção. Quando eu me sentia frustrado, eu escrevia código difícil, como forma de liberar a frustração. Agressividade passiva, dizem. 

Um belo dia, um colega de trabalho bom de serviço veio me perguntar o que significava 1 linha do código, que usava uma operação de XOR. Pense na última vez que você usou um XOR para montar uma interface gráfica. Aliás, pense o que faz um XOR ou como se escreve isso em Java. Lá estava eu, sendo um exibido egoísta babaca numa sociedade computeira que devia ser harmoniosa e altruísta. Lá estava eu, compondo BeBop e pensando "só um músico de jazz foda é capaz de tocar essa passagem". Era isto que se passava na minha cabeça.

A documentação é o código porque não há tempo hábil para manter código documentado. Não há. Java nem sequer checa se seu javadoc condiz com a assinatura do método, até onde eu saiba. Mas se seu método é público, isso diz muita coisa. E o livro do Meyer vai te explicar isso do ponto de vista teórico.

Um dia eu peguei um código aberto escrito por um biólogo americano, que em termos de computação, era um excelente biólogo. Variáveis globais por todos os lados. Pecado mortal para refatoração. Martin Fowler não é um gênio por causa do conceito de refactoring de código. Ele é um gênio porque apenas codigo BEM MODULARIZADO pode ser refatorado. É importante perceber a diferença. E eu precisava pegar aquela aplicação em swing e portar para a web. Como fazer isso num código de alguém que sequer sabia o que era MVC? Ele não estava programando para os outros.

Programação defensiva não é proteger o código de erros somente. É proteger também o código dos erros dos outros porque ele não foi feito para ser compreensível.

Outra coisa poderosa de Java e da orientação por objeto. A faca de dois legumes do aspecto dinâmico da linguagem. Você primeiro instancia e depois usa. É uma forma de compartimentar o erro. Um bug pode existir no seu código por uma eternidade, até que ocorra a condição que cause o bug. Alguns bugs vivem anos e anos no seu código. 

A cada nova versão, bugs antigos somem e outros surgem. O bug vem da nossa atividade humana de programar. Sempre estaremos lutando contra eles e eles sempre estarão surgindo. Poder compartimentar código e seus erros é o que permite um sistema ser desenvolvido por muita gente. É o que nos aproxima daquela engenharia que constrói represas, foguetes, aviões. A programação é social porque os projetos ficaram grandes demais. E as ferramentas se tornaram um problema por si só, porque as ferramentas também são software. E assim lidamos com a complexidade.

Java é verboso. É verboso porque é feito para computeiros serem sociais. Para poder fazer sistemas grandes, Para poder lidar com rotatividade de mão de obra. Para que eu possa tirar férias e o projeto não parar. Código fonte é apenas uma forma de expressar conhecimento sobre algo. Uma linguagem verbosa exige que vc se expresse, talvez mais do que vc gostaria. Nem todo mundo escreve bem ou resolve bem um problema, mas entender o que você faz é importante. Entender sua intenção. Lidar com a complexidade. Quebrar o problema e compartimentar seus erros.

Eu digo que Java é o Karatê das linguagens de programação. Sou faixa branca de tudo. Algumas artes marciais são práticas, como o Krav Magá, ensinam você a lidar com situações. Outras, trazem consigo uma história e uma filosofia por trás, como o Kung Fu. Outras, são modernas, como o Aikidô. Outras, foram feitas para as massas como o Karatê.

Karatê é uma boa luta para ensinar para tropas. As pessoas aprendem "kata"s, que são aqueles movimentos de golpes que vc repete à exaustão. Soldados costumam ser pessoas comuns, muitas vezes humildes, você não pode exigir muito conhecimento prévio. Você precisa dar para elas instruções curtas e simples, e principalmente, efetivas. Dificilmente você vai ver um mestre de karatê no UFC, mas as guerras não são vencidas com super soldados. São vencidas por pessoas comuns.

Da mesma forma, a TI não é feita de gente excepcional do Google, mas por pessoas comuns. Java é uma linguagem para pessoas comuns. A máquina virtual abstrai o que é específico da plataforma não somente pela portabilidade (útil porém rara, alguém já viu a necessidade de um sistema projetado para linux ter que ser portada para windows? é muito mais fácil e barato rodar noutra máquina, oras). A linguagem verbosa te força a ser claro na sua intenção (compare com códigos ofuscados intencionalmente em C ou Perl). É uma linguagem ubíqua (adoro esse termo - significa onipresente, mas foi traduzida como pervasiva) e portanto serve desde o server-side até sistemas android e raspberry pis da vida.

Java é uma das linguagens da commoditização da nossa profissão. A Microsoft não fez C# à toa. Eles sabem da importância de se ter uma grande comunidade de desenvolvedores à disposição no mercado. Estar no mercado é ruim porque os salários tendem a achatar, e é bom porque da mesma forma, dificilmente você ficará sem emprego. A mediocridade (que significa estar no meio e não estar embaixo) pode ser visto tanto do ponto de vista de ser dispensável quanto de ser empregável. 

Muitas vezes, do ponto de vista da empresa, é muito mais vantajoso você ter gente que sabe java em suas fileiras porque você quer ter elasticidade para contratar e demitir rápido do que começar um projeto numa linguagem obscura como Ruby por exemplo, por mais features incríveis que a linguagem te traga.

Acho que já falei demais, deixa eu tentar concluir isso aqui.

Em computação, tudo tem uma intenção. Existe o interesse de quem bolou a linguagem, da empresa que banca sua insituição (no caso de Java, a Oracle, e antes, a Sun). Existe a intenção do contratante. Existe a sua intenção como desenvolvedor. Existe a intenção dos outros da sua equipe. 

E existe a do cliente, que raramente quer ver seu código, que é como um vaso de plástico.

Ninguém se pergunta como aquele vaso de plástico foi feito desde que você possa plantar algo nele e ele dure pelo menos alguns anos.