Agora quem quiser encontrar a galera do 1up4dev, deve acessar http://1up4dev.org!

Bom pessoal, é isso, qualquer dúvida, críticas ou reclamações do novo layout ou qualquer outra coisa, podem comentar aqui.

Obs.: Para quem assina o feed (RSS), já está sendo automaticamente redirecionado para o site novo.

Abraço

Bom pessoal, hoje estou aqui pra pedir ajuda. Sim, pedir ajuda pra todos àqueles que utilizam a web(www) para alguma coisa, seja para estudar, trabalhar, jogar ou ficar rico! E falo por todos desenvolvedores que tem o navegador como container de suas aplicações, que tem que lidar com as diversidades de dois mundos, MS Internet Explorer 6 contra a rapa!

O dia-a-dia no desenvolvimento de software web é um tanto sofrido para quem tem que, além de fazer uma aplicação com boa usabilidade, performance e ainda bonitinha, tem de manter compatibilidade com a ferramenta <voz_do_faustão>da gloriosa Microsoft</voz_do_faustão> que vem com o Windows XP: IE6. Sempre que você faz algum milagre em JavaScript, ou usa alguma técnica Web 2.0 pensando em agradar o usuário final (ou até mesmo o seu gerente!), tem que ficar com os dois pés atrás, pois você só pode comemorar depois de testar no IE6. O IE6 com certeza pode ser apontando como o pior navegador de todos os tempos, lento, péssima usabilidade, segurança terrível e ainda vai na contra-mão de todos os padrões WWW. O fato é que muita gente que programa não sabe que na verdade nem JavaScript este browser suporta, na verdade ele suporta um clone da Microsoft chamado JScript, este sim é o que deixa os programadores do mundo todo de cabelo em pé.

É claro que eu não podia deixar de fazer um comentário maldoso. Atualmente ainda temos muitas aplicações que não usam muitos recursos maravilhosos que a nova gereção de navegadores oferecem por culpa de empresas que não tem coragem de chutar o balde e forçar seus clientes à migrarem seus navegadores em prol de uma melhoria para todos, desenvolvedores e usuários! É claro que este tipo de empresa casualmente adotam metodologias duvidosas (waterfall puro!!), que refletem diretamente na qualidade de seus aplicativos, mas por outro lado temos empresas que lideram um movimento que deveria ser seguido por todos àqueles que querem se manter no mercado, uma delas é a 37Signals, que já manifestou algumas vezes o seu abandono ao IE6 dizendo que apartir do dia 15 de agosto todas suas aplicações passariam a não ter o compromisso de suportar o IE6.

Bom, acho que já ficou claro até aqui, que o passoal do 1Up4Developers apoia esta causa, e é por isso que escrevo este post, para mostrar a nossa aderência à campanha SaveTheDelelopers.

Assim como nós, muitas pessoas começam a apoiar essa campanha através de seus blogs, pessoas que são referência no desenvolvimento de software web. Eu descobri esta campanha através do blog Nome do Jogo, do Carlos Brando, e de imediato pensei em fazer este post.

Pessoal, disseminem esta idéa em todos os lugares, quando algum parente chamar você para consertar seu computador diga: só se você atualizar o seu navegador!

Abraço

Sei que estão estranhando … perceberam que não tem Waterfall no título ? Pois bem, hoje não vou chorar e digo mais, vou até fingir que não vivo num Waterfall e vou falar sobre TESTES ! Tá bom, sei que enfatizei demais, só vou fazer uma resenha sobre este último livro que li mesmo.

Numa leitura leve e até divertida (sou nerd mesmo), os autores abordam conceitos práticos de testes que não estão ligados diretamente ao JUnit, e sim a “Filosofia de Testes”. O legal que os principais conceitos são apresentados com acrônimos como “Right BICEP”, “CORRECT Boundary Conditions”, “A TRIP”, MockObjects e etc. Depois da passagem por todos esses acrônimos, os próximos capítulos atacam temas como, onde colocar os testes, design dos testes e etc.

Isso pode parecer estranho, mas de todos os capítulos o que eu mais gostei foi do primeiro, a Introdução, talvez porque no momento estou com a água do waterfall até o pescoço, e nele os autores colocam as dicas de como contra-argumentar as desculpas para não fazer testes. Exemplos dos tópicos, “Por que devo me importar com testes ?” e “Desculpas para não testar”, parece que os autores realmente conhecem o lado negro da força. Por sinal, achei este último tão interessante, que estou pensando em pedir permissão para traduzi-lo e postar aqui, se alguém souber o caminho das pedras e quiser ajudar eu peço a gentileza de entrar em contato.

Gostei muito do livro, o considero uma ótima referência sobre o tema, veja bem, referência, pois se queres uma biblia do JUnit, descarte-o. Sei que muitos da nossa área não conhecem nada sobre o assunto, e um ótimo começo seria por ele.

Agora, voltando um pouco pra minha (e de muitos) realidade cruel, antes de ler o livro eu imaginava (ou sonhava ?) que o sistema atual em que trabalho, poderia ser implantado testes, agora, com uma visão mais pragmática, tenho certeza que estava certo, só que mirando na camada errada. Aqui, a maioria da lógica (uns 90%) está em PL/SQL no banco, e a melhor maneira de implantar testes seria começando com um PL/SQLUnit … mas aí já é assunto pra outro post. Ahh, ainda não pesquisei, mas deve existir com certeza.

Chegando ao fim do livro …

Uma parte chata do livro foi quando terminei de lê-lo, confesso que fiquei com uma vontade de “quero mais” e acabei ficando com a impressão de que só li a ponta do iceberg sobre o tema. Sugestões de mais livros sobre o tema, são bem vindas !

Como grande fã que sou do BR-Linux, estou aderindo a campanha ! E com certeza todos os autores deste blog concordam comigo, que noticia do mundo livre é no BR-Linux.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe – quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Há algum tempo atrás, orientação a objetos era uma coisa de outro mundo para mim. É sério, não conseguia pensar na possibilidade de existir outro paradigma de programação. Bem, depois que estudei muito sobre OO e passei a utilizar profissionalmente, hoje não consigo me imaginar trabalhando sem OO. Tudo fica claro, organizado, abstraído… O que eu ganhei com isso? Com certeza consegui ser mais produtivo, mais organizado e mais eficiente e, como consequência, melhor remunerado. Se ainda desenvolvesse proceduralmente, certamente ainda desconheceria conceitos e técnicas, sendo apenas mais um na multidão. E não é assim que um verdadeiro desenvolvedor ágil quer ser visto, certo?

Outra coisa que estudei muito e hoje fico feliz em utilizar profissionalmente são Testes Unitários. Uma das premissas do desenvolvimento ágil está relacionada à qualidade do código. Com testes unitários é possível desenvolver incrementalmente e responder rápido às mudanças pois seu código está “protegido”. Além de servir como apoio à refactoring. O que eu ganho com isso? Consigo me preocupar apenas com o desenvolvimento de uma pequena funcionalidade por vez, meu código fica mais “limpo” e manutenível. Em consequencia disto me torno mais ágil e sou melhor remunerado. Além de poder dormir mais tranquilo…

É importante reconhecer que há muito para aprender ainda. Nosso cenário de trabalho muda constantemente e os “usuários” são cada vez mais exigentes. Além disso, é importante lembrar que não existe bala de prata, não existe uma tecnologia que resolve todos os problemas. As linguagens e tecnologias são limitadas e precisam evoluir. Você precisa evoluir junto! Não se esqueça também que lá fora tem um mercado de trabalho começando a enxergar essas qualidades ágeis.

Em se tratando de 1up4dev, nem preciso dizer que a situação a que me refiro é a de quase inevitabilidade do waterfall, em que estamos tão engolidos pelo “sistema” que, aparentemente, só nos resta lamentar, se frustrar e eventualmente se acostumar com tudo. Não deduzo, porém, que esses são estágios de uma manifestação de bunda-molice. Do contrário, seria suficiente encerrar o assunto com algo do tipo “ou somos parte da solução ou do problema” (doutrina Bush, em pleno 2008). E ainda assim, sem que ao menos sejam esboçados tanto “o problema” como “a solução”, esse raciocínio binário não serviria para nada.

Antes de continuar com a minha idéia, gostaria de escrever rapidamente sobre o panorama que se desenha para o futuro. Especificamente, o nosso futuro. Nem sempre lembramos dele, mas é lá que vamos viver em breve. E sem querer parecer auto-ajudesco, digo que o futuro do desenvolvimento de software está nas nossas mãos — e não de forma indireta ou abstrata. É lógico: as mãos que hoje controlam o “sistema” vão se aposentar daqui uns anos, e as nossas vão substituí-las. Nessa seqüência, é possível imaginar que, em breve, estaremos perpetuando o waterfall. Pois nesse dia nós é que seremos o status quo, e o status quo, para ser digno do nome, não quer saber de mudar nada.

Software já é estratégico há algum tempo e ocupará cada vez mais espaço na vida das pessoas, das empresas e dos governos. Que qualidade de software será oferecida quando nossa geração estiver no comando? Imagine o alto custo financeiro e social de se manter na periferia de TI. Sub-desenvolvimento passa a ter um novo significado, não é? Temos que assumir a responsabilidade, até porque ela pode significar a existência dos nossos empregos. Ou você vai preferir usar um software made in India?

Nada contra a Índia, claro. Mas o alerta já tinha sido dado por David Anderson no comecinho do livro Agile Management for Software Engineering. Abaixo traduzo livremente um trecho cujo original você encontra na página xxvi do livro:

Se a atividade intelectual de software tiver que permanecer nos países desenvolvidos e se os engenheiros de software americanos, europeus e japoneses quiserem manter o alto padrão de vida ao qual se acostumaram, eles devem aumentar sua competitividade. Há um mercado global de desenvolvimento de software, o que encolheu a distância entre um cliente na América do Norte e um fornecedor na China ou na Índia.

Esse medo do sr Anderson tem que ser nosso também (exceto que nós não temos como rebaixar nosso “alto padrão de vida”). Sabemos que precisamos melhorar, e muito, a nossa competitividade, e não só individualmente. Agora, a grande questão é: como vamos fazer isso, se não temos suporte para viabilizar novas formas de trabalho sem dispararmos o sinal de pânico no chefe, no cliente?

Pretendo desenvolver a minha sugestão em alguns posts, seguindo alguns princípios:

1. “Mudança” é definida como o amplo abandono da mentalidade waterfall no mercado de TI.
2. Você acredita na mudança e é o maior interessado nela, pois ela representa o futuro que você quer.
3. O risco da mudança é percebido com mais intensidade quanto maior é o poder de quem a observa.
4. O benefício da mudança é percebido com menor intensidade quanto maior é o poder de quem a observa.
5. A mudança pode ocorrer de baixo para cima na cadeia de poder.

No próximo post, pretenderei detalhar melhor os efeitos desses cinco pontos. Dali em diante, dificilmente irei sugerir uma ação coordenada e planejada — nada menos ágil que isso! Prefiro apostar no desenrolar natural das coisas, desde que os princípios sejam válidos. No mínimo, vamos avançar o debate. Tomara que eu não escreva muita besteira, e espero ser corrigido a qualquer momento.

http://www.guj.com.br/posts/list/15/92783.java#497015

Esta discussão está boa, e no meio das chamas levei um “impacto” ao ler a frase abaixo.

louds wrote: [...] Não usem a incompetência alheia como desculpa. Se está ruim e você não está ativamente combatendo isso, você é parte do problema e não da solução. [...]

Esta é uma das frases que eu deveria lembrar toda vez que começo a lamentar sobre o ambiente atual de trabalho, eu tento, me gerencio, mas confesso que é difícil.

Com o diabinho no ombro, logo ouvi um suspiro … Waterfall é bom ! Não questione … volte a codificar … Só que ao olhar pro lado, vi o meu poster do Dijkstra e voltei a realidade. Foi quando me perguntei:

Por que é difícil combater o Waterfall ?!?

Sei que esta é uma pergunta sem resposta direta e que depende de muitos fatores do seu ambiente de trabalho, mas eu numa análise fria e cruel respondo: Porque a maioria não sabe o que é waterfall.

No último ano da faculdade (cursei Sistemas de Informação), e sem brincadeira, nas aulas de Engenharia fui obrigado a decorar todas as fases, papéis, artefatos e etc. do RUP, e pra fechar com chave de ouro, no segundo semestre veio o famoso Análise de Ponto de Função. Isso somente prova que já aprendemos errado, e sei que muita gente fica nisso. Se hoje tivesse a oportunidade de encontrar este mesmo professor, iria fazer a pergunta acima, e acrescentar com questionamentos como, engenharia de software não é eng. civil e neste processo todo quem está preocupado com o Retorno de Investimento do cliente !?!

Acredito que a chave para combater o Waterfall é conhecimento, temos que trazer questionamentos a quem está do lado e isso não é nada fácil, como você convence os mais de vinte desenvolvedores que estão ao seu redor que eles estão na Matrix !?! O que fazer com o pessoal que não quer sair da Matrix !?! O Waterfall é uma grande mãe que coloca muitas pessoas (Analistas, Desenvolvedores, Gerentes, Testers … etc.) numa casca irreal de proteção e que gera um ciclo vicioso que se auto sustenta.

Neste exato momento que sou obrigado a concordar com o grande malucão Raulzito:

É pena não ser burro ! Não sofria tanto.

As vezes me questiono sobre esta insistência em tentar mudar, nadar contra o Waterfall. Não seria melhor se “render” logo e entrar no jogo, sei lá, poder falar, “Caso de Uso não é comigo, só programação!” e ver que são 10 pras 18, desligar o computador e sair sem o minimo peso na consciência.

Por que numa equipe de dez desenvolvedores, só eu sinto falta de testes unitários !?! Fico indignado ao receber um caso de uso que não agrega nada ao cliente, somente foi “inventado” pra ser cobrado dele, e só eu que vejo isso !?! Sei lá, eu devo estar maluco mesmo com toda esta historia de desenvolvimento ágil, e se preocupar com ROI do cliente, apesar de achar uns malucos por ai que sofrem do mesmo “problema” que o meu.

Como no filme dos 300, tenho esperanças e sei que poucos enfrentarão muitos, e continuo minha batalha com o Waterfall.

Paz a Todos !

Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido.

O conteúdo continua composto de puro veneno partindo de mentes furiosas por não terem uma vida agilemente ativa. Aposto que você, leitor, também se encontra nessa situação aviltante, então assine o novo feed e participe comentando as nossas observações, frustrações e viagens.

Muito sucesso a todos! Prossigamos…

Eu vejo este tipo de metodologia como a velha discussão dos sistemas sócio-politicos. Se analisarmos de forma fria e racional as duas principais vertentes desenvolvidas neste campo, percebemos que de uma lado temos o socialismo com todo seu esforço para ser algo justo e equilibrado, e na outra ponta temos o capitalismo com toda sua desigualdade, agressividade competitiva entre outras coisas.

“O Socialismo é um sistema sócio-político caracterizado pela apropriação dos meios de produção pela coletivadade. Abolida a sua propriedade privada
destes meios, todos se tornariam trabalhadores, tomando parte na
produção, e as desigualdades sociais tenderiam a ser drasticamente
reduzidas uma vez que a produção, sendo social, poderia ser
equitativamente distribuída. A proposta de Karl Marx, um dos autores que desenvolveu este tema, é a de que o socialismo fosse um sistema de transição para o comunismo, que eliminaria de forma integral o Estado e as desigualdades sociais.” Ver referencias

Como sabemos atualmente o mundo é capitalista, apesar de algumas exceções. Mas que relação isto tem com processo de desenvolvimento de software??
Uma das razões para o capitalismo dar certo é a sua naturalidade, quero dizer com isso que este pensamento/comportamento é intrínseco ao ser humano, todos nós de alguma forma nascemos pensando e agindo assim, uns mais outros menos, e isso acaba refletindo no sucesso que teremos ou não no futuro. Por isso digo que é natural.

Apenas para deixar claro, não tenho intenção nenhuma de discutir ciências politicas ou econômia com ninguém, realmente não tenho conhecimento para isso (desconsiderem qualquer bobagem que eu tenha dito, tentem captar a intenção. risos).
Minha intenção desde o inicio é mostrar que os processos e metodologias que conhecemos na vida real como parte do Waterfall não são naturais ao desenvolvimento de software e muito menos à nós desenvolvedores. Eles parecem maravilhosos em um quadro na parede com todo fluxo do PMBOK, por exemplo, mas no dia-a-dia custam muito para serem aplicados e exigem que nademos contra nossos instintos para que cheguemos à algum lugar.

Quando falamos de metodologias ágeis, em primeiro momento parece muito vago, o manifesto ágil em sí não se mostra muito técnico, em alguns momentos parece um pouco distante de uma aplicabilidade real. Mas na verdade em sua excência ele tem tudo que nos identificamos. A começar por suas ferramentas, quem na vida nunca se viu praticando pair programming, pois bem isto é uma pratica muito útil de uma coisa maior chamada Extreme Programming. E não precisamos procurar muito para chegar a conclusão de o Scrum tem como consequencia uma maior aproximação da equipe e auto conhecimento dentre os participantes, com isso proporciana um maior controle gerencial para quem exercer esta função.

Tudo isso natural para nós programadores e computeiros, assim como o capitalismo é para a sociedade e o mercado ecônimico.

Reforçando, não quero iniciar nenhum tipo de flamming relacionado à política ou econômia, quero apenas expôr algumas maluquices que venho pensando ultimamente.

Bom galera, gostaria de dizer que me motivei a escrever essas idéias depois de ler um excelente post do Rodrigo Yoshima no Blog Débito Técnico. É bom saber que ainda existem pessoas que tem a capacidade de provocar o pensamento e instigar a busca por explicações.

Eu sonho um dia poder trabalhar com uma metodologia ágil, enquanto isso não chega vou me lamentando por aí.

Abraços, e coloquem suas opiniões! Podem esculachar, risos…

Referências:
Socialismo
Capitalismo
Débito Técnico – Não jogue dinheiro com melhoria de processos…
]]> http://1up4dev.wordpress.com/2008/06/01/waterfalling/feed/ 2 miguelhorlle http://1up4dev.wordpress.com/2008/05/29/campanha-de-vendas-e-promocoes-para-fechar-bem-o-ano-fiscal-coisas-do-bill/ http://1up4dev.wordpress.com/2008/05/29/campanha-de-vendas-e-promocoes-para-fechar-bem-o-ano-fiscal-coisas-do-bill/#comments Thu, 29 May 2008 22:02:00 +0000 miguelhorlle http://1up4dev.wordpress.com/2008/05/29/campanha-de-vendas-e-promocoes-para-fechar-bem-o-ano-fiscal-coisas-do-bill/ ]]>
Pessoal, não pude deixar de compartilhar essa!
Nos meus tempos negros trabalhei com a bendita Microsoft, com isso acabei deixando rastros nesse sub-mundo que me perseguem até hoje. Um deles é este newsletter do capeta que me persegue (nem o anti-spam do gmail funcionou!).

Outro dia estava tendo uma conversa discussão com meu amigo Nivaldo sobre interfaces web com uso abusivo de javascript. Aí lembrei o que o Miguel disse sobre interfaces citando como parâmetro o Google e a Apple e a pouca importância que as empresas dão para esse assunto.

O mercado (alvo) está cada vez mais competitivo. Usuários não querem simplesmente um sistema funcional; ele deve ser bonito, intuitivo, agradável de usar. Um bom exemplo do que estou falando é o popular Goggle Reader: será que estaria tão popular se não fosse sua interface “rica”?

Acredito que atualmente, para sistemas web, a interface deve(ria) ser o principal “exciter” e onde as forças devem atuar consideravelmente. Digo isso porque as outras partes de um sistema (estou falando do negócio e banco de dados) estão razoávelmente maduras em termos de conceitos (OO, Teste, ORM), frameworks, etc.

Foi o tempo em que precisavamos saber apenas escrever código funcional. O desenvolvedor de hoje precisa saber muito bem HTML, CSS e JavaScript. E para isso, felizmente podemos (e devemos) utilizar recursos e frameworks para isso.

8. Por que “anos de experiência” são tão importantes nos classificados de emprego?
   As profissões de informática já existem há décadas, e existe um grande histórico de coisas que deram certo e outras que nem tanto. Entre essas últimas, persiste uma forma garantida de contratar gente inepta, ao mesmo tempo em que aliena bons profissionais: a temível “experiência comprovada” em alguma coisa! Não importa se o candidato trabalhou uma vez por mês ou 16h por dia com a tal tecnologia durante todo o tempo requerido, ou se ele trabalhou com algo similar e não terá dificuldade, ou se consegue tranqüilamente ficar craque no tal requisito em duas semanas. Competência e experiência se confundem de forma surreal. É tão difícil assim avaliar aptidões?
9. Se certificações são tão inúteis, por que fazem tanto sucesso entre candidatos e recrutadores?
   Existe um debate acalorado sobre a utilidade/qualidade das certificações como forma de filtro de candidatos a emprego. As empresas não abrem mão de exigir algum diploma, pois a oferta está grande. Os candidatos, por sua vez, fazem sacrifícios para colocar uma estrelinha a mais no CV, pois a concorrência está grande. E na prática, quando pintar um problema, tanto o profissional ultra-graduado quanto o humildezinho vão recorrer a dois recursos: (1) capacidade de raciocínio e (2) Google. Quem tira proveito disso tudo além das empresas de treinamento?
10. Por que contratadores dificultam o acesso à internet por parte dos contratados? by peczenyj
    Será que quem contrata acha que o cara vai ser mais produtivo se ficar longe do GMail, MSN, Terra Esportes, 1Up4Dev? Sei lá. Eu achava que as empresas contratavam pessoas para que elas atingissem determinados objetivos, e não para que produzissem código ininterruptamente, sem “distrações”. Mas pode ser que, para elas, a produtividade seja um número, não um valor.
11. Qual é o sentido de se impor políticas de segurança inócuas? by miguel
    Há quem se sinta seguro contratanto dummies quaisquer para implementar filtros de firewall e fazer papel de polícia, bloqueando pen drives e colocando a impressora pra funcionar só das 8 às 18h. Missão: racionalizar o uso dos recursos de trabalho! Aumentar a segurança! Impedir vazamento dos fontes! Ao mesmo tempo, relaxam no recrutamento e logo a empresa vai estar infestada de pessoas que pareciam super-bem-intencionadas, mas vão passar o dia vendendo muamba no Mercado Livre através de um proxy russo. Ou emporcalhando os preciosos fontes, o que é bem pior que roubá-los.
12. Por que contratados e contratadores gostam de se tratar como empregados e patrões, mesmo em condições “PJ”?
    É fato inegável que a carga escorchante de tributos incidentes sobre a folha de pagamento leva as empresas a procurarem alternativas. Invariavelmente elas sub-contratam outras empresas para que, estas sim, se virem com o problema da mão-de-obra. Mas alguém já viu isso acontecer pra valer? O que existe é um local de atividade, um horário de trabalho, um salário, e cara feia se você quiser atender outro “cliente”. Os contratados não agem como empresários, embora paguem caro para o serem. E parece que ninguém se incomoda com o teatrinho patrão-empregado.
13. Qual a lógica em se cobrar por hora e não ganhar por hora?
    Os iniciantes começam com 10 ou 12 reais. Os júniores podem sonhar com o dobro disso. Os plenos estão na faixa dos 30 ou 35. E para os sêniores, o céu é o limite! Mas, curiosamente, quase todos trabalham 160 horas por mês. Quero dizer, são pagos por 160 horas trabalhadas no mês, recorrendo talvez a um banco de horas (muitas vezes fictício) quando a conta estoura. Ainda assim, freqüentemente gostamos de calcular nossos rendimentos pelo valor-hora, sonhando que estaríamos quase ricos se as contas batessem. 160 horas, my ass.
14. Como se enquadram projetos temporários nas variantes do Agile? Ou: posso ser free-lancer e agile ao mesmo tempo?
    Esta pergunta não é irônica (é, as outras pretendiam ser). É uma dúvida que eu tenho de verdade. Não sou expert em Agile/Scrum/XP/etc, e lendo a respeito dessas formas de trabalho, às vezes acho difícil compatibilizar a idéia de contrato temporário com desenvolvimento incremental sem tempo para terminar. Agile, por natureza, contra-indica prazos precisos. O contrato temporário, por natureza, baseia-se no inverso. Gostaria de entender melhor como essa situação já se resolveu na vida real.

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

4. 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.)
5. 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?
6. 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.
7. 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.

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.

“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.

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!

É 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.

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?