egomesbrandao, blog

Semana passada fui prestigiado com a menção do meu nome no podcast sem prestígio dos meus amigos, Elemar Jr., Leandro Daniel e Vinicius Quaiato, que cada dia ganha mais prestígio, dias atrás estava em destaque na página de downloads de podcast do iTunes: Voidpodcast ! Este episódio teve como tema “Tecnologias sem prestígio” e fui mencionado quando VB/VB.Net entrou na discussão. Mas será mesmo que esta linguagem não tem prestígio? Então, como diria o Vinicius Senger, esse post é: Pela honra do VB!

A minha história com o VB começou no início dos anos 2000, quando eu ainda trabalhava com projetos de automação predial. Cheguei a programar uma ou outra vez nessa época nas controladoras que utilizávamos porém em uma linguagem totalmente visual, que era um arrastar e soltar de blocos que representavam ventiladores, sensores, motores… Mas a maior parte do meu trabalho foi desenhando esquemas elétricos no AutoCAD, que para quem não conhece,  é o software padrão para desenhos de engenharia 2D e 3D. Com o meu amadurecimento no uso da ferramenta, comecei a sentir a necessidade de automatizar algumas coisas no meu trabalho. Acho que quando se conhece um processo tão profundamente as tarefas ficam tão monótonas que se começa a pensar em como podemos tornar essa tarefa melhor, mais rápida e melhor  ou ainda mais assertiva; e aí estava uma oportunidade escrever código dentro da ferramenta para atingir esses objetivos! Eu sempre gostei da ideia de programar, havia feito um curso de C, mas foi com ênfase em eletrônica, que era minha área na época. O AutoCAD até a versão 14 oferecia LISP, C++, e talvez outras coisas, para programar. Eu tentei estudar LISP (Lost In Stupid Parantheses), mas foi chato pra caramba. Até que na versão 2000, a Autodesk, incluiu o VBA para AutoCAD! Sim, o mesmo VBA que já estava presente no Access, Excel, Word. O VBA me permitiu não só criar macros para blocos de desenho no AutoCAD, como também acessar uma base de dados, criar Forms para entrada de dados, tudo de uma maneira muito simples, até mesmo para alguém sem conhecimentos profundos na área. Eu comecei aí, mas não parei, tive um mentor a época, Felipe Antunes (escreve o blog “E agora DBA”), que me ajudou muito em questões básicas, em entender como funcionava um banco de dados relacional, o que me fez pular do Access para o SQL Server em pouco tempo. Fiz os treinamentos oficiais do VB6, até mesmo o 1016 que envolvia coisas como MTS (na época do Windows NT) e COM+. Adotei a famosa arquitetura WinDNA. E consegui desenvolver um software que solucionava um gap entre a área comercial e a de projetos, agilizando o processo, dando confiabilidade a informação, e por aí vai. Não é preciso dizer o quanto fiquei entusiasmado com isso, já que vim para a área de TI logo em seguida.

Mas não é por conta da minha história com a linguagem que ela tem prestígio para mim e sim por causa da história da própria linguagem. Antes,  o que quer dizer prestígio? Segundo a Wikipedia: “…se referia à ilusão causada aos espectadores pelos truques de um mágico”. “(…) O termo foi usado com este sentido até século XVIII, quando em francês se começou a dar a ‘prestige’ o significado de renome, ascendência, influência, e o prestígio francês nas cortes da Europa traduziu este significado para a nossa lingua”. O uso atual “(…) descreve importância social, alta consideração e sólida reputação”.

No fim da década de 90 e início dos anos 2000 a linguagem que tinha mais influência no mercado, corporações, produtos, … era o Visual Basic, que chegou até a versão 6, trouxe um grande poder ao desenvolvedor, no sentido de tornar simples o desenvolvimento, fazer um acesso a base de dados relacional, criar uma tela gráfica, acessar a API do Windows, desenvolver uma aplicação distribuída, tinha ficado muito mais simples. Em 2005 62% dos programadores usavam uma forma de Visual Basic (Wikipedia), já que nessa época já estavamos entrando na versão 2.0 do VB.Net, mas até hoje o Visual Basic 6 é utilizado em produção, em projetos, até mesmo alguns novos projetos são desenvolvidos com ele! Talvez atualmente o Visual Basic 6 não seja a melhor opção para desenvolver um projeto, mas no início dos anos 2000 era uma das melhores opções, Java ainda era extremamente lento e complexo, de se programar, de se criar um ambiente, o Delphi apesar de prático exigia um pouco mais. O VB dava poder para quem estava começando, dava agilidade. Mas com todo esse poder também vinha uma grande responsabilidade, que era ignorada.  Com a mesma simplicidade que se desenvolvia no VB,  se criava uma grande dívida técnica! Infelizmente o descontrole dos projetos, de arquitetura, de boas práticas não é culpa da linguagem. Não podemos culpar armas, carros, aviões por matar pessoas! Os próprios desenvolvedores foram os culpados por toda essa quantidade de brownfield que se criou na plataforma. E que não venham dizer que foram forçados a isso, que a gerência mandou. Ninguém faz o que não quer!

Por fim, o VB.Net resolve o problema do cliente, que é o objetivo com que qualquer linguagem é criada, fora linguagens teóricas. E isso que é importante, juntamente com o cuidado de se escrever um código limpo.

Assisti  poucas palestras, mas praticamente todas que eu vi eu gostei. Eu sei que todos deixaram de trabalhar um pouco ou de se divertir. Dedicaram algumas horas para formatar um conteúdo de alto valor e  em contra partida a entrada é de um baixíssimo valor monetário! As empresas deveriam olhar com mais atenção para este tipo de evento, deixar um funcionário participar não vai dar problema no projeto ou pagar a entrada para todo mundo não vai causar problema no fluxo de caixa. O conteúdo vai se pagar. Ao mesmo tempo que pessoas tiveram que fugir de seus trabalhos para poder comparecer, teve uma empresa que contratou um ônibus para levar vários funcionários no evento, muito legal isso!
Assisti palestras muito boas, que me deram novas idéias, que me inspiraram em algumas soluções, a da Yara (@yarasenger) e Vinícius Senger (@vsenger) de como foi abrir a Global Code, novidades como o novo Windows Phone 7 (apresentada em um Mac Book) pelo Vinícius Quaiato (@vquaiato), um manifesto contra métricas absurdas e micro gerenciamento do Giovanni Bassi (@giovannibassi), escovação de bit em Intermediate Language (IL) do .Net, com vários participantes de Java, feita com propriedade pelo Elemar Jr. (@elemarjr), implantação de ALM em uma semana do Vinícius Senger só com ferramentas open source, Continuos Deployment com a Fabiane Nardon (@fabianenardon), lightning talk do Leandro Daniel (@leandronet) sobre Arquitetura evolucionária, e outras mais ou pelo menos pedaços!

Minha palestra

Comunidades

Devido à grande variedade de linguagens, tecnologias e assuntos a variedade de pessoas com quem era possível conversar é marcante nesse evento! Você pode tomar um café com o pessoal de Java ou almoçar com a galera da comunidade de NoSQL. Ser abordado por um dono de empresa a procura de desenvolvedores PHP. Mas um evento de várias comunidades como esse não seria completo se ao menos uma vez rolasse uma discussão (muito saudável, lógico) de rixa entre plataformas. No fim o pessoal acabou indo tirar a prova no código, fomos recebidos no stand da Crafters Studio e SOA|Expert, e o Elemar Jr. topou o desafio de implementar um código em .Net, ali na hora, com vários “PO’s” apontando o que deveria ser feito, opinando, criticando, apesar de a galera ser de outra plataforma; como sempre ele na postura de professor respondeu todas e deixou pessoas de outra plataforma surpresas com os recursos do C#/.Net. No dia seguinte foi a vez do Felipe Rodrigues (@felipero) topar um desafio, criar na hora um aplicativo em Ruby On Rails acessando o MongoDB através do framework MongoID, e lógico detalhando os por quês enquanto codava.

HH, ou Happy Hour

Como não poderia deixar de acontecer todo dia teve HH! Então depois do encerramento diário às 19 horas do evento… o evento continuava em um HH, até 23, 24, … e mais tarde! Muito mais troca de conhecimento e idéias, mas também lugar para diversão. A honra do Clipper, COBOL, DBase, Joinner, VB, Progress, DOS, Norton Command… foi bravamente defendida várias vezes! O saudosismo rolou solto, foi combinado um evento nostálgico, até mesmo montar uma BBS! Até mesmo aniversários foram comemorados lá!

Mais um evento, mais um ano. O TDC ainda tem muito para melhorar, o que é ótimo, por que ano que vem não sabemos o que esperar, a não ser a certeza de que será melhor que este último! Parabéns à organização.

Links:

• Fotos oficiais do primeiro dia
• Minha apresentação

Algumas frases que publiquei semana passada no twitter fizeram algum sucesso. A  idéia veio de vários lugares: juntei com o que ouvi de alguém, com aquele velho e-mail sobre a carreira Y, entre outros episódios da nossa área; mas o problema é real e se chama: Síndrome do Programador Herói (SPH). Provavelmente todos da área de TI com alguns anos de carreira já viram alguém ser acometido pela SPH, alguns são afetados pelo resto da vida, enquantos outros conseguem se libertar ou serem libertos por alguém que lhes dê um chacoalhão. Acontece é que o desenvolvimento de software é um dos segmentos de trabalho mais propícios para adquirir essa síndrome.

A maneira mais fácil de contrair SPH é o programador participar de vários projetos de sucesso, principalmente se ele buscar os desafios, e todos darem extremamente certo! OK, sabemos que todo projeto tem seus problemas, mas muitas vezes os executivos não enxergam esses “problemas”. Para eles é apenas um programador que não consegue chegar no horário, um outro que não tem certificação; mas sempre tem aquele cara que gosta de matar no peito, por mais que isso vá arder no dia seguinte, ele quer comprar latinhas de energético e virar a noite na empresa, lógico que depois de pedir aquela pizza, e codar, codar, codar. O trabalho é gerar linhas de código, centenas delas, talvez milhares; ele vai ser o cara que vai carregar o projeto, o cara que vai dar o sangue… E por aí vai. Esse cara é cumprimentado pelo gerente, vai almoçar com ele, alguns colegas querem ser como ele, “o cara que coda pra baralho”, “o cara ali é o único que sabe como funciona essa regra de negócio”, “ele que sabe como esse framework funciona”.

Apesar da gerência adorar e,  talvez a sua existência seja devido ao modelo capitalista, ainda mais em contratações acordadas por valor/hora, esse tipo de profissional deve ser evitado! A qualquer custo. Parece loucura não apoiar um profissional que dê o sangue pela empresa, mas não é, essa é a atitude mais saudável que alguém poderia tomar em um projeto. O projeto deve ser feito pelo time, o mérito da execução deve ser do time, os bugs são criados pelo time; é muito fácil verificar se isso ocorre, é quando se ouve “nós falhamos na implementação de determinada tarefa”, “nós conseguimos fazer um refactoring e melhorar o código para a implementação de determinada funcionalidade acontecer”, “nós automatizamos os testes de integração”, “nós não vamos conseguir completar as tarefas a tempo para lançar essa release na data pré-determinada”.

Quando o time funciona de maneira homogênea o conhecimento técnico ou de negócio é passado para todos, todos irão saber como agir quando algo der problema, todos vão assumir os problemas, todos vão cooperar.

As frases:

• “programador ninja = programador mercenário, q usa práticas não ortodoxas, sabotagem, espionagem… veja def.: http://ht.ly/5ejDE”
• “programador jedi = trabalha com ficção, projetos q de uma galáxia muito distante da nossa, único empregador: LucasArts.Com”
• “programador highlander = vai detonar todos os seus colegas, única maneira de sobreviver no projeto… afinal: só pode haver um!!”
• “programador Daileon = resolve o seu problema mas devasta todo o ambiente…”
• “programador AstroBoy = é bonitinho… mas vc não quer um brinquedo de crianças cuidando do sistema crítico da sua emrpesa…”

O pessoal também criou algumas:

• @wjat777 Ninja: vem armado até os dentes (varias ferramentas), pode até resolver o problema, mas (cont.)
• @wjat777 mas tem a capacidade de desaparecer se a situaçao pioara.. normalmente cobra caro!
• @alistonCarlos Programador Power Ranger: junta com mais quatro pra fazer uma bazuca que mata até formiga!
• @marcelotozzi e o rockstar?
  • Aí vai Marcelo: “tem twitter e fica falando sobre um monte de coisas e escreve um blog sobre assuntos diversos, até mesmo sobre programação, falando como deve ser a coisa”  … #bazinga, ok?

Eu tomo café da manhã na padaria: um suco de laranja e um croissant. Como vou sempre na mesma,  o atendente já me conhece, mas quando ele começou lá foi a mesma coisa do anterior, ele me servia o croissant, servia o suco e ia pegar um canudo, que eu sempre recusava (questões ambientais)… Se você pede um suco sempre colocam um canudo, mas se você pede um refrigerante, um chocolate quente, uma água com gás, uma cerveja… não colocam! Por quê? O copo é o mesmo. Acho que quando inventaram o canudo era para você conseguir beber um líquido de um lugar do tipo uma garrafa, ou até mesmo acho que era para crianças. Não tem  sentido servir um suco com canudo e um refrigerante sem!
No desenvolvimento de software é a mesma coisa. Não usamos canudo, mas já perceberam como fazemos coisa que não sabemos por quê? Alguém fez a primeira vez, talvez para resolver um problema específico, e outro copiou, depois outro… E de repente está todo mundo fazendo, e ninguém sabe por quê.
Por quê se usa Dataset’s? Além do fato de vários livros de .Net básicos ensinarem e o pessoal parar de estudar no básico ou intermediário, se você perguntar para algum desenvolvedor o motivo que o levou a usar Dataset ele não vai saber explicar. Teve alguma vantagem? Ele não vai saber. É mais rápido? Ele não vai saber.
Por quê usamos Try…Catch? Muitos desenvolvedores não vão saber explicar! Aliás, muitos não sabem nem mesmo usar! Ou alguém nunca viu um método FazTudo com um Try…Catch abrangendo um código gigantesco?
Por quê ainda usamos ADO.Net puro quando temos outras maneiras melhores de acessar um banco de dados? Por quê programamos estruturado em uma linguagem orientada a objetos?
Meu pai fala uma frase: “O ser humano é um animal acostumado a hábitos”.
Nós simplesmente acostumamos a fazer alguma coisa e isso vira um processo, sempre se repetindo, sem espaço para inovação, criatividade, pensar fora da caixa. E a sociedade, a vida cotidiana, força-nos mais ainda a manter esse hábito de repetição (olha a recurividade aí, hábitos já são repetitivos).
Os estudantes não são ensinados a pensar e sim a repetir, a decorar, desde os primeiros anos. Não são forçados a questionar, a verificar, a pesquisar, a tentar entender e quem sabe no futuro entender esse conhecimento sozinho. Anos atrás por conta da pobreza dos editores das linguagens de programação e também por causa da fraca tipagem era uma questão de bom senso usar um prefixo com o tipo da variável.

<br />
float fValorTotal;<br />
int iQuantidade;<br />

Mas era algo totalmente justificável, pois você não tinha algo como o Intellisense do VS.Net, você podia atribuir um valor decimal para uma variável declarada como inteira, e por aí vai. Mas e hoje, por quê ainda se usa esse prefixo? E por quê ele é ensinado em muitos lugares? Não tem o menor sentido. E os alunos habituados a anos a decorar sem questionar não conseguem perceber que sem o prefixo o código compila da mesma maneira.
Por quê ao ensinar o paradigma de orientação a objetos não deixamos de codar estruturado? Temos ainda o paradigma funcional, dinâmico, … Mas essa distinção não é clara para recém formados ou participantes de cursos de programação. Por que até hoje se ensina OO como se fosse uma evolução do estruturado, o que nunca foi uma verdade.
Hoje os bancos usam programação estruturada, indústrias com seus softwares MRP também, esse tipo de linguagem não vai sumir, ela tem o seu uso, e o OO não é o futuro dela.
Manter a mente aberta para o aprendizado é algo extremamente difícil, questionar processos, discutir teorias, é complicado, pois somos avessos a mudanças. Albert Einstein, disse: “A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original”. E é assim que deveríamos agir em todos os momentos da nossa vida, e precisamos de pessoas que queiram experimentar, criar, aprender e evoluir principalmente na área de software. Quem sabe assim termos mais qualidade, seremos mais econômicos, mais rápidos e assertivos. Só depende de quem faz.

Outro dia saiu uma pergunta numa lista de discussão, sobre o que era melhor usar, For, foreach ou ainda ForEach?

Histórinha do ForEach: Depois dos Generics, disponibilizado no framework 2.0, se tornou comum o uso de listas tipadas, muito melhores que o uso de Arrays de Objects! Também foi introduzido os tipos anônimos, expressões Lambda. Em seguida na versão 3.5 do framework foi introduzido o Linq, mudando a forma como são manipuladas coleções de objetos.

Se é necessário somar o valor dos itens de uma nota fiscal o modo “old school” é:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

foreach (Item item in itens)
{
 valorTotal += item.Valor;
}

Ou você pode fazer:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

itens.ForEach(item => valorTotal += item.Valor);

Mas fora a diferença de sintaxe, existe alguma outra? Performance? E o que é esse método ForEach?

ForEach é um método que recebe como parâmetro um delegate Action<T>, ou seja ele recebe uma função a ser executada, nesse caso será executado um foreach!! Sem emoção aqui, mas o legal é que percorrer uma coleção fazendo alguma alteração em seus itens agora requer apenas uma linha.

Mas não é só isso! Voltando a nossa questão de performance o ForEach é mais otimizado sim, eu ia fazer um pequeno projeto de teste mas… achei um post falando justamente sobre isso, então para reaproveitar código quem quiser testar é só usar o projeto que foi disponibilizado pelo Dustin Russell Campbell aqui neste post. A comparação é bem completa, usando vários tipos de interação (For, foreach, ForEach), e o ForEach ganha! Somente quando o código esta usando otimização na compilação com uma coleção pequena a velocidade se equipara, mas a medida que a quantidade de itens aumenta ele é mais rápido que outros métodos.

A quem não goste

Encontrei também comentários de pessoas que não gostam dessa abordagem, dizendo que ela não adiciona poder representativo a linguagem, o exemplo dado no link é bem simples então o autor tem razão. Porém minha opinião é que o código fica muito mais legível, tornando a leitura mais fluída.

Anos atrás uma onda de terceirização foi iniciada em vários segmentos da economia, indústria, serviços; delegando para terceiros a fabricação de partes de  componentes , a montagem de um equipamento, até mesmo sua completa fabricação. No setor de serviços sub-contratando mão de obra, ou empresas inteiras para prestação de algum serviço, limpeza e segurança são os exemplos clássicos, além do telemarketing e  serviço de atendimento ao consumidor, que foi chamado de chão de fábrica do século XX. O objetivo principal: redução de custos! Enquanto a inteligência do negócio, criação, comercialização, continuava com a empresa, atividades de menor valor eram terceirizadas. Em nenhum outro segmento como na TI foi e é tão visível, e isso não funciona. Nunca funcionará.

Surgiram então as fábricas de software, muito bem descrito no artigo do Akita, Fábrica de Software é uma Besteira , como: “O maior desserviço à área de Desenvolvimento de Software já criado na nossa história recente foi o termo ‘Fábrica de Software’”. No qual existe até uma concordância com outro texto meu, Arquitetos não existem, em que eu coloco que a construção do software é trabalho do compilador, o desenvolvedor faz o projeto dele. Engraçado que,  apesar de saber da existência deste texto do Akita, eu ainda não havia lido.

Já que a  questão da fábrica de software já foi discutida, quero colocar outro problema em evidência:  o body shop, outsourcing; que é feito por várias empresas que alocam profissionais para trabalhar nos seus clientes. O objetivo é sempre o mesmo, redução da carga tributária; a falta da necessidade de manter indefinidamente a estrutura com esses profissionais, enxugando assim a quantidade de funcionários propriamente dita. Mas chega um determinado ponto que esse modelo falha.  Acontece que esses profissionais não estão comprometidos com a empresa em que estão alocados, ou seja, não vão se comprometer com o seu trabalho, com o projeto ou com o produto. Ele não está comprometido com a continuidade. No primeiro sinal de perigo ele pula fora. Afinal quando uma empresa decide fazer cortes ela começa por aí, já que não terá o ônus trabalhista,  só precisando  cancelar um contrato. Uma proposta um pouco maior também faz esse profissional sair e, uma vez que  a visibilidade dele para a empresa em que está alocada e para a sua empresa as vezes é pequena, será difícil ele conseguir uma valorização financeira maior sobre o trabalho que está executando.

Esse profissional está por conta própria. Com perspectivas de crescimento pequenas, de valorização ainda menores, ele se encontra em uma posição desfavorável e ninguém gosta de estar assim. Por conta disso,  diversos profissionais encontram-se estagnados, já que não tem motivação para ir além de sua capacidade. Dessa forma, executam um trabalho diário braçal e mecânico, sem melhorar sua técnica, trazer mais valor para o seu trabalho. Muitas vezes ele é hostilizado por funcionários da empresa em que se encontra alocado, tratam-no apenas como recurso no processo, proveniente de um contrato de prestação de serviço. Com certeza algum leitor está pensando que não é verdade que todo profissional não contribua, que não invista, que não melhore seu trabalho. Sim vários se importam, por que eles entendem que não são só as empresas envolvidas em um projeto mal feito que serão penalizadas, seu nome também esta em jogo. Mas mesmo esses profissionais são desestimulados com o passar do tempo.

Pessoas não são recursos. Elas determinam o sucesso e o fracasso de um projeto, e não as máquinas usadas, a linguagem, a internet. A desvalorização e, consequente, a  desmotivação de uma pessoa afeta diretamente o sucesso de um projeto no qual são horas perdidas de conhecimento, pesquisa, e por aí vai.

Mas então,  qual seria a solução? Empresas fortes em desenvolver sistemas para os seus clientes e não apenas em fornecer mão de obra. Empresas que pesquisem, armazenem esse conhecimento, mantenham profissionais e vendam soluções,  e não horas. Empresas de TI que sejam do negócio de TI e não apenas RH especializados em TI. Empresas assim,  ganham mais, pagam mais e contribuem com a economia do país. Essa empresas teriam foco, da mesma maneira que os clientes que ela atenderia  têm foco, que não é a TI.

Chego na empresa, ligo minha máquina e,  enquanto isso, pego um café, duplo. A injeção de cafeína vai ajudar a começar o dia. A equipe de interface gráfica no nordeste espera a conclusão do web service para finalizar o trabalho que eles deveriam ter feito no fim de semana. Sim, no fim de semana! O projeto atrasou, a equipe de marketing resolveu adicionar mais uma funcionalidade, além daquela outra adicionada na semana passada, e agora estamos atrasados… Bom, estamos atrasados  já tem… Um mês. Eu fico puto com isso, prefiro ter um filho veado que um filho cliente!
O VS.Net abre, sincronizo o código, trabalhei nele até as 22:00 da sexta-feira passada, mas vai saber se alguém mexeu em alguma coisa. No fim de semana pensando no meu problema, as idéias se encaixaram e guardei a solução. Tarefa simples, porém braçal, tudo o que é preciso para iniciar uma segunda-feira sem pensar muito, só codar. Vou alterar o código é… Meu, quem foi que fez check-out exclusivo nessa classe? Ah! O cara que está  atrasado… Fico puto com isso! Prefiro ter um filho veado que um filho programador que faz isso… Aliás, prefiro ter um filho veado que um filho que configura o TFS com check-out exclusivo.
OK, vamos adiante, preparar os dados que serão enviados para a UI. Não é complicado, dados cadastrais, interface móbile… Caramba, um saco de dados vem desse web service, o que vai deve estar definido na especificação… Que especificação? A única coisa parecida com uma é um e-mail em tom imperativo dizendo: implemente nova função, blá, blá, blá; nada que ajude realmente. Fico puto com isso, será que não é possível descrever direito a necessidade? Prefiro ter um filho veado que um filho gerente de produto.
Já são 10:45 da manhã, em quinze minutos reunião com arquiteto sobre o outro projeto que deveria ter começado, e começou;  é isso que diz o cronograma, mas esta em paralelo por causa desse. Meu, preciso dizer que preferia ter um filho veado que um filho gerente de projetos? Pausa pro café, antes da reunião.
O arquiteto chega, atrasado. Caramba, o que esses caras fazem? Reunião marcada pela exigência do processo, que a arquitetura seja envolvida no início para o levantamento de necessidades dos serviços disponíves. O arquiteto me pede pra levantar os dados, fazer uma planilha, buscar os serviços disponíveis, para que ele possa aprovar! Parece  que eles são aquelas crianças chatas que os amiguinhos não querem brincar junto e daí os pais criam regras para isso. Pô, prefiro ter um filho veado que um filho arquiteto corporativo! Se eu soubesse onde estão os serviços eu não teria marcado a reunião, ao invés do cara colaborar,  o cara quer burocratizar.
Hora do almoço. Aproveito para ler e-mails pessoais, dar uma navegada, já que nos acham incapazes de controlar o tempo de acesso a internet e por isso ela é bloqueada o dia todo, lógico é necessário controlar a produtividade, a atenção… Bom, o UOL e o Terra estão liberados o dia todo! Vai entender… Meu, prefiro ter um filho veado que um filho admin de rede.
Na fila do almoço o de sempre, aquela mulher que fica escolhendo a folha de alface, o pedaço de batata, põe uma, duas, três, quatro colheres muito pequenas de arroz… escolhe o pedaço do frango, lógico que ela  está batendo papo com a amiga na fila da frente, atrasando as duas, criando uma fila enorme. Nem vou falar nada…
Volto pro escritório, pego café, e vou fazer um teste do WS, rodo o código, … erro! O WS chama outro que está  com pau… Ligo pro dev, pergunto pra ele, e a resposta é “testei na minha máquina e mandei pro ambiente de homologação, mas não testei lá”, meu… calma… Verifico o ambiente e vejo que ele esqueceu de subir os arquivos XML de configuração. Abro chamado para o suporte, solicito inclusão dos arquivos… Espero. Recebo e-mail de OK. Novo teste, rodo… Erro! Meu… “Login inválido do banco de dados”… OK… Peço o arquivo Web.config de homologação, não mudaram o endereço do servidor do BD! OK… Mudando… Novo chamado, nova inclusão, mais uma espera… E-mais de OK… Teste… Executo… Erro! ERRO!! Não é possível. Análise do Web.config, o cara de suporte subiu o meu arquivo, com a senha em branco… Cara, prefiro ter um filho veado que um filho analista de suporte!! Alterações feitas, testadas, ambiente OK, e-mail para equipe da UI, … É só esperar confirmação. Enquanto isso,  é ler um pouco.
Recebo e-mail de que o meu WS está  com erro… Não é possível… Nada de errado! Pego o arquivo XML no log, … Pô, dois cabeçalhos “<?xml version=’1.0′ (…)”, como que o cara quer que funcione? Não, nem vou comentar.

Se você está  rindo disso… Ainda vai acontecer com você. Provavelmente amanhã…

Texto inspirado em um quadro do Terça Insana.

Ou o contrário… eu explico.

Anos atrás,  quando comecei a me envolver mais com arquitetura de sistemas, quando procurei por “coisas que me ajudassem a desenvolver melhor o meu trabalho (tudo começou por que eu achava que deveria existir uma maneira melhor de fazer acesso a dados do que com Dataset’s, mas isso é outra história), eu me deparei com Padrões de design, DDD, e por aí vai; Nessa época o Giovanni Bassi também estava procurando pessoas para discutir arquitetura, e assim que me deparei com o .Net Architects. Passei por uma grande empresa de software no Brasil e lá existia cargo de arquiteto, de arquiteto corporativo, este último trabalhando com a diretoria. Mas conhecendo mais sobre arquitetura, com as discussões no #DNA comecei a pensar que, na verdade, o arquiteto era um papel exercido por um desenvolvedor dentro do processo de desenvolvimento de software, e não um cargo ocupado por alguém pensando somente em arquitetura conceitualmente, mas  sim “codando” junto com o time de desenvolvimento, pelo menos em uma parte significativa do tempo e em PoC’s, ou em partes específicas. Afinal, se o arquiteto não vive a codificação, como ele garante que a arquitetura que ele pensou inicialmente está aderente ou ainda,  que está mais ajudando do que atrapalhando? Sim, por que se a arquitetura é a estrutura na qual será construído um software ela tem que ajudar a codificar, se está atrapalhando, é melhor fazer sem. Ou seja, ninguém deveria ser contratado para ser arquiteto e sim, deveria exercer o papel de arquiteto durante um projeto, ou em uma equipe de um produto específico. Da mesma maneira que podemos estar no papel de tester, ou focado em desenvolvimento de interface (papel de dev de UX), etc…

Para que o arquiteto consiga desenvolver uma arquitetura, o que ele precisa? Conhecimento, experiência; ou não, se o cara é inteligente e cresce com PBL, qual o problema? Existem os skills que não são técnicos, comunicação, habilidade social (afinal ele precisa conviver com o time e não achar que esta acima de tudo isso). E ninguém tem dúvida que ele deve conhecer Design Patterns, frameworks, build, Testes e por aí vai. Mas espera, isso não seria tudo o que um desenvolvedor deveria conhecer? Design Patterns, codificação, framework’s, melhores soluções, tendências, Testes, Build, sem isso um dev não vai desenvolver.

- “Ah! Um dev desenvolve software, ele constrói software, já um arquiteto cria arquitetura, a base, ou um projeto… Não é a mesma coisa.” Será? Um dev realmente constrói software? Vamos fazer um paralelo? Vamos pegar outro segmento de mercado, uma indústria, uma construtora civil… Para se produzir um carro, para se construir uma ponte, é necessário um projeto, existem pessoas com diferentes habilidades lá, nem todas conseguem imaginar um carro ou os detalhes de uma ponte e nem todas conseguem instalar vidros nas portas ou pilares. Então os que não conseguem imaginar os detalhes de construção são dirigidos por um plano, ou um projeto, que é elaborado por pessoas que conseguem visualizar todos esses detalhes. Então arquitetos, engenheiros mecânicos produzem um projeto que serve de guia para operários construirem a ponte ou o carro. Os arquitetos e engenheiros tem uma visão abrangente, mesmo se só desenvolverem um pedaço desse projeto, esse pedaço é abrangente, pois é composto por diversos detalhes. O operário tem uma visão de processo de construção, seguindo o plano. Às vezes dentro desse processo ele consegue sugerir melhorias, novas idéias, mas dentro desse processo.

Voltando ao desenvolvimento de software… O desenvolvedor constrói software? Ele empilha os bits em código de máquina? Ele “builda” o código de máquina? Não! Um desenvolvedor de software constrói um projeto do que ele quer que seja o software, daí ele aperta F5 e envia uma mensagem para o Compilador dizendo “construa um código de máquina baseado nesse projeto aqui, nesse código”. Se o desenvolvedor é quem projeta ele é um arquiteto/engenheiro de software, pois ele exerce as características que definimos como a de um arquiteto. Ele não é simplesmente um operário que segue um projeto, que segue um plano, um processo. Ele pensa, elabora, planeja e PRECISA conhecer tudo aquilo escrito lá em cima: Design Patterns, ORM, Banco de dados, SOA, linguagens de programação, código, frameworks, protocolos, API’s, UX, etc… etc… Um desenvolvedor que apenas sabe usar IF…ELSE, FOR…EACH, SWITCH, simplemente não estudou o suficiente, é iniciante, ou esta enganando alguém. E ainda não leu “Clean Code”.

Se todos os dev’s se comportarem com o que esperamos hoje de um arquiteto eles serão realmente responsáveis pelo código que estão gerando, já que a arquitetura será dele também, já que ele vai ter que estudar, e muito, para aprender tudo isso. Ele também vai aumentar a visão que tem do projeto, poderá ver coisas que não estava entendendo e que contribuíram para um desenvolvimento mais pobre que ele tenha feito. É óbvio que um desenvolvedor que acabou de iniciar na profissão não terá conhecimento e experiência suficiente para codar sozinho definindo frameworks, arquitetura, mas com o auxílio de um outro dev mais experiente ele irá adquirir essa bagagem.

Então desenvolvedor,  pense como um arquiteto, seja um arquiteto! O projeto/código é seu!

Se você é responsável por alguma área de TI, coordenador, gerente, diretor e tem uma pequena verba sobrando,  que tal torrar? Afinal,  se você não gasta toda a sua verba, no ano que vem vão diminuí-la, certo? O problema é que não pode dar na cara, se você simplesmente torrar essa grana em um happy hour com a equipe, comprar cadeiras melhores ou um segundo monitor para cada desenvolvedor, isso pode levantar suspeitas e te acusarem de não saber controlar sua verba. Então seguem abaixo algumas sugestões. Espero que lhe ajude na ascenção de sua carreira! Se você for promovido, deixe seu depoimentos nos comentários. Segue abaixo o manual: Como torrar sua verba de TI de maneira “responsável”:

Atualize os seus softwares

Caro e não palpável:  a compra de software é uma maneira de você gastar e ninguém ver onde. Você pode comprar várias e várias licenças, hoje em dia não vem nem mais a caixinha que ocupava espaço, e gastar muito dinheiro com isso. Para gastar bem gaste com a moda, compre ALM! Várias licenças de Team Foundation vão custar uma bela grana e simplesmente não use-as. Pelo menos não totalmente, para não dar na cara, use somente o controle de versão, todas as outras funcionalidades podem ser esquecidas, não precisa usar o build automático, tracking, etc…
Ganhe um Bônus adquirindo o VS.Net Ultimate e não treine os desenvolvedores para usar as facilidades que ele oferece, aliás… o TFS não vai estar funcionando mesmo.

Contrate um gerente de projetos

Aqui é “double damage”! Além de gastar dinheiro com um profissional para tomar conta de outros, os desenvolvedores, no caso, pois eles não tem a menor idéia do que fazer, precisam de uma babá e às vezes trabalhar na base do chicote; esse integrante do time vai reagir de forma contrária ao time, vai introduzir ruído, marcar extensas reuniões, vai sentar ao lado de um dev para ver o que está acontecendo e ajudar no código; ou seja, vai atrasar seu projeto ou piorar as manutenções de software. Traduzindo:  mais tempo, que é mais dinheiro, mais gastos. Se você além de double quer um bônus com essa aquisição, peça um que seja PMP, certificado claro, pois a hora é mais cara e ele vai trazer um livros de regras junto para aplicar no seu processo.

Processo

Se você não tiver um processo você já tem muito gasto, atrasos, comunicação falha, e por aí vai. Mas, instalando um processo você pode gastar ainda mais!! Vá para o mercado, procure profissionais gabaritados em processos, e peça uma avaliação, afinal você quer ter mais visibilidade do projeto, ter certeza que estão fazendo a coisa certa e quer controlar se a galera esta indo pro banheiro dormir no vaso depois de uma noite de balada na terça-feira, e para isso terá que gastar mais. Planilhas de horas, ou um software, documentação abrangente, validações, reuniões de planejamento, análise do problema; tudo isso deve estar contemplado no processo. Ganhe bônus instalando uma ferramenta de controle do processo.
Já tem um processo na empresa? Então mude! Escolha um da moda e obrigue sua adoção, lembre-se de contratar um consultor para isso! A mudança do projeto deve ocorrer durante o projeto em andamento e não se preocupe, coloque tudo o que puder, as pessoas devem se adaptar,  e não o contrário.

Contrate pessoas

Se você acha que ainda esta gastando pouco,  nada é mais caro do que a contratação de pessoas. Principalmente pessoas que não estão comprometidas com a empresa, portanto abuse dos terceiros, eles podem te dar um bônus em gastos se você contratá-los com “horas abertas”. A contratação de mais pessoas vai prejudicar sua comunicação no projeto e provavelmente vai dobrar seu tempo de desenvolvimento, isso mesmo, vai dobrar! Se isso não é custo suficiente,  peça certificados; os profissionais com certificação vão lhe garantir um gasto extra, já que como pessoas com mais conhecimento vão te cobrar mais.

Se você não tem uma verba sobrando… Mantenha seu ambiente com um clima péssimo, infra-estrutura ruim, máquinas velhas, isso fará com que as pessoas não queiram trabalhar, logo elas vão produzir pouco ou nada e o projeto vai atrasar. Algumas vão se demitir então poderá contratar novos, mais alinhadas com as diretrizes da empresa. Depois poderá pedir mais verba para consertar o andamento do projeto… Volte ao início e aplique as propostas apresentadas.

Se você é desenvolvedor e leu esse texto… bazinga!

Hoje o Manifesto Ágil completa 10 anos. Nesse tempo muita coisa mudou, evoluiu, ou não!

10 anos na indútria da TI é muito tempo. Muita tecnologia nasceu e outras tantas morreram, muitos aplicativos foram desenvolvidos, alguns de sucesso incrível outros nem tanto, e outros que pareciam não deixar de existir,  nunca foram engolidos por inovações. Mas, desenvolver software ainda é uma incógnita para muitos do mercado.
Pode ser muito tempo para a TI, mas, historicamente falando, 10 anos é pouco tempo para analisarmos grandes mudanças.

Fazer software ainda é para muitas empresas sofrível! E é curiosa essa afirmação, pois em um segmento em que mudanças acontecem da noite para o dia, novas tecnologias são desenvolvidas frequentemente, elas não são absorvidas pela própria indústria que as cria. É como se as empresas de telefonia não fizessem uso do telefones para se comunicar.

O manifesto ágil focou em pessoas, interação, mudanças e colaboração. Mas poucas foram as empresas que conseguiram absorver esses conceitos. Por que? Muito antes do manifesto, Ricardo Semler mudou a cultura da sua empresa, a Semco. Quando a TI nem falava de trabalho remoto (famoso Home Office), colaboração entre indivíduos, ambiente de trabalho… A Semco já mudava essas formas antiquadas de pensar. Não foi fácil, mas se operários de fábrica conseguiram ter flexibilidade no horário de trabalho, por que profissionais que não estão presos a uma linha de produção ainda não conseguiram?

Os ambientes colaborativos na internet 2.0 aparecem aos montes, são ferramentas de redes sociais, aplicativos profissionais, até mesmo CRM já tem internamente sua rede social (veja o Salesforce Chatter), mas todas essas facilidades a um click de distância de qualquer indivíduo com acesso a grande rede são barrados por firewalls de empresas preocupadas com produtividade. Essas mesmas empresas são aquelas que minam a produtividade de seus funcionários proporcionando um ambiente tão ruim de trabalho que é desanimador querer resolver algum problema. Veja o vídeo do Jason Fried da 37Signals no TED (Why work doesn’t happen at work).

O ágil esta na moda hoje! É legal a empresa ser ágil, só pela palavra já é legal, ter um framework do tipo Scrum, esse então todo mundo parece usar, mas realmente fazer uso, difícil… O Giovanni Bassi da Lambda3 recentemente escreveu um post com o título Que fique claro: não se “instala” agile, diferentemente do que pensam muitos “gerentes” por aí, que acham que é só chamar um “consultor”, fazer 3 dias de cursinho, e bora usar o Scrum.

Infelizmente a mudança cultural defendida pelo movimento ágil vai demorar a acontecer em muitos lugares, pois a cultura da falta de colaboração entre indivíduos, falta de valoriazação do trabalho, más práticas, é a realidade de muitas empresas, e pior, educaram vários indivíduos assim… Deseducar será um longo processo para elas. Quem hoje consegue se livrar de toda essa carga cultural negativa vai surfar a onda.