O fato de escrever programas um pouco fora do comum traz algumas conseqüências. Alguns dos seus amigos de trabalho, aqueles que às vezes sentam ao seu lado, não entendem nada do que você está fazendo (e vice-versa). Outros são vistos sussurrando: “Cuidado! É aquele cara ali que programa drivers.”. Essa dificuldade que as outras pessoas têm de entender o que estamos escrevendo, acaba atingindo também os gerentes, diretores e assim por diante. Não que eles fossem culpados disso. Afinal de contas, se eles se interessassem pela área técnica a esse ponto, provavelmente não seriam gerentes, diretores ou seja lá o que for. Isso não é uma regra, mas pelo menos nas empresas onde trabalhei, a minoria dos meus superiores entendiam a complexidade daqueles problemas que acabavam atrasando a entrega de um produto.

A pior das situações é quando um superior pensa que é simples resolver as coisas. Afinal de contas, quando ele programava em COBOL, não havia um problema que ele não resolvesse, e que você provalvelmente estaria fazendo corpo mole ou simplesmente se achando um super astro por resolver os problemas das telas azuis. Eu particularmente acho lindo quando eles perguntam: “Mas você já não resolveu esse problema da tela azul?”, como se houvesse apenas um problema cuja conseqüência é uma tela azul.

Bom, desta forma acho que a opinião de uma reconhecida autoridade no assunto poderia ter alguma influência sobre a opinião destas pessoas. No primeiro capítulo do seu livro Programming The Microsoft Windows Driver Model (2º Edition), Walter Oney dá algumas dicas sobre como uma empresa poderia encarar o desenvolvimento de drivers a fim de obter resultados mais próximos dos esperados. Separei alguns trechos que seguem logo abaixo.

“A triste realidade é que programar WDM é muito difícil, e somente programadores experientes (e caros!) são capazes de fazê-lo bem.”

“O desenvolvimento dos drivers deve iniciar assim que houver uma especificação razoavelmente definida de como o hardware vai trabalhar. Você deveria esperar por modificações na especificação em virtude às desagradáveis descobertas durante o desenvolvimento do driver, …”

“Você também deve esperar que programar drivers leve mais tempo e mais custo que o imaginado inicialmente. Todo programa está sujeito a uma maior demanda de tempo e custo. Uma demanda adicional viria da dificuldade de comunicação entre as pessoas de hardware e software, das ambiguidades na especificação e na documentação do DDK,…”

“Dê atenção em saber como os usuários finais irão instalar seu driver. A maioria dos vendedores de hardware preferem entregar uma instalação customizada em um CD-ROM, e escrever o instalador é um processo longo que pode consumir um programador experiente por várias semanas…”

“O arquivo executável provavelmente incluirá mensagens de texto em um resource especial com múltiplas línguas, e seria uma boa idéia ter uma pessoa treinada para compô-las. (Eu não estou dizendo que seu programador de drivers não possa fazer isto, mas ele pode não ser a melhor escolha.)”

“Finalmente, não trate seus drivers como detalhes sem importância. Ter um bom driver com um suave instalador é no mínimo tão importante quanto a aparência exterior do produto. … Então, uma má escolha por um desenvolvimento barato de driver poderia ter um dramático efeito negativo em poucos anos. Este aviso é especialmente importante para fabricantes de hardware de países em desevolvimento, onde gerentes têm a tendência a procurar por qualquer corte de custos. Eu sugiro que o desenvolvimento de drivers seja em um lugar onde ter decisões baseadas em custos seja inapropriado.”

Talvez eles nunca leiam isso, mas com certeza nos ajuda a respirar fundo e continuar programando. Agora volta a trabalhar porque você não é pago pra ficar navegando na Internet! (Essa também é ótima)…

This entry was posted on Monday, December 11th, 2006 at 11:08 and is filed under Off Topic. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.