Para a felicidade de nosso editor-chefe, e para não ficar com a fama de ser o último a atender os incansáveis pedidos do mesmo, eis que após me deparar com um post que li no Suicyte Notes, um blog sobre bioinformática e coisas afins (viu editor-chefe, não só escrevo algo, como este algo é sobre bioinformática!!) e me animei a escrever.

O post comenta sobre um artigo que saiu na Nature, onde os autores descobriram um erro no programa utilizado para construir as famosas matrizes BLOSUM - matrizes utlizadas para pontuar alinhamentos entre aminoácidos, que se baseiam nas probabilidades de substituição de um aminoácido em outro (se tiver mais interesse no assunto, cheque os links). Estas matrizes têm sido empregadas por mais de 15 anos, e servido de base em diversos estudos científicos. Imagine o impacto que a descoberta deste bug não teria, levando milhares de pesquisadores a rever seus resultados.

No entanto, para a sorte dos autores do programa - Steven e Jorja Henikoff - que gerou estas matrizes, Murphy estava de férias naquele dia. O autor do artigo corrige o problema, refaz as matrizes, e faz a comparação entre as matrizes “zicadas” e as corrigidas. Resultado: as matrizes “zicadas” funcionam melhor que as corrigidas. Quisera Geoffrey Chang tivesse essa sorte.

Chang é um pesquisador que no início do ano passado, teve que se retratar publicamente, após ter publicado cinco artigos sobre estruturas de duas proteínas que ele e sua equipe haviam determinado. Cinco anos depois do primeiro artigo, 720 citações, e a comprovação por parte de outros grupos que as estruturas que eles haviam determinado estavam erradas, Chang e seus amigos descobriram um bug no programa que eles haviam criado, que resultou nas estruturas erradas. Ou seja, todos que desenvolveram pesquisas confiando nas descobertas de Chang, se deram mal. Incineração de filme no mais alto grau.

Fica aí a dica: se você não testa seus códigos, torça pra ter a sorte de Steve e Jorja, senão você pode se dar mal como Chang.

Aconselho a leitura do artigo Mature Optimization, escrito por Mick West.

Ele aborda uma questão interessante: otimização no inicio do projeto é sempre ruim?

Citando Donald Knuth:

We should forget about small efficiencies, say about 97% of the time. Premature optimization is the root of all evil – Knuth, Literate Programming, 1992, p28.

O autor tenta mostrar que, as vezes, otimizações no final do projeto podem ser problemáticas:

Towards the end of the project we profile the code, and find that 20% of our CPU time is taken up by a function […] then we fix it. Then we tackle our next function on the profiler’s list; maybe one that takes 10% of the CPU time. We fix that[..] Our game now runs 30% faster[…] However, if after that the code is still too slow, you will now find it is not because of a few weighty functions, but rather a general problem with all of the code. The code is just generally inefficient. By ignoring optimization until the end of the project you have ended up with “sick code” that contains multiple inefficiencies too deeply ingrained within the fabric of the code to be removed in a timely manner.

A idéia do texto é mostrar que existem duas categorias de otimizações a serem consideradas. A primeira, considerada precoce e ruin, é aquela que é feita sem um real entendimento da necessidade dela e sobretudo do efeito final. As vezes, gastamos um grande tempo otimizando uma função cara que, no final das contas, será chamada apenas uma ou duas vezes durante a execução do programa sem afetar na performance geral.

A segunda categoria é chamada pelo autor de otimização madura. Ela cuida de problemas bem conhecidos em certos domínios de software, que são recorrentes e sobretudo previsíveis em vários projetos. Em geral, são otimizações estruturais que envolvem decisões de arquitetura e que dificilmente podem ser corrigidas ao final do projeto. O autor cita vários exemplos aplicados ao desenvolvimento de jogos, onde performance é crítica. Um exemplo bom é a questão de alocação de memória: é muito mais eficiente utilizar um sistema de pool de objetos do que ficar executando alocação repetitiva e constante na pilha.

No domínio de software que eu tenho trabalhado, o grande gargalo pode ser a quantidade de dados gravados. Uma simples listagem pode ser um pesadelo caso não seja feita seguindo certas regras simples: usar paginação na base de dados (e nunca na camada de aplicação), tentar filtrar ao máximo os dados extraídos da tabela (extrair apenas o necessário para exibição, evitandoo aumento desnecessário da quantidade de dados). Pode parecer bobo, mas outro dia me deparei com uma listagem simples que demorava em torno de 15 minutos pra rodar…

O problema acima não se encaixa tão bem no quesito “decisão estrutural”, porque ao final do código é relativamente simples mudar sem grande impacto no sistema. É apenas chato ter que passar por todas as queries, reescrever e retestar tudo. Sem contar que em geral o problema irá aparecer apenas depois do sistema ter sido instalado no cliente, ou estar em produção (afinal, ele está diretamente ligado à quantidade de dados da base). Mas com certeza é o tipo de problemas que pode ser facilmente mapeado no inicio do projeto e que não impacta em nada no desenvolvimento, se bem organizado.

Aproveitando o artigo do Raphael sobre o design de um produto ou de uma solução, quero falar aqui sobre o design de um dos aspectos de um produto de software, que é a interface homem máquina.

Se perguntarmos para 100 pessoas qual a principal característica da Apple por exemplo, muito provavelmente 98 dirão que é o design de seus produtos (os 2 outros dirão que é o preço absurdo..mas isto está mudando!). Tudo o que sai da empresa do Tio Jobs prima pela beleza, atenção nos detalhes e simplicidade de uso. Nada mais simples e clean do que um iPod shuffle, com seus 4 controles. Alguém me disse um dia que primeiro eles definem como o produto vai ser, depois eles pensam como fazer para que ele seja daquele jeito. Não duvido disso.

A Google é outra que merece destaque no quesito interfaces. Não pela beleza: as interfaces deles são muitas vezes feias. Mas eles inovaram no quesito simplicidade, usabilidade e interatividade, mostraram ao mundo um novo jeito de interagir com sites na internet. O melhor exemplo disso é a tela inicial do motor de busca, uma tela branca e um campo de texto (na verdade, o motivo inicial desta tela espartana foi a falta de conhecimento de HTML dos fundadores Brin e Page). E nada mais eficiente, rápido e leve do que a interface do GMail, ou do Google Maps. E basta ver a quantidade de ofertas de empregos para engenheiros de interação em Seattle ou New York.

E existem muitas outras empresas que claramente se preocupam com a qualidade da forma como os usuários irão interagir com seus produtos. Flickr, Adobe, 37 signals…

Ok, back to Brazil.

A minha experiência pessoal é de que interface é encarada como um mal necessário na maioria dos projetos. Sobretudo em projetos para empresas. Infelizmente ainda não tive a oportunidade de trabalhar em projetos para o grande público, ou pelo menos em projetos onde quem paga é efetivamente quem usa. Talvez seja diferente. Mas em projetos enterprise, é assim.

Em projetos web, o melhor que podemos ter é uma interface construída em photoshop e um web designer para dar um ar mais profissional para a coisa. Daí o cliente vê a interface (em geral photoshop), e usa todo o seu conhecimento (em geral inexistente) em interação para aprovar. Por fim pegam algum computeiro que esteja sem nada melhor pra fazer e mandam ele implementar a interface.

Eu posso contar nos dedos de uma mão o número de desenvolvedores que eu conheço que gostam de trabalhar com interfaces. Acho que não preciso discutir os problemas de pôr alguém pra fazer algo que não gosta, e que acha que é um mal necessário. Preciso?

Sem contar que a maioria das vezes, as interfaces se resumem a listagens gigantescas e formulários. Nada contra eles, muitas vezes resolvem. A questão é quando tratamos com quantidade gigantescas de dados (o que é bastante comum hoje em dia, tanto em sistemas empresariais quanto em sistemas para o grande público). Grandes chances de que muito rapidamente se perceba que a interface é pouco produtiva, lenta…

Não estou aqui advogando pela otimização precoce de um sistema. Estou advogando pelo estudo cuidadoso de projetos de interface e interação quando a questão da quantidade de dados/eficiência de uso é algo facilmente previsível e sobretudo crítico para o sucesso do projeto. Exemplos de interfaces que requerem um certo estudo? Que tal uma tela que tenha que sintetizar graficamente uma tabela de excel de 500 colunas por 3000 linhas, permitindo que decisões possam ser tomadas a partir de uma análise rápida do conjunto ou então que dados isolados sejam facilmente encontrados e manipulados em um mesmo ambiente? Ou então uma listagem com milhares de nomes acessada centenas de vezes por dia, onde seja imperativo encontrar um nome específico ou conjunto de nomes que atendam certas características de forma rápida?

Um bom projeto de interface requer uma equipe especializada nisso, que saiba lidar com aspectos teóricos (usabilidade, acessibilidade, modelos mentais, metáforas, affordance), com aspectos técnicos (Javascript, HTTP, programação backend eficiente), e com aspectos gráficos e de layout (cores, fontes, posicionamento de elementos). Requer gente que tenha interesse pelo assunto, e que se preocupe com detalhes. Requer estudos, protótipos, testes. Requer coerência com o resto do sistema, e com o tipo de usuário que deverá utilizar o sistema. Requer pensar um pouco out of the box: muitas vezes, as soluções padrão não resolvem o problema adequadamente.

Resumindo: requer dedicação e tempo. Não pensar nisso pode ser o barato que sai caro.

Sugiro, a quem tiver interesse em trabalhar com design de interfaces, dar uma lida no texto do Joel Spolsky sobre tema: User Interface Design for Programmers.

Carlinhos é um programador mediano, morador da cidade de Sampa. Se formou em uma universidade longe de estar na lista das melhores do país, estado ou da cidade. Foi contratado pela empresa ACME.com como trainee. No começo, seus superiores o achavam bastante fraco, com muitas falhas de formação e pouca prática de desenvolvimento de software. Com o tempo, e graças a uma boa ajuda dos colegas e muita boa vontade e esforço, Carlinhos foi evoluindo e se tornando importante para o projeto.

Após um ano de empresa, Carlinhos queria mudar de cargo, afinal tinha 26 anos e ainda era trainee. O RH aceitou a requisição e Carlinhos foi promovido a Analista Júnior. Mas o salário continuou o mesmo, extremamente defasado diga-se de passagem. Depois de mais alguns meses, foi pleitear um aumento. A oferta do RH? 100 reais. Bastante contrariado, avisou que iria sair de férias e procurar emprego. Começou a enviar CVs para varias consultorias. Alguns dias depois, recebeu uma ligação, recebendo uma proposta para trabalhar na empresa ACME.com! Por um salário bastante superior ao anterior!! Esta história é real apesar dos nomes fictícios. Ouvi de uma fonte confiável.

Alguns pontos merecem destaque nesta história. Na pressa de conseguir enviar nomes para a empresa, a consultoria nem ao menos se deu o trabalho de ler de fato o CV do Carlinhos, onde com certeza estava escrito que ele trabalhava na empresa ACME.com. E daí pergunto: se nem isso eles olharam, será que eles olharam de fato o CV do Carlinhos?

Hoje em dia, o mundo da computação vive a ditadura das palavras chaves: EJB, J2EE, JBOSS, C, C++, PHP, ASP, e muitos outros. Boa parte da seleção de profissionais hoje em dia se faz apenas e tão somente a partir destas palavras, sem levar em conta outros aspectos extremamente importantes como experiência, conhecimento de fundamentos de computação, arquitetura, facilidade de aprendizado de novas tecnologias, interesse, comprometimento. Estes requisitos em geral são completamente desprezados. E isto piora quando se sabe que em geral as pessoas que recrutam nestas consultorias não são profissionais de tecnologia e não fazem idéia do que estão falando.

Há alguns meses atrás, recebi dois telefonemas de consultorias oferencedo emprego. Na primeira, a pessoa me perguntou se eu tinha experiência em Java e VB. Respondi que era muito experiente em Java, mas que VB tinha apenas brincado, mas que isso não era problema porque aprenderia fácil. A moça respondeu que tinha que ser extremamente experiente em ambos e me descartou. Não que eu tivesse interesse no trabalho afinal já estava trabalhando e feliz, mas um papo de 15 minutos não deveria ser eliminatório. No segundo telefonema, a moça me fez algumas perguntas sobre conhecimentos em tecnologias específicas: basicamente, uma coleção de palavras chaves que eu tinha que simplesmente dizer se conhecia ou não. A dita cuja tinha dificuldade pra pronunciar algumas das palavras, como middleware por exemplo. Claramente não era a primeira vez que lia a lista. Nunca mais me ligaram.

Quando se sabe o quão criterioso e focado em conhecimentos de teoria, segurança, arquitetura e outros conceitos vitais são os processos seletivos de empresas como Google ou Microsoft ou Apple, eu fico um tanto quanto desanimado quando eu vejo a forma como os processos são nivelados por baixo no Brasil. O profissional de tecnologia é muitas vezes considerado como sendo a peça mais substituível em um processo de desenvolvimento de software, e a qualidade do produto final fica a cargo de camadas e mais camadas de gerenciamento e metodologias que muitas vezes garantem qualidade apenas no papel. Aliás, em geral qualidade é algo que serve apenas para vender, ficar bonito na foto.

Outro dia saindo do trabalho, cruzei com uma mulher parada na frente da catraca/ponto eletrônico da empresa. Achei que ela estava lá simplesmente batendo papo com a recepcionista. Quando passei pela catraca, ouvi ela dizendo “Só mais dois minutos e eu posso passar…”.

Pra bom entendendedor….

Na hora me lembrei de um email que recebi, daqueles estilo corrente, com o tema “Como fingir que está trabalhando”. Basicamente dava dicas do estilo sempre andar com ar apressado e de preferência com várias pastas na mão mesmo que só pra ir ao banheiro, ou deixar a mesa sempre bagunçada, ou sempre deixar o telefone tocar várias vezes antes de atender, e coisas do gênero.

Confesso que eu mesmo já fiz várias coisas dessas.

Fato é que o dia a dia de uma empresa sempre tem duas componentes curiosas: funcionários fingindo que trabalham e chefes fazendo de tudo pra restringir qualquer coisa na esperança de aumentar a produtividade. Quanto mais se restringe pra aumentar a produtividade, mais se finge que se trabalha. Vira um grande teatro. E esse teatro aumenta porque muitas vezes, mesmo que você não tenha nada pra fazer, precisa fingir que está fazendo pra não ser mal visto. Me lembro que uma vez, em uma época de transição de projetos e má organização geral da empresa, fiquei mais de uma semana sem nenhuma tarefa a ser feita. Mesmo assim, se chegasse às 9 em vez de 8h30, pessoas me olhavam com ar de reprovação. Voltar pra casa mais cedo era impensável, mesmo se estivesse a 5 horas na frente do meu computador esperando por uma tarefa e não havia nenhuma num horizonte de 5 dias. E eu passava meu dia inventando tarefas pra não morrer de tédio absoluto. A maioria sem nenhuma ligação com a empresa.

Eu acredito que em ambiente de desenvolvimento de software, controle por ponto, restrições horárias, proibições de acesso a sites e coisas do gênero são a pior coisa que se pode fazer para tentar manter produtividade. Entendo que elas sejam necessárias em alguns casos específicos: restrições de acesso no meu entender são válidas apenas para ambientes que requerem alta segurança, e horários estritos são necessários para pessoas que trabalham com atendimento ao cliente. Mas quando se está desenvolvendo um produto, boa parte do trabalho é solitário, e a meu ver depende muito de inspiração.

E inspiração depende de momento. Tem gente que funciona melhor de manhã, tem gente que funciona melhor a tarde, e outros a noite. Tem gente que prefere trabalhar regularmente 5 horas por dia em vários dias, e conheço pessoas que trabalham por batch: 30 horas ininterruptas. Ou as vezes estamos em dias cheios de problemas pessoais, e as coisas não andam. Daí surge a necessidade de fingir.

Quando falo que sou contra restrições e afins, muitos me falam que o que eu quero é oba-oba, não trabalhar, etc. Muito pelo contrário, eu quero trabalhar e não ter que fingir que estou trabalhando. Mas quero trabalhar no meu ritmo. E como conciliar o meu ritmo com o da empresa ? Metas bem definidas e que devem ser cumpridas. Do ponto de vista do desenvolvimento de um software, uma vez que os requisitos estão bem definidos e cada desenvolvedor sabe o que deve ser feito, pouco importa em qual horário é feito, ou se foi feito em 30 horas seguidas de programação ou em blocos de 5 horas ao longo de 6 dias. Importa que esteja pronto na data, e feito com qualidade. Em termos de quantidade de trabalho, com certeza um sistema de metas agressivas com horários muito flexíveis pode ser muito mais efetivo do que um sistema de horários estritos.

H á alguns meses participei do processo seletivo de uma gigantesca empresa de software multinacional. No meu ponto de vista, uma das melhores. Ao final da entrevista, pude fazer perguntas sobre a empresa. Obviamente perguntei como era o esquema de horários e afins. A resposta foi que por exigência do Ministério do Trabalho, os funcionários tinham que bater ponto (contratação CLT), mas que o ponto era totalmente fantasia. Os desenvolvedores poderiam chegar na hora que preferissem, fazer seu horário, eventualmente trabalhar de casa, eventualmente trabalhar mais em certos dias para não trabalhar em outros. As únicas restrições eram em relação a reuniões de projeto (poucas segundo o entrevistador) e em relação à data de entrega do código. E a coisa simplesmente funciona.

Acho realmente que o melhor modo de estimular a produtividade é instigando o interesse dos colaboradores, estimulando a participação ativa no processo de delineamento de requisitos, oferencedo problemas interessantes a serem resolvidos, e criando um ambiente que estimule a pesquisa por novas tecnologias e idéias. Em outras palavras: acho que oferecer um ambiente cheio de restrições apenas aperfeiçoa a capacidade de teatro dos colaboradores.

Para terminar, sugiro um teste: ofereça a um desenvolvedor que goste do que faz um problema computacional interessante a ser resolvido, determine um deadline e instale-o em uma máquina com MSN/ICQ/GoogleTalk e Orkut liberado. Aposto que em 99% dos casos ele irá esquecer a existência de todos esses sites/programas enquanto o problema não for resolvido.

Estava a conversar com um amigo acerca de certificações, e achei que seria interessante colocar aqui o que penso a respeito, com o objetivo de fomentar uma discussão a respeito da importância das mesmas. Pensando um pouco mais, achei interessante falar sobre cursos também, que têm se mostrado um tema polêmico em algumas conversas.

Primeiro vamos falar de cursos: para mim cursos são ótimos para pessoas com pouca experiência, e com necessidade de obter uma rápida introdução a uma determinada tecnologia. Se a pessoa realmente quiser colocar em seu currículo que domina uma tecnologia, não basta ter 30 certificados de conclusão de curso, tem que desenvolver projetos variados fazendo uso da tecnologia.Desta forma, sugiro que se você tem interesse em aprender uma tecnologia nova e tiver condições, faça um curso sim, mas planeje algum tempo após o curso para desenvolver pequenos projetos que exercitem os diversos aspectos do que você acabou de aprender. De qualquer forma, se você tiver tempo e força de vontade, talvez você possa pular o curso, mas nunca o exercício da tecnologia.

Agora, a respeito de certificações. No meu entender, certificações são fundamentais atividades como DBA, administradores de rede e afins. Mas para uma linguagem de programação, acredito ser totalmente dispensável, exceto para pessoas com pouca experiência. Se eu avaliar um currículo para estagiário, e este possuir uma certificação em programação, certamente darei um crédito maior do que um outro que não possua a certificação. Mas em se tratando de profissionais experientes, o que mais importa é a sua experiência, e não o seu certificado. Acredito que um certificado de programação consiga avaliar o conhecimento da estrutura da linguagem, mas não a capacidade do programador de fazer uso de suas funcionalidades, nem tampouco sua habilidade como programador.

De uma forma geral, no que diz respeito a cursos e certificações, a mensagem que quero deixar é que não é possível atestar a competência de um desenvolvedor atavés destas ferramentas. A experiência é muito mais importante.

“There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.”

Por Bjarne Stroustrup, criador da linguagem C++, em entrevista à revista online TechReview do MIT.

Gosto bastante também da seguinte crítica ao processo de desenvolvimento de softwares hoje em dia:

“I think the real problem is that ‘we’ (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but–so often–it’s not enough.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just ’sort of evolved’ into something minimally acceptable…”

Sim, sim, eu sei…não estou com tempo pra escrever.

E olha que eu tenho alguns temas em mente: cluster em linux, heatbeat, linguagens de programação.
Enfim…quem sabe no feriado

Enquanto isso, leiam este artigo do Joel Spolsky sobre como se encontrar bons desenvolvedores para contratação.

Em vários outros posts anteriores, eu comentei sobre a dificuldade de se desenvolver aplicativos web em CSS, Javascript e HTML que fossem totalmente compatíveis com todos os navegadores disponíveis.

Realmente, esta tarefa requer bastante paciência e eu até entendo que desenvolvedores mais preguiçosos ou com deadlines mais apertados e com clientes bem segmentados resolvam focar seu desenvolvimento para apenas um navegador (em geral, para minha infelicidade, IE).

Atualmente existe alguns movimentos que visam a adoção de padrões por esses navegadores, para melhorar a vida de todos. Um deles é o projeto Webstandards. No site deles, existe um teste que analisa a compatibilidade do seu navegador com os padrões standards. O teste (que pode ser executado aqui) consiste numa página que usa somente CSS e DIVs para desenhar uma carinha. É possível ver o resultado gerado pelo seu navegador e o resultado esperado. Para efeito de comparação, seguem abaixo os resultados obtidos. Bastante ilustrativo.

Como deveria ser (uma carinha feliz):

Como é no Firefox (carinha tomou um LSD no dia anterior):

Como é no IE (carinha passou por uma rebelião do PCC):

A idéia deste post surgiu das duas reclamações que o Miguel já fez neste blog a respeito da falta de documentação em projetos de Software Livre (uma destas reclamações está aqui) e de algumas conversas que tive com ele sobre este assunto baseadas na recente experiência que estou tendo no meu trabalho.

Bom, antes de mais nada, concordo com o Miguel de que falta documentação na maior parte dos projetos de software livre que eu já vi. Quer dizer, depende do que nós estamos acostumados a chamar de documentação. O meu referencial de documentação de um projeto vem dos conhecimentos de Engenharia de Software que eu tenho e da vivência com outras Engenharias. Deste ponto de vista, na minha opinião, documentação é tudo aquilo que te ajuda, de alguma forma, a explicar um sistema, como ele funciona, quais são suas funcionalidades e, talvez o mais importante, como usá-lo de uma maneira correta e eficiente, ou seja, para que o sistema serve.

Acho que a grande falha neste sentido para muitos projetos de software livre está no fato de que muitas pessoas da comunidade acreditam que a documentação é o código-fonte, afinal, que melhor maneira haveria para obter informações a respeito de um sistema do que simplesmente poder ver como o sistema funciona nos mínimos detalhes? A falha neste pensamento, comparado ao que eu disse no parágrafo anterior, está na palavra “ajuda”. A documentação deveria ajudar a entender o sistema e olhar o código fonte nem sempre ajuda muito no início. Em sistemas grandes como o Eclipse, pode-se demorar uma semana ou mais para se pegar o “jeito” e conseguir, a partir de então, obter informações relevantes do sistema a partir do código-fonte. Em projetos grandes, uma semana pode não ser muito tempo, mas isto inibe, por exemplo, que uma pessoa que nunca tenha feito um plugin para Eclipse se aventure a fazer um plugin que lhe pareça útil… simplesmente porque o tempo que ela vai gastar para entender a arquitetura do sistema lhe dá apenas duas opções: ou ela vai utilizar uma parte do seu tempo livre para entender o funcionamento do sistema ou vai se virar sem a funcionalidade que ela queria implementar e, provavelmente, distribuir gratuitamente para uso-fruto do resto da comunidade.

Outra questão importante é: se há documentação, muitas vezes ela não é de fácil acesso. É muito comum os sites que hospedam projetos de software livres terem estruturas complicadas, pouco amigáveis. Apesar de eu achar este um detalhe menor, é importante citá-lo também, pois isso leva com que pessoas que trabalham com software livre se comportem de uma maneira diferente de pessoas que, por exemplo, trabalham com software proprietário.

Quando eu programava em tecnologias proprietárias, minha maior fonte de referência não era o Google. Era muito mais fácil achar referências e soluções para meus problemas na própria documentação gerada pela empresa desenvolvedora do sistema. Tive esta experiência, por exemplo, com Visual Basic 6. Não quero aqui discutir as virtudes ou não desta linguagem e muito menos as virtudes ou não da Microsoft (isto dariam vários outros posts e este já vai ficar grande o suficiente). No entanto, a Microsoft fornece uma documentação muito completa, rica em exemplos e de fácil navegação e busca. Simplesmente isto fazia com que eu dificilmente recorresse a sites específicos a respeito de VB6, ou a fóruns ou ao próprio Oráculo, digo, Google. Isto também faz com que VB6 seja, ainda hoje, uma das linguagens mais conhecidas e mais utilizadas no desenvolvimento de sistemas, mesmo com todas as suas limitações e com o fim de suporte oficial da Microsoft à linguagem.]

Em compensação, todas as vezes que eu trabalho com software livre, “Google is my friend!”. Gosto das listas de discussão também, mas acho que elas são mais complicadas de serem utilizadas, pois existe toda uma etiqueta para participação de listas, o que inclui a leitura dos FAQs e perguntas antigas das listas, o que geralmente eu não tenho muita paciência para fazer. De qualquer forma, poderíamos dizer que neste caso a documentação não está escrita formalmente. Se ela existe, é difusa e esta mal catalogada (por melhor que o Google seja, ele não pode ser utilizado como catálogo de nada, até porque o objetivo dele não é este, por enquanto). Isto, na minha opinião, acaba inibindo alguns novos desenvolvedores a experimentarem o software livre. A filosofia de que a documentação é o código-fonte, para estas pessoas, não funciona.

Os mais puristas em relação ao modelo de desenvolvimento do software livre poderão pensar que eu estou exagerando, e talvez esteja mesmo. Mas eu queria chamar atenção para o fato de que talvez um processo mais elaborado de geração de documentação poderia fazer com que projetos de software livre fossem mais bem vistos por desenvolvedores de uma forma geral e pelas corporações também (afinal, hoje grandes empresas também têm papel decisivo no desenvolvimento de projetos de software livre).

Não estou dizendo também que se deva adotar um processo formal de qualidade de software no desenvolvimento de software livre. Este esquema, na minha opinião, não funciona com o modelo de desenvolvimento criado pelas comunidades de software livre. Um processo exagerado de documentação certamente desmotivaria os colaboradores dos projetos livres, mas alguns controles, como os criados, por exemplo, pelo Gforge, poderiam ser interessantes. Isto sem levar em conta alguns argumentos interessantes da comunidade de software livre para a ausência total de documentação nos projetos de software livre. Algumas que eu acho interessante e faço questão de comentar:

• Software de qualidade não necessariamente é feito com processos de qualidade e nem todo software feito com processo de qualidade tem qualidade. Isto é uma verdade indiscutível.
• Processos de qualidade de software como o CMMI focam boa parte do trabalho na definição dos processos pois se a empresa ou o grupo de desenvolvimento tiverem os processos bem definidos, isto significa que, teoricamente, a saída de uma pessoa do grupo e a sua substituição por outra pessoa não deveria interferir na qualidade do software produzido. Isto faz com que as pessoas sejam transformadas em meros recursos, o que, definitivamente, não é a idéia das comunidades de desenvolvedores de software livre, onde os desenvolvedores são os principais atores.
• Espera-se que a comunidade de software livre tenha colaboradores bons. E uma pessoa que não seja boa o suficiente para ler um código-fonte e entendê-lo não agregará nenhum valor ao movimento. Isto, na minha opinião, é uma verdade pela metade. Uma das grandes batalhas de um dos principais representantes do mundo de software livre, o Linux, é que ele seja um sistema operacional mais aceito e utilizado mundialmente. E, para que isto aconteça, é necessário, antes de mais nada, que o sistema seja fácil de usar e seja entendido por pessoas que não fazem nem idéia do que seja um código-fonte. Qual é a melhor maneira de se fazer entender neste caso? Eu acho que uma boa documentação poderia ajudar bastante nesta hora.
• Na comunidade de software livre, boa parte dos problemas que seriam resolvidos com processos de qualidade de software são resolvidos pelo mantenedor do projeto. Sem dúvida nenhuma, o mantenedor é uma figura crucial em projetos de software livre e ele é o responsável, como o próprio nome diz, pelo bom andamento do projeto. Dizer que o processo de desenvolvimento de software livre não possui nenhum processo formal de qualidade pode até ser verdade, mas isso não significa que o mantenedor e seus colaboradores não tenham que definir funcionalidades, recursos, estimar tempo de desenvolvimento e definir milestones e releases do produto. Tudo isto também acontece com software livre.

Em suma, acho que o que talvez falte para o software livre seja pegar algumas poucas idéias dos processos complexos de qualidade de software e tentar aplicar estas idéias de uma forma apropriada à sua realidade. Sei que cada projeto é um caso diferente e que as regras não seriam universais, mas alguns conceitos poderiam ser usados para tentar ajudar a vida não só dos desenvolvedores, mas também dos usuários comuns que queiram propagar a filosofia de ser livre.

O artigo The Joel Test: 12 Steps to Better Code propõe um pequeno teste, transcrito abaixo, para verificar a qualidade do seu ambiente de desenvolvimento.Apesar de simples, aborda pontos importantes para qualquer ambiente de desenvolvimento, e parece um bom ponto de partida para uma avaliação básica.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?