Hoje em dia a grande moda é ser Co-Founder ou outro nome bonito da onda que gira em torno de Startups. Não tenho nada contra o modelo, pelo contrário, sou suspeito para falar porque já tentei manter e já trabalhei para Startups. O problema é justamente que ninguém fala dos problemas.

Estão vendendo um sonho de que se voce é um desenvolvedor, largue seu emprego e monte uma startup, ou ainda, dedique parte do seu tempo para a criação de uma. Isso é bacana e as idéias e modelos nascidos nessa linha são realmente fantásticas. Acho até melhor do que a onda de até um tempo atrás, aquela que dizia para você parar tudo e estudar para concursos numa espécie de lotaria factível.

Empreendedorismo

O que vejo errado são os motivos para se empreender. Como se trabalhar para alguém fosse algo nefasto ou que você é explorado por capitalistas porcos e o lucro fica com seu patrão, numa espécie de revisão marxista da errada mais-valia.

Empreendedorismo não se aprende na escola, desculpe se te fizeram acreditar nisso. A escola pode te lapidar, mas empreender é um dom como jogar futebol, ter lógica de programação, saber desenhar ou quaisquer outras aptidões que não conseguimos ensinar, está dentro de você. Existem motivos errados para empreender, como: Por amar um produto você deseja possuir a fabricação dele, se sentir menosprezado ou explorado pelo seu atual empregador, querer ficar rico, querer glamour de um Zuckerberg, ir na onda de que isso é a evolução natural de um bom desenvolvedor, etc.

Mas tenho que te alertar, empreender é um outro campo totalmente distinto e com sua particularidades, nem melhor e nem pior do que sua profissão, só diferente. Empreender nem sempre vai te fazer ter um patrimônio maior ou ganhar mais grana. Existem milhares de executivos e profissionais liberais com mais grana e patrimônio do que eu ou milhares de empreendedores.

Alguém deixar seu trabalho para fundar uma Startup por algum desses motivos que levantei soa para mim da mesma forma que alguém deixou de programar e foi fazer advocacia porque dava mais grana ou qualquer outro motivo que não a aptidão.

Empreender é outra “profissão” e exige conhecimentos que voce provavelmente não gostará de adquirir. Contabilidade e administração pode ser muito chato e entediante, mas necessário para um empreendedor. Sabe vender? Ou acha que vai ficar só retwittando seus produtos e esperando os compradores aparecerem como mágica?

Deixa eu te contar outra coisa que voce não lerá nos contos sobre Startups, aquela história de que “Construa que eles virão” é falácia. Construa, anuncie, divulgue, trabalhe, faço-os conhecerem, faça-os experimentarem, caia, levante.

O tiro de misericórdia, Startups não são o fim de um negócio, só o início, Startup quer dizer: “Projeto de empresa sem grana, fudido, com o sonho de um dia dar grana de verdade”. Voce acha que existem dois Twitters?

Acreditar em um modelo de sucesso e não perceber que ele é exceção é como achar que todo jogador de futebol ganha bem e é bem sucedido.

Não estou desencorajando ninguém a empreender, pelo contrário, estou alertando sobre os perigos de se iludir e não ter ninguém para te balançar. Se quiser empreender, empreenda, mas se voce tiver aptidão.

MMA ou Mixed Martial Arts é um negócio atual lucrativo que rende bilhões de dólares e criou um mercado gigantesco em volta. Lutadores, que outrora brigavam entre si nas praias cariocas, hoje são empresários de sucesso e alguns até parceiros.

A história que todo mundo conhece e repete é aquela onde o Rórion Gracie levou aos USA a arte da família, cultivada e aperfeiçoada em solo brasileiro durantes décadas, o genuíno Jiujitsu Japonês que os próprios japoneses deixaram desaparecer.

Só que a história vai um pouco mais além, esconde alguns segredos que foram revelados no livro da Reila Gracie, filha do lendário Carlos Gracie, criador dessa dinastia de lutadores e responsável por um mercado que não existiria sem ele.

Você pode estar me questionando nesse momento – se não leu esse livro – se esse mercado que existe foi uma consequência involuntária das ações do Carlos Gracie, na verdade foi proposital, pensada e arranjada. Vou tentar resumir um livro de mais de 400 páginas e traduzir como esse homem foi um empreendedor.

Carlos Gracie era o irmão mais velho, foi o primeiro a treinar sob a tutela do Conde Koma, um japonês radicado no Pará e membro da famosa Kodokan, escola criadora do Judô. Até meados da década de 50 do século 20, o judô era chamado ainda de jiujitsu em grande parte do mundo, porque o Judô na verdade foi a reunião de todos os estilos de Jiujitsu que se uniram na Kodokan.

Carlos Gracie na verdade aprendeu o Judo Kodokan, que na época não era como o esporte olímpico que conhecemos hoje, os lutadores dessa escola viajavam o mundo inteiro disseminando o “novo estilo” por meio de desafios no que ficou conhecido aqui no Brasil por vale-tudo. Carlos Gracie e seus outros 4 irmãos nunca treinaram um estilo de Jiujitsu tradicional japonês, eles foram alunos do Jiujitsu Kodokan, nomeado aos poucos para Judô.

Desde o início o Carlos vislumbrou um negócio duradouro, uma espécie de empresa-família em volta do Jiujitsu.

Campeão da Família

Toda empresa que se preze tem uma marca bem trabalhada. Carlos instituiu o papel de Campeão da Família, que começou com ele próprio. Para se ter uma idéia de como ele planejou tudo com olhos de um empreendedor que pensa nos negócios, veja como ele escolheu seu sucessor.

Para se dedicar aos negócios com mais afinco, Carlos tinha que escolher um de seus irmãos para o papel de campeão da família, por todas as declarações da época, George Gracie seria o mais indicado. Lutador talentoso e vitorioso de todos as lutas que o irmão marcou para ele. O problema é que George era metido a playboy, indisciplinado e desobediente. Tanto é que chegou a fazer lutas combinadas, algo que o irmão detestava e ía contra aquilo que estava construindo.

Veja bem, até nisso ele planejou com esmero, Carlos desde o início planejou vender o Jiujitsu como a melhor arte de combate já criada e sua família a que tinha o melhor jiujitsu, participar de lutas ensaiadas demoliria sua estratégia de fortalecer aquela marca.

Mas o pior do George era não obedecer o irmão, portanto Carlos escolheu o Hélio, caçula que idolatrava o irmão mais velho. Hélio era o oposto de George, disciplina deveria ser seu sobrenome. Criou-se a lenda de que Hélio desenvolveu o Jiujitsu junto com o irmão, nada disso, Carlos planejou tudo com cuidado.

Geração após geração foi-se definindo o campeão da família. Esse papel de campeão além do Marketing vital para aquele negócio, tinha outra estratégia crucial. Para enfrentar o campeão, um desafiante teria que enfrentar um aluno menos graduado para provar seu valor, dessa forma eles poderiam avaliar como o sujeito lutava e se prepararem em cima das fraquezas com um treino direcionado. Não existia um estilo de luta Gracie, existia o estilo necessário para cada luta em particular, metricamente calculado com o que funcionava e muito bem treinado.

O Estilo Gracie

Se existe um meio onde se mais tem charlatão, esse meio é nas artes marciais, toda esquina tem um mestre que criou sua própria arte marcial aprendida de um japonês ou chinês que mantinha um segredo medieval. As Artes Marciais parece um pouco com outros campos, para se ter uma idéia de protocolo, alguns líderes de clã samurais sequer sabiam lutar, mantinham a liderança porque eram os responsáveis pelos documentos da escola, passada de pai pra filho.

É um negócio rentável, basta dizer que não pode lutar porque tem segredos que poderiam matar o adversário e viver um tempo enganando as pessoas enquanto toma dinheiro delas. Carlos desde o início foi prático quanto a isso.

Os Gracies nunca tiveram cerimônia para manter os nomes em japonês dos golpes, talvez sequer tenham aprendido. Não lembro se há menção no livro da Reila, mas há relatos de que um ex-aluno do Conde Koma afirmou na década de 30 ou 40 que os Carlos nunca chegou a ser faixa-preta pelas mãos do Conde. Isso não tem importância, na época não existia uma clara definição sobre faixas, o que importa é que ele aprendeu a lutar e aprendeu a enfrentar desafios. Ele poderia ser tratado como mais um empresário com superior incompleto que deixou a escola para criar um império.

Os Gracie mantiveram a luta de solo como foco do seu estilo porque em um desafio com poucas regras definidas toda luta vai para o chão e se você não domina, você é dominado com facilidade, estratégia boa para 5 irmãos franzinos.

Ele nunca admitiu, mas também nunca condenou as afirmações que eles desenvolveram a luta de chão que fez o Jiujitsu Gracie tão especial, eles não inventaram nenhum golpe, nenhuma “alavanca” como se mitificou.

A praticidade do Carlos sempre favoreceu o combate e as técnicas que funcionavam, qualquer outra coisa era deixado de lado, concentração total na vitória das lutas. Poderíamos até traçar um paralelo com certificações técnicas, a única certificação válida para Carlos era a prática, a que trouxesse vitórias.

A Empresa

A família chegou a ter várias academias frequentadas pela elite carioca, desde desembargadores, passando por senadores a presidentes da república. Até os infortúnios conspiravam a seu favor, como o caso quando foram presos por espancarem um desafeto e receberam um indulto do próprio Getúlio Vargas. Esse networking facilitava muito as coisas.

Os Gracies treinavam e mantinham os melhores alunos como se fossem membros da família, eles sabiam que nunca se tornariam o Campeão da Família, mas eram reconhecidos dentro da empresa e ganham muito bem, até porque era do interesse do Carlos que eles fossem muito bons para evitar ao máximo expor o campeão e ainda por cima serviam como o melhor “sparring” que existia e de graça.

Numa época que não existiam startups e nenhuma empresa colocava refrigerantes e puffs para seus “recursos”, Carlos levava seus alunos para morar consigo, frequentar sua chácara e ensinar em sua academia como um irmão Gracie. Isso é tratamento de sucesso com seu empregado, o resto é bobagem.

O Negócio

Frases bem trabalhadas e expressões como “Se você quer um braço quebrado contate Carlos Gracie neste número” eram constantemente veiculadas nos principais jornais da então capital do Brasil.

Carlos queria vender o Jiujitsu como a arte mais eficiente e sua família como possuidora do melhor Jiujitsu, dessa forma mesmo quando a família perdia para outro membro do Jiujitsu eles ainda se beneficiariam, já que apenas o Jiujitsu pode vencer o Jiujitsu e aquela derrota com o tempo desapareceria, como ocorreu com todas as derrotas dos Gracies.

Carlos se cercava de todas as nuances para fazer seu negócio prosperar, ele “inventou” até uma dieta que ficou conhecida como Dieta Gracie e clinicou como nutricionista por muitos anos quando nem existia essa profissão. Existe a teoria de que ele não inventou essa dieta, copiou de um médico argentino. De qualquer forma ele pensou em tudo em volta do negócio Gracie, desde o estilo ao modo de vida que eles deveriam levar.

O negócio de vale-tudo passou por períodos de brilho e períodos de ostracismo, a família nunca “mudou de ramo”, apostou sempre no produto e souberam esperar o timing certo. Não dá para especular o que ocorreria se outro Gracie tivesse levado o modelo aos USA em outro momento, se fosse na época de Bruce Lee provavelmente ninguém teria dado bola, atores faziam mais sucesso do que artistas marciais. O Certo é que no momento que o Rórion levou o Jiujitsu Gracie para o celeiro do Show Business, o formato do negócio estava trabalhado por quase 80 anos.

Tanto que nos primeiros 3 show do UFC, seu irmão Royce, que nem era o Campeão da Família, sequer um dos melhores da família, venceu com tanta facilidade que parecia brincadeira de criança, muitos chegaram a duvidar da veracidade das lutas, tamanha a facilidade.

Os brasileiros são os maiores vitoriosos no contexto geral dentro desse esporte/negócio, porque o modelo e formato estava bem trabalhado por aqui pelos Gracies. Pena não termos empresários liderando as principais organizações de lutas, daí podemos comparar Carlos Gracie ao Barão de Mauá, empreendedores solitários em uma país não propício a empreendedorismo.

A família se desentendeu como em toda sucessão empresarial familiar, mas hoje todos aqueles que vivem do MMA devem agradecer a esse empreendedor. Filtrei alguns pontos importantes da visão que o Carlos Gracie teve para seu  negócio, mas a história é muito mais interessante do que esse resumo/review, deixei de fora alguns pontos polêmicos como seus mais de 20 filhos com diversas esposas, mas o legado do Carlos é maior do que alguns percalços que tenha provocado.

Bem rápido uma opinião sobre o tema lançado na @java_ce, em outro momento eu discorro mais sobre:

Imagina que você é profissional de RH com formação clássica onde todas as outras profissões são bem delineadas em relação a responsabilidades, o que voce colocaria na vaga?

Ainda não chegamos a definir o que somos, o que fazemos, imagina pessoas de outras áreas. Dentro da grande área que eu poderia marcar como computação – só uma definição imprecisa para nos situarmos – não temos essa delimitação e tudo tende a fragmentar ainda mais.

Teoricamente eu colocaria Cientista da Computação ou Bacharel em Sistema da Informação que já bastaria, mas hoje as empresas sabem que não representa nada, mais a frente volto nesse tema.

Há 5 anos um profissional poderia se autodenominar “programador Java” ou “programador .net”, hoje se ele fizer isso já limita sua empregabilidade. Hoje precisamos de profissionais que não coloquem suas preferências tecnológicas acima das necessidades da empresa, que resolva os problemas com a melhor solução para aquele problema.

Educação atual

Diante dessa necessidade que evidenciei no parágrafo anterior, as escolas atuais não estão preparadas para preparar profissionais para a nossa era, quando eu digo profissionais eu estou me referindo a todos, um pesquisador é um profissional – enfatizo isso porque aqui no Brazil há uma pequena confusão sobre o papel de um pesquisar, ainda mais porque existem pesquisadores públicos carreiristas que lançam papers que ninguém lê e não tem responsabilidades de produzir.

Na era da “Terceira Onda”, Alvin Toffler diz: “A escola precisa preparar os alunos a aprender a desaprender para reaprender”.

Diferente de um médico que basta se especializar em seu campo de atuação, como cardiologia – só para exemplificar, nós em contrapartida precisamos ser clínicos gerais com múltiplas especializações que muda radicalmente a cada meia década e com tendencias a mudar a cada trimestre – em mais uma analogia imprecisa.

Isso se dá porque o corpo humano não muda seu funcionamento no próximo trimestre, enquanto o que fazemos tende a aperfeiçoar não só seus métodos, materiais [ferramentas] e necessidades ao longo do tempo, muda também os princípios básicos que estão fundamentadas. Ok, máquina de turing ainda define a computação que conhecemos, mas a distância entre a teoria de Chomsky e a evolução das linguagens avança num ritmo que não vemos em nenhuma outra área, olhe que nem temos teoria matemática sólida para orientação a objetos e temos todo um corpo de estudo.

Algumas pessoas veem nisso o terror, eu não os condeno, ainda mais se sua formação educacional clássica o moldou a pensar na segunda onda, industrial. Nós somos de uma profissão criada na e para a terceira onda.

A educação clássica industrial já foi criticada pela forma, estrutura e burocracia por Schopenhauer em sua obra “Sobre a Filosofia Universitária” e por essência pelo Aldous Huxley principalmente em “A Situação Humana” e “Admirável Mundo Novo” – na minha visão.

Não vou entrar nesse tema, vou escrever mais sobre isso no futuro sobre como a educação na nossa era ainda não se encontrou.

Nesse momento o ponto principal que quero chegar é sobre a condição do aluno médio.

Passividade

O grande problema atual não é porque a escola/universidade não consegue ensinar ou como dizem: “preparar o aluno para o mercado”, é sobre como as pessoas são passivas em um admirável mundo novo que precisa de pessoas ativas.

Que a escola não está preparada, isso todo mundo já percebeu em algum momento, mas o problema é mais profundo e  agora visualize a seguinte situação para entender em apenas 3 atos:

1 – Alguém envia um vaga de estágio para uma lista de discussão, essa pessoa não aparenta ter vínculo algum com a empresa da vaga;

2 – o primeiro a responder pergunta para onde deveria enviar email;

3 – o segundo envia o currículo para a própria lista e não para o responsável.

Agora veja só, de que adianta uma pessoa cursar universidade, estudar cálculo 1, 2 e 3, álgebra linear, lógica de programação, banco de dados – teoria de como é feito um, estruturas de dados e toda sorte de matérias de nível superior se essa pessoa não consegue ser proativa.

Básico, se você não entendeu o problema nessa situação que relatei, então não será com uma explicação minuciosa que irei te provar ser grave.

Isso não é culpa da escola, é de vida, é uma pessoa doutrinada a esperar a vida seguir uma espécie de rumo natural, onde ele estuda formalmente em uma instituição definida e controlada pelo estado, arruma um emprego, constitui família, se aposenta e morre.

Esse tipo de profissional é a média, portanto a maioria absoluta. De quê adianta exaltarmos os “outliers” se quem faz a máquina andar é o cidadão médio?

Não sei o que pedir

Eu já trabalhei na indústria, uma das queixas do “pessoal de RH” era de que não tínhamos definição dos cargos no setor – chamávamos e éramos chamados de CPD, não, não sou tão velho

Todo mundo “crimpava” cabo de rede, dava manutenção no servidor, configurava o recém lançado SQL Server 7, criava “rotinas” no ERP feito em C e vez por outra recebia ligação da recepção porque o telefone estava mudo, sim, era uma situação de cão.

Nessa época a gente mandava colocar no currículo tudo que fazíamos, a lista era imensa. Em alguns CPDs, principalmente aonde tinha mainframe, havia uma clara distinção de pelo menos dois perfis, programador e técnico/admin de rede. Nas empresas pequenas e médias já não tinha muito bem essa distinção.

No começo da década de 2000 a coisa mudou de figura radicalmente, alguns papéis como Analista de Sistemas, Gerente de Projetos, entre outros, começaram a delinear os cargos e perfis. Agora já colocávamos na descrição das vagas algo como: “UML, Java, EA”.

E o caos voltou…

Por volta de 2005 pra cá essa situação que vivi na década de 90 e vi na década de 80 começou a arranhar uma volta, hoje com a popularização de devops, não se admite que um profissional não saiba configurar pelo menos um servidor. Como falei antes, o programador que se autodenominar de “Programador whatever” já não serve.

Se voce se chama programador rails, programador java ou programador .net, se acostume, você está com seus dias contados – pelo menos na próxima meia década.

Frente a isso é muito comum vê hoje vagas com centenas de requisitos, linguagens, frameworks e coisas que teoricamente não fazem sentido.

Na última vaga de estágio anunciada eu tentei reduzir ao máximo e pedir somente lógica de programação, seja lá o que for isso, para receber todo mundo e analisar cuidadosamente cada perfil.

Não me assusta alunos com 6 ou 8 semestres em nível superior não estarem preparados para o mínimo necessário esperado em sua profissão e acusarem as empresas de “pedirem em excesso”, o que me impressiona mesmo é a mentalidade industrial.

Hoje especialmente você tem uma escolha muito grande aonde trabalhar, parece brincadeira, mas não é, se falar inglês e ter proatividade, escolhe quanto quer ganhar.

Agora o que é proatividade?

Aqui no Ceará nós chamamos de desenrolado. Simplesmente é uma pessoa que se cria, você não precisa mandar fazer, ele detecta uma necessidade, pesquisa sobre isso, procura quem sabe, pede conselhos, opiniões e resolve. Ou pelo menos aponta que encontrou o problema e precisa de ajuda para resolver.

Hoje esse profissional é fora da curva e você tem que ralar muito para encontrar. O médio espera você mandar fazer.

Duas horas produtivas para mim é uma licença poética para “códigos testáveis de forma automatizada, bem escritos, entregues por dia independente de tempo e que não trarão retrabalho”. Um par evita muito retrabalho, lembrando que retrabalho não é refactoring, é prejuízo.

Claro que não há método científico algum, apenas inferência por observação simples. Dia desses um funcionário de um cliente me disse:

“- Milfont, essa sua teoria é mais um dos seus exageros”.  Respondi:

“- Olha do lado, observe o que todos estão fazendo”.

Para espanto desse funcionário, ao olhar para o time mais caxias da empresa, aquele time considerado certinho, que ninguém conversa com ninguém, ele tomou um susto e detectou que todos, eu disse T-O-D-O-S, estavam com o cliente de email aberto. Ninguem estava com sua IDE em primeiro plano.

Coincidência?

Trabalho Energizado

Como consultor eu enfrento problemas de coaching e mentoring [adoro buzzwords] em relação a dificuldade da alta gestão não compreender os benefícios de programação em par para o trabalho energizado. Não que programação em par seja o único responsável por um trabalho focado, mas sem essa prática não dá nem para começar a mudar o cenário.

Todos meus clientes dizem em uníssono: “Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”. Investigaremos essa frase ao final.

Meu trabalho como consultor é transformar galinhas mortas em galos de briga, então não tenho pretensões nem esperança que em um mês meus clientes terão integração contínua, todos seguirão Test First como prática e serão felizes para sempre, no mundo real a coisa é só um pouquinho mais complicada. Enfrento muitos clientes saindo da década de 80 direto para o novo milenio, é uma leva de CVS, Delphi, até clipper, além de vícios provocados por essas plataformas/arquiteturas/whatever.

Agile Bibas

Hoje é muito comum meus clientes pedirem planilhas e técnicas para medir velocidade e desempenho de seus “recursos” porque leram sobre isso nas revistas da moda. Isso é perda de tempo, vou cair no clichê mas não posso deixar de falar, enquanto voce não tratar seu time como pessoas e que elas não são máquinas controladas, não espere retorno deles.

Leonardo Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se comprometem com as planilhas. Apenas comando-controle disfarçado de ágil.

Esqueça métrica de time, concentre-se na métrica do software. Não importa se o membro do time está nu, pulando corda, de cabeça para baixo, lendo emails ou enchendo a cara numa terça de manhã. O que importa é se as features foram entregues e com qualidade.

Parece simples mas não é, a soma “8 + 8 = 16″ é difícil de ser anulada [imaginar que 8 horas de dois funcionários representam 16 horas de trabalho produzido com qualidade]. Medir tempo por funcionário é um dos maiores erros para tentar aumentar a produtividade do time.

Vou dizer mais uma vez: “Não meça pessoas, meça e entregue software”. Então não importa se seu funcionário não trabalha as 6 ou 8 horas que você espera que ele trabalhe, o que importa é se as duas features planejadas para hoje foram entregues com a qualidade esperada.

Evitar o trabalho chato

Algumas empresas ainda sonham com a esperança que basta impedir o acesso a redes sociais ou serviços na web, então o funcionário vai parar o “Goofing Off“. Existem inúmeros motivos para uma pessoa não estar energizada em seu trabalho, considero o principal como sendo “fazer trabalho chato”.

Vamos agora analisar aquela frase do início:

“Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”

Observe que essa frase revela duas nuances onde o cliente acredita que trabalho em par não é importante, uma consequência da outra. Trabalho simples que provoca a necessidade de não trabalhar em par o tempo todo.

A primeira coisa como consultor quando sou contratado para mudar a cultura do time é tentar incluir programação em par como algo natural e prática necessária, para tanto preciso anular esse trabalho chato que considero ser basicamente trabalho repetitivo. Observe na frase anterior que meus clientes chamam esse trabalho de “simples”.

Não é simples, é chato.

Exemplo que me veio a cabeça agora mesmo, todos os cliente que não tem Test First como prática, então ficam testanto as coisas durante o desenvolvimento na mão, para tanto precisam gerar dados.  Para um desenvolvedor é frustrante ficar fazendo dump e passando para seus colegas de trabalho, porque não automatizar isso?

Todos meus clientes que não fazem Test First passam por isso. Ora, se mesmo os que tem essa prática nós enfrentamos desafios de um bom Setup para garantir a independência no INVEST, imagina os que não fazem.

Outro erro comum é achar que número de commits é sinal de proficiência ou estar trabalhando mais, em regra, para mim é sinal de muito trabalho repetitivo.

Não vou me prolongar, quero só concluir que evitar trabalho chato ajuda a demonstrar que Pair Programming é sim necessário o tempo todo e que se isso for alcançado a “morcegação” tende a diminuir e o reflexo na entrega de funcionalidades se torna positivo. Junte a isso o foco no software ao invés de medir pessoas e esqueça as toneladas de planilhas, na maioria das vezes nem um Burndown seja necessário, apenas trabalho energizado.

(…)”A dúvida era essa: Linguagens dinâmicas dão maiores possibilidades de inclusão de erro no código com isso aumentando de forma significativa a refatoração.”(…)

Em conversa com um excelente desenvolvedor aqui no Ceará, Delberto Muniz, ele escreveu a seguinte resposta:

Estava relendo um livro sobre os primórdios da programação e houve um debate semelhante: Os programadores Assembly achavam que programar em Fortan dava maiores possibilidades de erros porquê o programador não tinha total controle sobre o código gerado.

Dez anos depois o pessoal do Fortran falou mal do Algol porquê Algol abstraía demais e o programador não tinha total controle sobre a linguagem.

Aí veio o pessoal do C/C++ dizendo que Java abstraía demais, deixando margens a bugs serem introduzidos nos programas pelo compilador e/ou pela vm ou porquê simplesmente ele não estava alocando/desalocando memória manualmente.

Só mudaram as linguagens – o debate é sempre o mesmo: Se eu aumentar a abstração, meus programadores vão fazer besteira?

Se você está com essa dúvida, sinto muito: Você está nivelando por baixo e/ou não conhece seus desenvolvedores.

Se eu fosse um novato, recém integrado na faculdade, sem base acadêmica para duvidar de um Dr. [ou quase] eu estaria destruído com minha ignorância.

Esse é o temor que tenho da academia, a sua falta total de pé-no-chão ou conhecimento real daquilo que ensina, é o que me fez abandoná-la e nunca mais pisar por lá.

Tantas citações a obras importantes é típico da academia, mas o discurso que eu gostaria de ouvir não existe:

“Quando eu implantei CMMi na XPTO…”

“Quando eu trabalhava com RUP, nós…”

Na prática a teoria é outra

Caro Dr., eu estudei muito sobre isso, li todos esses documentos e até cheguei já a acreditar que eram válidos para garantir a qualidade de um produto. Claro, isso no início desse século quando eu era estagiário e sem conhecimento real.

Depois de passar por implantação de CMMi mais de uma vez, ISO e Mps.Br, foi que aprendi o valor da teoria e como aquilo que está escrito não reflete a realidade na “engenharia de software”.

Talvez o que mais me marcou em verificar que não existe engenharia de software [ou ela é ainda muito incipiente] foi ter participado de avaliações ISO em outros setores como indústria, imobiliária e serviços. Fica evidente para todo mundo que a avaliação nesses setores é de processo e não de produto e serviço porque eles tem métricas reais e aplicáveis em suas industrias.

Quando CMMi ou ISO falam em qualidade de produto eles não dizem como fazer e sim o que fazer, essa é a diferença básica entre processo e produto, caro Dr.

Essa bobagem semântica  faz toda a diferença, quando eu avalio a qualidade de um produto como uma garrafa PET, existem métricas reais para testar a qualidade [como por exemplo durabilidade], existe um processo normatizado por órgãos [como ANATEL, ANVISA, e tantos outros] que garantem a qualidade mínima do produto ou serviço.

Esse foi o seu primeiro erro conceitual, dizer que tem que fazer é diferente de dizer “como” tem que fazer. “O que” é processo, DR. “Como” é produto, Dr.

Testes de Software

Vou fazer um mea-culpa porque quando escrevo eu sempre esqueço que meus leitores não me conhecem e não podem advinhar o que fica nas entrelinhas, eu não gosto de citar referências por preguiça de sair catalogando nomes de livros e autores [só quando lembro na integra de cabeça e acho importantissimo] e espero que as pessoas não acreditem em uma só linha sem verificar. Como vão verificar, eles acham a referência por si só, não preciso colocar bibliografia nos meus textos.

Esse trecho fica evidente que falho por omissão:

Há controvérsias sobre testes automáticos garantirem qualidade interna, na verdade, não vejo onde há relação direta. Testes são sim de suma importância, independentemente de serem automatizados ou não, que fique claro, mas não garantem totalmente a qualidade, nem externa e muito menos interna (em breve explicarei o porquê), muito menos é o único método para se conseguir qualidade. Inspeções e revisão de software (e especificações associadas), juntamente com analisadores estáticos, são tão efetivos quanto testes na detecção de defeitos e tem possibilidade maior de melhorar a qualidade interna de produtos de software.

Quando falo em testes, é óbvio para quem me conhece que estou me referindo sobretudo a TDD e também BDD. Testes por si só não garantem nada, nem sequer que as falhas estão cobertas.

O processo de TDD é que fortalece a qualidade interna do software porque ao você aplicar as práticas desse processo, você se torna minucioso na verificação de coesão, complexidade, acoplamento sem precisar de ferramentas de análise de código.

Eu não estou afirmando que não use ferramentas de análise de código, longe disso, só que essas ferramentas não verificam qualidade real no código, no máximo elas avaliam erros clássicos e mau cheiro no código. É perfeitamente possível escrever um código horroroso e ilegível e passar por todas as ferramentas de análise de código facilmente, isso acontece na prática no cotidiano.

Como testar?

Antes de me dizer, responda-me: Você faz que tipo de teste? Unitário, integração, sistema, aceitação? Testes funcionais, estruturais ou baseados em defeitos? Para testes funcionais, você utiliza classes de equivalência, análise de valor limite, grafo causa-efeito e ainda tenta error-guessing? Para testes estruturais, você aplica grafos de fluxo de controle? Como define seu critério de cobertura de instruções, decisões, condições e caminhos? E quais das métricas já citadas ou quaisquer outras tem adotado? (Zhu, Hall and May, 1997) Se você não tiver uma boa estratégia para cada uma destas táticas, sinto muito informar-lhe, mas VOCÊ NÃO SABE TESTAR SOFTWARE.

Eu não sigo as estratégias do Zhu “Who?”, eu sigo um AMADOR SEM EDUCAÇÃO chamado Kent Beck que não é nada científico mas funciona. Sim, eu faço testes unitários, integração, aceitação, stress, carga e o que der mais para fazer com o tempo disponível para entregar o software o mais saudável possível. As ferramentas de análise de cobertura são frágeis e deixam escapar a real cobertura, da qual temos que aplicar triangulação e outras práticas não-acadêmicas criadas por AMADORES SEM EDUCAÇÃO.

O bacana de tudo são esses números:

Ou seja, mesmo que você tenha 100% de cobertura, você terá apenas garantia de detecção de defeitos em 25% dos casos (Glass, 2002).

Minha vó dizia que os números quebrados tem mais credibilidade, se fosse pelo menos um 25, 37%… vá lá.

Não estou a par de nenhum estudo rigoroso que mostre relação positiva entre presença de testes automáticos e código mais coeso, desacoplado, limpo, claro e legível também.

Dr. o mundo não vive de Papers apenas, saia da academia e visite uma empresa que faça TDD e outra que não, o senhor avaliará por si só. Alias, quem deveria fazer esses estudos era a academia, não? Como farão se não saem às ruas?

Caso alguém tenha, por favor, entre em contato. Gostaria de saber também, se possível, quais processos preocupam-se com qualidade externa em detrimento de qualidade interna. Seriam os processos ágeis?

Todos os processos avaliam qualidade externa pelo que escrevi acima.

O seguinte trecho quase me faz não responder esse artigo:

Por fim, o PROJETO é a quarto e última variável necessária para construir software, porque planejamento e gerenciamento são nossas únicas armas para controlar a complexidade

O que diabos complexidade tem a ver com planejamento e gerenciamento?

Desde quando voce planeja a complexidade de um software?

Fazendo notação matemática do algoritmo?

Desculpe, mas nem todo mundo tem o tempo do Dr. Knuth para entregar software, precisamos de verificação rápida e não notação matemática e não existe um mecanismo que faça isso antes de ter um software escrito.

Novamente, o projeto pode ser tão detalhado e formal quanto se queira.

Não, DR. O projeto não pode ser tão detalhado e formal quanto o queira, isso eu acreditava antes de fazer coisas reais e ficava apenas em cima de livros, se a engenharia de software realmente existisse, eu tinha mecanismos reais para fazer esse detalhamento, mas hoje esses mecanismos reais não existem.

Cada vez mais me convenço de que a academia está morta e não produz nada de real, apenas papers repetitivos de bobagens que ninguem lê.

Deveriam ter terminado a notação formal da orientação a objetos mas estão preocupados demais com “modelos de qualidade” [sic] que nunca avaliaram na prática e não fazem idéia de como mensurar.

Isso não é científico, Dr.

Autor

Texto criado por Bruno Luiz Pereira da Silva
http://twitter.com/blpsilva
http://brunopereira.org/

Original

Baseado no post http://tisimples.wordpress.com/2009/07/28/contra-a-regulamentacao-da-profissao-de-analista-de-sistemas/

Emails dos Senadores

adelmir.santana@senador.gov.br, almeida.lima@senador.gov.br, mercadante@senador.gov.br, alvarodias@senador.gov.br, acmjr@senador.gov.br, antval@senador.gov.br, arthur.virgilio@senador.gov.br, augusto.botelho@senador.gov.br, cesarborges@senador.gov.br, cicero.lucena@senador.gov.br, cristovam@senador.gov.br, delcidio.amaral@senador.gov.br, demostenes.torres@senador.gov.br, eduardoazeredo@senador.gov.br, eduardo.suplicy@senador.gov.br, efraim.morais@senador.gov.br, eliseuresende@senador.gov.br, ecafeteira@senador.gov.br, expedito.junior@senador.gov.br, fatima.cleide@senadora.gov.br, fernando.collor@senador.gov.br, flavioarns@senador.gov.br, flaviotorres@senador.gov.br, flexaribeiro@senador.gov.br, francisco.dornelles@senador.gov.br, garibaldi.alves@senador.gov.br, geraldo.mesquita@senador.gov.br, gecamata@senador.gov.br, gilberto.goellner@senador.gov.br, gilvamborges@senador.gov.br, gim.argello@senador.gov.br, heraclito.fortes@senador.gov.br, ideli.salvatti@senadora.gov.br, inacioarruda@senador.gov.br, jarbas.vasconcelos@senador.gov.br, jefferson.praia@senador.gov.br, joaodurval@senador.gov.br, joaopedro@senador.gov.br, joaoribeiro@senador.gov.br, jtenorio@senador.gov.br, j.v.claudino@senador.gov.br, jose.agripino@senador.gov.br, josenery@senador.gov.br, sarney@senador.gov.br, katia.abreu@senadora.gov.br, leomar@senador.gov.br, lobaofilho@senador.gov.br, lucia.vania@senadora.gov.br, magnomalta@senador.gov.br, maosanta@senador.gov.br, crivella@senador.gov.br, marco.maciel@senador.gov.br, marconi.perillo@senador.gov.br, maria.carmo@senadora.gov.br, marinasi@senado.gov.br, mario.couto@senador.gov.br, marisa.serrano@senadora.gov.br, mozarildo@senador.gov.br, neutodeconto@senador.gov.br, osmardias@senador.gov.br, gab.papaleopaes@senado.gov.br, paulo.duque@senador.gov.br, paulopaim@senador.gov.br, simon@senador.gov.br, raimundocolombo@senador.gov.br, renan.calheiros@senador.gov.br, renatoc@senador.gov.br, robertocavalcanti@senador.gov.br, romero.juca@senador.gov.br, romeu.tuma@senador.gov.br, rosalba.ciarlini@senadora.gov.br, sergio.guerra@senador.gov.br, zambiasi@senador.gov.br, serys@senadora.gov.br, tasso.jereissati@senador.gov.br, tiao.viana@senador.gov.br, valdir.raupp@senador.gov.br, valterpereira@senador.gov.br, wellington.salgado@senador.gov.br

Assunto

PROTESTO CONTRA A REGULAMENTAÇÃO DAS PROFISSÕES DE INFORMÁTICA – PLS607/2007

Texto

Prezados Senadores, venho aos senhores protestar contra o projeto de lei PLS607/2007, que busca regulamentar as profissões de informática.

A minha opinião é semelhante à de milhares de profissionais de destaque na área de Informática, e estamos todos extremamente preocupados com o futuro do mercado de Informática no Brasil. A regulamentação traria irreparáveis danos ao mercado de trabalho no Brasil, pondo em risco uma área na qual o Brasil vem conseguindo conquistar relevância mundial, e que vem melhorando as condições de vida de muitas famílias no país. O mercado de informática funciona muito bem através da auto-regulamentação, que é a prática mundial na área. Modificar a regulamentação é uma péssima idéia pelos motivos a seguir:

Competitividade no cenário global: o Brasil já tem dificuldade para competir com outros países na hora de vender TI por causa da burocracia, dos impostos e da barreira da língua. Coloque mais uma barreira para dificultar, como a regulamentação da profissão de analista de sistemas, e veja investidores começando a olhar para o Kuwait ou Polônia como opções mais lucrativas que o Brasil. Pior, começa a valer muito mais a pena para as empresas brasileiras contratarem serviços de outros países, como a Índia. A regulamentação no Brasil não vai criar e nem proteger empregos. Ela faz os empregos migrarem.

Barreira ao empreendedorismo: no Brasil já é complicado abrir um negócio, porque a lei não te ajuda, os impostos comem todo aquele capital que você preferia transformar em mais empregos. A regulamentação da informática torna as coisas ainda mais complicadas, ainda mais hoje que toda empresa precisa pelo menos um pouco de TI. Obrigado a contratar pessoas com diploma e todos os outros detalhes exigidos pelo Conselho Regional, o empreendedor se torna refém dos preços tabelados causados pela falta de mão de obra.

Barreira à inovação: Países que são pólos efervescentes de inovação em tecnologia como os Estados Unidos e a Índia não criam esse tipo de barreira e é por isso que estão aonde estão. O Vale do Silício (de onde sairam as principais e mais famosas empresas de TI do mundo) não existiria com uma lei que torna mais complicada a captação de talentos. E como uma regulamentação pode definir o que é o mínimo que um profissional deve conhecer em uma área tão dinâmica como tecnologia? Isso acaba tendo o mesmo efeito que o vestibular, em que as pessoas vão investir nesse conjunto mínimo de habilidades, ao invés de se arriscar estudando coisas que poderiam gerar muito mais valor.

Baixa oferta de mão de obra qualificada: a gente já está cansado de ouvir as notícias de que está faltando mão de obra qualificada para preencher as vagas de tecnologia em empresas. Mesmo com a crise isso é verdade, como você pode ver nos sites de ofertas de emprego. Com a regulamentação você torna o número de possíveis candidatos ainda menor. O que começa a tornar interessante terceirizar ou contratar serviços em outros países. Ou fechar as portas. Ou engolir a qualidade baixa de qualquer jeito (você não acha que ter diploma seja sinônimo de qualidade, certo?).

Incentivo à mediocridade: Em informática, uma reserva de mercado só vai servir para proteger os medíocres, os diplomados e que pagam a mensalidade do Conselho Regional em dia, mas que são profissionais de competência questionável. O Brasil possui inúmeros excelentes profissionais que não concluíram curso superior, ou o fizeram em um curso fora da área de Informática. Os bons profissionais atualmente conseguem facilmente se alocar pela meritocracia, pois o mercado é extremamente carente de bons profissionais. A auto-regulamentação do mercado separa os bons profissionais dos profissionais ruins.

Diploma como um fim: a regulamentação parte do pressuposto de que o diploma é um fim, e não um meio para que o sujeito se torne um bom profissional. Como se ao receber o diploma ele se tornasse um analista de sistemas competente. Todos que trabalham na área já conheceram profissionais com diploma que são completamente inaptos. Todos que trabalham na área já conheceram excelentes profissionais que não concluíram curso superior.

Peço humildemente aos senhores que não conhecem profundamente a área de Informática que não cometam esse enorme erro de regulamentar as profissões de Informática. Devemos buscar a competividade pro Brasil, e não outra reserva de mercado que só nos prejudicará. Vamos tomar como exemplo os países mais evoluídos na área, que têm excelente qualidade e competitividade sem regulamentação. Não à regulamentação e sim ao progresso!

Fotos

http://picasaweb.google.com.br/lucianobeserra/CursoCaelum
http://picasaweb.google.com.br/cmilfont/CursoCaelumRR11
http://picasaweb.google.com.br/handersonbf/MareDeAgilidade
http://picasaweb.google.com/maredeagilidade/SwellFortalezaMinicursos
http://picasaweb.google.com/maredeagilidade/SwellFortalezaPalestras
http://picasaweb.google.com/maredeagilidade/SwellFortalezaConfraternizacoes
http://www.manoelpimentel.com/fotos_eventos/72157622015680086/1

Twitter

http://twitter.com/#search?q=maredeagilidade

Posts

http://agiletips.blogspot.com/2009/09/big-agile-wave-in-brazil.html
http://pauloigor.blogspot.com/2009/08/mare-de-agilidade-em-fortaleza.html
http://www.natanaelpantoja.com/tech/?p=299
http://felipebviana.wordpress.com/2009/08/10/mare-de-agilidade-fortaleza/
http://ialis.wordpress.com/2009/08/09/mais-agilidade-por-aqui/
http://www.handersonfrota.com.br/triadworks-no-mare-de-agilidade/
http://www.milfont.org/tech/2009/08/05/mare-de-agilidade/
http://henriquegogo.wordpress.com/2009/08/04/mare-de-agilidade-em-fortaleza/
http://www.cearaonrails.org/2009/07/29/esta-querendo-ir-ao-mare-de-agilidade-que-tal-concorrer-a-algumas-cortesias/
http://blog.seatecnologia.com.br/2009/07/20/mare-de-agilidade-e-oxente-rails
http://iviablog.blogspot.com/2009/07/fortaleza-e-palco-para-o-evento-mare-de.html
http://www.igocoelho.com.br/2009/07/14/promocao-para-o-mare-de-agilidade/
http://www.fa7.edu.br/ypiranga/noticia/noticia.php?id=848
http://www.fernandoquadro.com.br/html/2009/07/13/evento-mare-de-agilidade-2009/
http://www.eventosdeti.com.br/2009/07/mare-de-agilidade-fortaleza/
http://www.cejug.org/pages/viewpage.action?pageId=40632324
http://leonardoeloy.com/2009/05/13/mare-de-agilidade-fortaleza/

Slides

http://www.slideshare.net/seatecnologia/manifesto-20
http://www.slideshare.net/seatecnologia/minicurso-ruby-e-rails
http://www.slideshare.net/seatecnologia/minicurso-de-testesonrails
http://www.slideshare.net/fabiokung/onde-mora-a-produtividade-do-ruby-on-rails
http://www.slideshare.net/manoelp/gesto-lean-para-o-desenvolvimento-de-softwaremanoel-pimentel-verso-30
http://www.slideshare.net/cmilfont/mare-de-agilidade-bdd-e-tdd
http://www.slideshare.net/brunopedroso/curso-xp

Videos

http://www.youtube.com/watch?v=IG7QzUjl5TM

Quando falo em testes aqui eu falo no conjunto de todos os tipos de testes, como: unitários, aceitação, integração, carga e demais necessários. A cobertura de testes é um investimento para redução de bugs na fórmula de ROI. Bugs são como “Back Order” na indústria e comércio, além de lucro perdido pela não-venda da mercadoria, ainda fragiliza a marca.

Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas não existe cobertura de 100%, então como podemos conviver com esse paradoxo?

Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.

Sabemos por consequência que testes aumentam a qualidade do software, eu não tenho tanto problema quanto antes em vender testes de software, mesmo a empresa que não tem testes automáticos, sabem da importância de se testar o software [mesmo que manual].

Meu problema atual é como conseguir vender o aumento da cobertura, mas antes disso eu mesmo preciso entender até quanto testar é suficiente para se pagar.

Power Law

Conversando dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois pontos: que o aumento de testes por mais insignificativo que seja já provoca uma redução drástica de bugs e que ao passar do tempo você tem a impressão de que os testes já não trazem mais retorno, como vocês podem ver no grafico abaixo. Vou chamar esse ponto de “Ponto de Acomodação”.

Fonte da imagem: Blog do Clavius Tales.

Comentei com o Tales que concordo que a função seja mesmo logarítmica, mas que tenho a impressão que a curva é um pouco mais acentuada e o “Ponto de Acomodação Ideal” que deveria ser o “Ponto G” no mundo real é algo entre ele e o “Ponto B” e que devemos ir mais além. No gráfico do Tales ele mostra dois pontos de acomodação, o real no Ponto B [que é um engano e as empresas devem buscar sair dessa área] e o “ideal” no ponto G, aqui tratado.

Então temos dois fatores novos, a curva mais acentuada e o ponto de acomodação, que é o ponto onde as pessoas sentem que não adianta mais testar porque o inicio de testes já reduzem significativamente o número de bugs. Esse ponto de acomodação pode ser explicado por Pareto que é algo que funciona aproximado em quase tudo na vida, dizendo que 20% de alguma coisa geralmente representa 80% do todo.

Tenho ainda um terceiro sentimento provocado pela minha experiẽncia com testes, quanto mais testes nós fazemos, mais cedo detectamos bugs e sempre há pelo menos uma inconsistência que não tinhamos “pensado” antes. Pode até ser que seja finito a quantidade de testes necessários no sistema, mas esse número é muito grande e nunca consegui alcançar na prática, sempre há bugs.

Considerando esses fatores somados, podemos usar os cálculos do Power Law ou cauda longa para melhorarmos o gráfico original do Tales de forma mais aproximado da redução de bugs com o aumento constante de testes no sistema.

Fonte da imagem: Wikipedia

Considero que a meta de cobertura de 100%, mesmo sendo irreal, é algo a ser buscado sempre, forçando o time a se policiar e aumentar o número de testes constantemente mesmo após a acentuada queda de bugs [que chamei de "Ponto de Acomodação"] e que 100% de cobertura não quer dizer livre de bugs porque a cauda sempre vai ser um número aproximado mas nunca toca o zero na prática. Esse caso se aproxima da regra de 98%.

Considero também que dependendo da necessidade de software em produção um número aceitável de bugs a partir do “Ponto de Acomodação” não trás tanto retorno de investimento a curto prazo.

Vou começar a coletar informações de dois projetos atuais para verificar se a tendência desse gráfico satisfaz a realidade. Por enquanto preciso de mais informações para chegar a conclusões melhores.