Um post no estilo “remoendo coisas que passam pela minha cabeça”. À medida em que continuarem passando, aumento a FAQ.

1. Por que se fala mais de processos e ferramentas do que de indivíduos e interações? O item 1 do manifesto agile não me parece tão professado quando se observa a quantidade de informação dedicada a sistematizar — isto é, pôr em um processo — as alternativas agile. É da natureza do engenheiro colocar tudo em um diagrama?

2. Por que tanta gente (incluindo eu) prefere reclamar do emprego ao invés de arrumar coisa melhor para fazer? Parece haver uma terra prometida onde os projetos não atrasam, os clientes estão sorrindo, os chefes têm bom senso e os salários são muito bons. Lá você vai trabalhar quatro dias por semana e tem um andar com mesas de sinuca. Você acha que merece trabalhar lá, mas se conforma com “a situação”, que “é assim mesmo”, e ainda cobra pouco por isso.

3. Como metodologisificar* os projetos concebidos em erro? Imagine o seguinte: o cliente precisa cumprir uma meta, não vai conseguir e convenceu você a levar a culpa tocar o projeto. Não foi difícil te convencer, pois você precisa da fatura. Qual metodologia vai te salvar? Em casos assim, é sempre erro de negociação ou o projeto pode ser metodologizado* direito?

*Dá pra sentir o quanto eu gosto da palavra metodologia

1. Por que é tão difícil segurar gente boa na equipe? Provavelmente o seu talentoso colega vai trabalhar num lugar que oferece praticamente as mesmas CNTP para a proliferação de programadores medíocres: projetos mal geridos, chefes acomodados, clientes insanos e café ruim. Tudo por 1 ou 2 reais a mais à hora. Por que tantas empresas insistem em tratar programador como commodity? (Os signatários do blog já viram pessoas sendo pagas para dizer isso.)

2. Por que é tão difícil mandar os incompetentes embora? Qualquer pessoa que faça a mesma coisa do mesmo jeito há mais de um ano está acomodada. Uma empresa que aceita um recurso desses, também. Desconfio que quando ela hesita em mandar incompetentes embora alegando “perda de conhecimentos esclerosados acumulados”, ela quer dizer “somos incapazes de fazer avaliação profissional objetiva”. Engraçado: cadê o programador-commodity nessas horas?

3. Existe uma palavra melhor para iteração? Essa palavra é muito pedante. Só os iniciados sabem do que se trata, e os demais ficam pensando em “interação”. Que, na boa, pode muito bem se referir à mesma coisa. Não estou falando de “iteração de loop/enumeração/lista”, onde a tal palavra é indispensável. Agora, falando de projetos, com gente normal (não-programadora), que se fale então em ciclo, passo, ação, ou interação mesmo — preciosismo pra quê, meu deus.

4. Por que as empresas acreditam em antivírus? Vou ter que interromper a escrita das FAQs pois o antivírus começou a executar sua rotina diária. Ele não vai encontrar nenhum vírus mas a empresa vai dormir tranqüila. Enquanto isso, estou numa máquina Windows com direitos de admin local e o único browser que posso usar é o Internet Explorer 7. Paciência.

Recentemente trabalhei em uma empresa de pequeno porte tentando implantar (ensinar, vender, disseminar, ou outro termo que caiba aqui) Scrum na tentativa de organizar e agilizar o processo de desenvolvimento do software da empresa, que até o momento só conhecia (e conhece) Waterfall.

As desculpas da empresa para não adotar Scrum (ou outro processo ágil) são todas apoiadas em confiança (ou desconfiança): como confiar num projeto que não tem tudo detalhadamente especificado desde o início? Era comum ouvir: “só isso não vai dar certo”, “precisamos detalhar todas as funcionalidades primeiro”, “não quero chegar lá na frente e ter que mudar alguma coisa hein”, “o cliente não vai querer comprar uma coisa que ele nem sabe o que é”.

Na ocasião, encontrei este artigo falando sobre desenvolvimento iterativo e incremental, e utilizei estas imagens para (tentar) argumentar meu ponto de vista.

Iterativo:

Incremental:

É evidente que ninguém entendeu a mensagem. Para eles, a confiança ainda estava em jogo. Em termos de proteção, o Waterfall ainda garante uma “falsa segurança” à empresa: “estamos entregando apenas o que estava documentado nas especificações”, “a documentação nos protege”.

Bom, tá aí um resumo da minha experiência e tenho certeza que vocês já passaram por algo parecido. Continuamos nos comentários…

Estou lendo o consagrado The Pragmatic Programmer, o livro é ótimo e faz com que eu tenha certeza que sou um sadomasoquista -calma, eu vou explicar-. Da sua capacidade técnica eu nunca desconfiei, pois sempre é citado nas lista de “top hits” de pessoal muito bom como o Guilherme Chapiewski e Phillip Calçado. Agora entra a explicação do sadomasoquismo … ler um livro destes, realmente nos faz pensar, tanto em corrigir hábitos ruins que adquirimos com o tempo, quanto novas possibilidade em automatizar todas as tarefas rotineiras por exemplo. Até ai tudo bem, maravilha, o livro até parece uma auto-ajuda alá Paulo Coelho para o programador sofrido e abatido pelo rotina Waterfall … E é nesse momento que volto a realidade e lembro que não sou um programador e muito menos pragmático, pois aqui, no real world Waterfall eu sou apenas um macaco digitador, logo adaptei algumas lições do livro para a vida real:

• The DRY Principle, bom aqui é diferente, parafraseando o Miguel, aqui temos o PRY Principle, que se auto explica, Please Repeat Yourself.

• Building Adaptable Systems, essa parte aqui se resume a criar “flags” no banco de dados e dar um nome bonitinho de “parametrização”.

• Programming Close to the Domain, Domain !?! Seria enviar 18 ou mais parâmetros pra procedures que contém as regras de negócio ? Se for, aqui a gente faz !

• Programming Defensively, aqui isso se resume a colocar logs em lugares chaves pra passar a culpa do bug para outro equipe.

É claro que existem mais conceitos, mais para um programador-pragmático-waterfall os principais estão acima. O significado real de cada tópico você pode ver nos links, apesar que nada substitui a leitura do mesmo, que por sinal eu recomendo!

Enquanto isso, continuo com a minha sessão “sado”, lendo sobre DDD e tentando descobrir Por que as pessoas de negócios falam como idiotas.

Qualquer desabafo deixem nos comentários.

*obs: o link do amazon não é “paitrocinado”, só ilustrativo mesmo.

Ultimamente eu tenho me sentido um pouco Josef K, daquela história. Acordo sem peso na consciência, mas basta abrir a porta (ou o Google Reader) e parece que o mundo decidiu que eu preciso tomar parte de um processo, o qual quanto mais eu tento compreender, mais enrolado, culpado e incompetente eu tenho que me sentir.

“O processo” aqui é todo o conjunto de metodologias, patterns, mindsets e filosofias que, se eu não absorver e professar, não sou digno nem de abrir o Visual Basic 4. Claro que ficar expert no processo não é coisa simples assim como ler um blog ou ler um livro. Além de estudar, você tem pôr em prática, compartilhar o conhecimento e encantar as pessoas ao redor, ao mesmo tempo. Você tem que se tornar um especialista em tudo e ter uma wikipédia implantada na cabeça, pra não se esquecer de nada.

De todas as suas especialidades, você deve conhecer os patterns, os anti-patterns, como aplicá-los, como não aplicá-los, os casos de sucesso e os fracassos. E não basta todo o conhecimento puro e simples. Isso é fácil de ter! O passo 1 na sua hierarquia de necessidades é adquirir uma técnica apurada, ficando fera do assembly ao Haskell, do file system à enésima forma normal, do calloc() ao GC, sem tropeços.

Depois você precisa expandir um pouco os seus horizontes com o estudo das metodologias que fazem um software nascer, crescer e vencer. É preciso saber como um projeto é gerido, como os programadores funcionam, o que o cliente realmente quer… enfim, satisfazer todos os stakeholders, como você vai se acostumar a dizer. Tudo isso dentro do orçamento que você vai obviamente saber controlar para depois calcular o ROI — coisa simples, admita.

E já que está manjando de finanças, o degrau a seguir é acompanhar o mercado de IT corporativo e open-source, para conhecer os produtos, estratégias, mergers, winners e losers. E, conhecendo, escolher o que é melhor. Não vai querer ficar pra trás, né? Não vai ser difícil para alguém tão inteligente quanto você.

Ficará evidente que você não passa deste ponto do processo se não souber aplicar toda a sua expertise na forma de arquiteturas ágeis, interfaces ágeis, teamwork ágil e comunicação ágil. Claro, a esta altura absolutamente tudo o que você faz é ágil de alguma maneira. (Sua namorada pode reclamar, porém.) Este momento é crítico na sua carreira, pois você não pode errar só porque seu desempenho tem que estar num ponto ótimo dentro de 10 ou 12 dimensões. Por sorte, você conhecerá todas as métricas e seus benchmarks, para poder guiar a si próprio e sua equipe.

Então, passando esses níveis de subsolo você está pronto pra atingir o térreo do desenvolvimento bacana de software. Você já tem experiência e conhecimento suficientes para exercer sua profissão em alguma empresa 2.0 (quiçá 3.0!) por aí. Já poderá participar de discussões de arquitetura, engenharia e filosofia de software nos blogs. Você venceu o processo.

Quanto aos Josef K da vida… bom, você sabe o que acontece no final.

Diferente do meu blog, onde o foco é apresentar as idéias “mastigadas”, aqui eu pretendo gerar discussões para que possamos entrar num consenso.

Primeiro, deem uma olhada neste artigo que apresenta bancos de dados como commodities, ou seja, qualquer um serve. Depois tem mais esses posts sobre ORM e Frameworks que também acho interessante.

Agora gostaria de saber a opinião de vocês: dado um sistema não crítico de mercado (tipo um CRM, e-commerce, portal, etc), onde mais de 50% das funcionalidades são CRUD, 30% relatórios e os 20% restantes alguma lógica e processamento, a escolha do banco de dados e a forma com que os dados serão manipulados são os principais fatores determinantes do sucesso de um projeto?

1… 2… 3… Valendooo!

Este é meu primeiro post aqui no 1up4developers e tentarei ser objetivo.

É fato que a maioria das empresas de desenvolvimento de softwares são desorganizadas, têm problemas nas entregas, falta documentação, etc. Outro ponto em comum é a espectativa de resolver todos os problemas apenas adotando uma ferramenta/metodologia de nome forte ou que ainda não foi inventada.

Só para ilustrar essa afirmação, vou expor algumas situações reais que presenciei:

Multinacional alemâ com dificuldades no levantamento de requisitos e testes buscou resolver seus problemas com uma suíte de produtos da Borland. Não deu certo. Empresa nacional de médio porte quando enfrentou uma crise financeira por não conseguir cumprir datas buscou solução contratando uma consultoria especializada e “organizar” a bagunça. Não deu certo e deixou a empresa à beira da falência. Empresa nacional de pequeno porte pretendia migrar a tecnologia/plataforma de desenvolvimento fornecendo cursos para seus desenvolvedores na esperança de melhorar o processo e a qualidade de seu produto. O resultado foi desastroso.

É comum hoje ouvirmos nomes como RUP, XP ou Scrum como a solução para todos os problemas de uma empresa. Outros nomes como UML, Testes Unitários e TDD também têm ganhado espaço nessa lista de “celebridades”. O erro das empresas é achar que esses nomes são “roupas” que podem ser vestidas ou trocadas facilmente. Elas têm um problema X e acham que resolvem aquilo adotando uma ferramenta/metodologia Y.

A grande solução para esses problemas são as pessoas, os profissionais da empresa. Encorajar o desenvolvimento profissional, incentivar financeiramente, deixar os profissionais à vontade para opinarem são alguns pontos que geram resultados a longo prazo. Valorizar o profissional na contratação também é muito motivador ao invés de tentar negociar seu salário com base em seu tempo de experiência ou quantidade de ferramentas que já trabalhou.

Só para finalizar o post, esperando que tenham entendido a mensagem, fica um artigo do Fowler falando de quando o barato sai caro.

— Inaugurando a minha participação no blog —

Sabe aqueles quadros que costumam vender na rua? Esses de feirinha, que são verdadeiros clássicos: casas toscas num gramado, cenários praianos, coisas deste naipe. São parte do que é chamado de arte naïf: obras não necessariamente intelectuais ou acadêmicas. Que podem até ser tecnicamente bem-feitas, mas dificilmente vão transformar seus autores em Van Goghs, mesmo que eles arranquem as próprias orelhas com os dentes.

Lembrei dessas coisas no mês passado, quando eu estava a ponto de precisar desenvolver um parser para uma certa linguagem de programação antiga. O parser seria um pedaço de uma ferramenta que extrai informações sintáticas e estruturais de um programa a partir do seu fonte — coisa que qualquer IDE atual disponibiliza quando se faz refactoring ou checagem de referências e dependências. Mas, como a tal linguagem não tem exatamente um IDE, a ferramenta (e o parser) tem que ser desenvolvidos “do zero”. E lá estava eu estudando as necessidades do meu trabalho.

Em pouco tempo concluí (instintivamente, não objetivamente) que o ideal era construir um mecanismo de parsing genérico, que servisse para qualquer linguagem. Entendi que esse mecanismo era possível de existir, desde que o léxico (sintaxe para definir sintaxes) fosse potente. Foi divertido então definir um léxico que permitisse uma estruturação a la BNF. E de forma bastante ingênua parti para montar um protótipo de parser. Um protótipo que entendesse uma linguagem simples. Um parser de XPath, por exemplo, só pra começar…

Foi aí que eu vi que ainda preciso comer muito arroz e feijão! O fato é que eu nunca precisei fazer um compilador na faculdade (ha!), e portanto não sabia que o buraco é muito mais embaixo. Existe um monte de formas de se construir um parser, uma porção de ferramentas, documentos, exemplos… e eu lá, escavando a pedra pra fazer a roda.

Pra mim foi interessante entender como esses mecanismos funcionam, e também foi bacana ter imaginado alguns algoritmos que, depois vi, são usados no ramo há muito tempo. Mas o ruim da história é ter entrado num caminho arriscado ao criar uma solução duvidosa, por pura ignorância. Nesse episódio eu fui um engenheiro naïf!

A minha “obra” até poderia ser passável tecnicamente, mas sem dúvida eu deixaria uma série de defeitos para trás, que qualquer um mais capacitado iria bater o olho e pensar: mas quem fez esta merda? Que é mais ou menos o que eu penso quando vejo uma ou outra pog alheia…

Seu código se sentiria à vontade na feirinha hippie?

Inicio de nova tarefa:

• Descobrir onde está o documento de requisito.

• 10 minutos depois, achei o documento, mas só tem tela.

• Descobrir onde está o outro documento de casos de uso.

• 10 minutos, descobri que está em outro documento.

• 10 minutos, descobri que este outro documento não tem a funcionalidade que preciso desenvolver, mas tenho esperanças, pois achei um link pra outro possivel documento.

• 10 minutos, realmente desisto, no documento só tem os tópicos, nada de texto.

• Pergunto ao lider onde encontrar o documento, e é claro que está no Sharepoint.

• Finalmente acesso e ganho um “Error: Access Denied” …

~40 minutos … Realmente o Waterfall não tem limites !

obs: Espero que o Request access do Sharepoint realmente funcione !

Hello hello hello ! Inaugurando o Blog do Mal … Foi lançado convites de autores a grandes poggers da atualidade !

A idéia deste blog inicialmente é discutir as dificuldades que vivemos diariamente num ambiente Waterfall 2.0, mais como um desabafo mesmo ! E também é claro, postar sobre tecnologias dos sonhos … afinal, não é todo mundo que trabalha numa ThoughtWorks, 37signals, Surgeworks … etc. que realmente trabalham com tecnologia de ponta !

O que vem a ser tecnologias dos sonhos ?!? Resposta rápida e cruel: São as tecnologias que não podemos desenvolver em nosso ambiente waterfall de trabalho ! Ruby, Ruby on Rails, Python, Java 5 … e muito mais !

Vamos ver o que vem por ai !

Sucesso e paz a todos !