Livros para comprar

Estava vendo livros para comprar, achei algumas resenhas sobre esses aqui que me interessaram muito: Pragmatic Project Automation - Amazon (US$ 20,00) - Livraria Cultura (R$ 122,00) The Pragmatic Programmer - Amazon (US$ 31,00) -Livraria Cultura (R$ 102,00) O duro é que pra comprar apenas um livro na Amazon o frete sai mais caro que o próprio livro. E não estou com cacife por enquanto para pagar mais que um. Alguém conhece algum desses livros?

Tequila nunca mais

Galera! Exagerei na tequila ontem. Foram 5 a 7 rodadas de tequila, fora 3 caipirinhas que eu já tinha tomado. Um ex-colega de trampo, o Cláudio, veio ontem e a gente saiu pra botar o papo em dia. Sei que pra finalizar a noite, resolvemos fechar com UMA tequila... aí apareceu mais uma, mais uma, mais uma.... aff! O engraçado é que nem dor de cabeça eu estou hoje. Bicho ruim é assim, acho. Mas bebedeira igual essa, de novo, só daqui uns 20 ou 30 anos... :) Olha o link das fotos: Fotos da tequilada

Sobre simplicidade e mudança

Não adianta, Ward Cunningham é mestre! Segue o link para o del.icio.us com artigos de primeira linha do tio Ward. Vale a pena ler. Artigos e afins de Ward Cunningham

Três tipo de pessoas

Outro dia estava lembrando de um ditado que eu vi em algum lugar. "Pessoas cretinas falam sobre outras pessoas Pessoas inteligentes falam sobre fatos Pessoas sábias falam sobre idéias" Fico imaginando quantas vezes por dia eu sou cretino, inteligente e sábio, uma vez que estamos sempre mudando de assunto. No geral, acho bom tentar ficar no sábio e inteligente a maior parte do tempo :)))

Test FIRST - Pra que servem testes?

Simples e rápido: "Pra que servem testes?" ou melhor: "Pra que serve testar uma aplicação depois de pronta?" Resposta: Serve pra melhorar o código!!! Péééé!! Errado! *vaias* Uuuuuuuuuhhhhh! A menos que vc adicione uma fase extra de codificação ("tiração" de bugs), testar um código depois que está pronto só serve pra vc ter a certeza que seu código tem bugs. Então qdo o tempo está curto, a primeira coisa que vai pro brejo são os testes E a qualidade do seu código. Uma vez que se vc nem faz a fase de teste, tb não tem como fazer a fase de "tiração de bugs". Solução: Test-First Design nele. Só não confunda isso com fase de testes, "PELARMOD'DEUS"! O que eu vejo de gente falando que faz UnitTest e na verdade faz testes tradicional "mais ou menos" automatizado, não tá escrito.

"Caça às Bruxas"

Já viu chefe louco da vida procurando quem foi que fez aquela cagada? Já viu isso adiantar de algo? Outro dia foi bem engraçado, o chefe perguntou: "Por que foi que vcs não fizeram o que eu pedi?". Era uma coisa muito boba e a única explicação possível era "eu esqueci". Foi o que dissemos pra ele, e me veio na boca um "ok, agora vc sabe que esquecemos, e aí?", mas eu engoli. Pra que criar atrito à toa? De fato, fiquei pensando depois que não adianta nada saber quem foi ou porque foi. Depois de feita a cagada, o que interessa é saber o que se pode fazer pra resolver. Principalmente pq não resolve dar bronca, nessa área de informática, nenhum desenvolvedor que mereça o nome erra por querer, sempre fazemos o melhor possível, mas às vezes não é suficiente. Ou estou errado?

Tempos de "polimento"

Tenho reparado que sempre que um software está para ser liberado, existem um monte de pequenas arestas, ou "pontas soltas", que precisam ser corrigidas. Esse tempo costuma ser de no mínimo dois dias até uma semana, no caso mais genérico. Depois disso, ainda existem os "polimentos" de pequenos bugs que só são percebidos em produção. Esse tempo normalmente é disperso, de acordo com a velocidade em que os bugs são encontrados/reportados, em pequenos "chunks" de quinze minutos até metade de um dia. Isso costuma invadir o tempo de desenvolvimento de outros software e, olha que interessante, não costuma ser contado no tempo de projeto desses outros softwares. Uma vez medimos esse tempo de "polimento de produção" e ele tomou cerca de 10% do tempo total de outro projeto. Próxima vez que eu fizer uma estimativa de projeto, vou incluir uma semana de "polimento" no fim, e já vou alertar para essa "invasão" de projeto. Será que isso seriam "patterns de desenvolvimento de software"?

Precisando de XP

Desde que sai da última empresa, 8 meses atrás, tenho sentido uma falta imensa de XP. A gente fica mal acostumado qdo trabalha direito. Estou sentindo na pele o "retrocesso". Mas sem problemas, a empresa é competente e aos poucos, bem aos poucos, vamos colocando um processo aqui, um processo ali, até termos XP de novo. Se fiz duas vezes, posso fazer uma terceira ;) De resto meu maior problema no momento é colocar Unit Tests. E como sempre, o que mais empaca para colocar Unit Tests é integração com banco. Sinto que vou ter que apelar fortemente para o Connection Mother.

Tempo de projeto / Número de desenvolvedores

Tava pensando agora há pouco. Vc já trabalhou em um time em que cada um está fazendo um projeto diferente? Fico pensando se dá efeito. Até onde sei e vi, vale a pena agrupar esforços até um certo limite, acima disso, fica complicado. Exemplo simples e estúpido: 2 projetos, 2 desenvolvedores. Imagine que se cada um trabalhar em um projeto, ambos os projetos ficariam prontos no fim de 2 meses. Se os dois trabalhassem em um único projeto, ele ficaria pronto em apenas um mês? Que vc acha? Provavelmente cada um levaria MENOS de um mês pra ficar pronto. Só que essa regra não é linear, não é "tempo/número de desenvolvedores". Até onde eu vi, 4 a 6 desenvolvedores é o melhor custo benefício por projeto. Acima disso, vc começa a precisar de muita coordenação. Bom, essa é minha experiência, mas acho que cada caso é um caso, que vcs acham? Alguém já teve experiência diferente?