Author Archive for

13
jun
08

Guerrilha agile: a motivação

Eu preciso desenvolver uma idéia que vem me provocando ultimamente. Na verdade é menos uma idéia do que um reflexo da situação desoladora em que a maioria de nós está.

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.

03
jun
08

1up4developers 2.0

Então, nobres colegas e respeitável público, o nosso blog estava meio estranho no Blogger e decidimos mudar para uma plataforma mais funcional, mais gerenciável, mais colaborativa, enfim, uma coisa totalmente mais 2.0 mesmo.

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…

27
maio
08

Frequently Asked (by me) Questions, parte II

Prosseguindo com a série de perguntas que não querem calar, desta vez com um enfoque em RH & correlatos. Já com sugestões do respeitável público! Continuem comentando. A intenção é catalogar tosquices de comportamento encravadas no nosso cotidiano.

  1. 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?
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
26
maio
08

Frequently Asked (by me) Questions, parte I

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

  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.
20
maio
08

O Processo

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.

14
maio
08

Engenharia naïf

— 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?




Saiba mais sobre nós

RSS Feeds

agosto 2017
S T Q Q S S D
« ago    
 123456
78910111213
14151617181920
21222324252627
28293031  

Feed Counter

Blog Stats

  • 1,113 hits

tail -10f /top-posts

RSS job4dev

  • Ocorreu um erro. É provável que o feed esteja indisponível. Tente mais tarde.