CORPORATE
Coluna do Maddog
Procura-se
Precisamos de mais engenheiros de software com qualidade.
V
oltei recentemente da fantástica conferência
LinuxFest Northwest 2009, em Bellingham,
no estado de Washington, EUA. É uma cidadezinha ao norte de Seattle que abriga pessoas bem
diversas, desde autodenominados “hippies anciões”
até gente de software que fugiu de Redmond para
uma vida mais calma. No voo de volta, que saiu do
aeroporto de Bellingham, sentei-me ao lado de um
cavalheiro “aproximadamente da minha idade”.
Quando o cumprimentei, ele respondeu com um
leve sotaque escocês.
Nosso papo chegou aos nossos trabalhos: eu falei sobre meu trabalho de “vender Software Livre”, e ele me
contou de seu trabalho como engenheiro de sistemas
na Chevron. Conforme nossa conversa avançava, ele
discutiu seus esforços para usar produtos da Microsoft
e o número de vezes que eles travaram. Sua voz ficou
mais calma quando ele falou de como os sistemas Unix
e Linux são muito mais estáveis e de como ele gosta
bem mais deles.
Depois, ele disse algo que eu não escutava há muito
tempo: “Claro que para aplicações de missão crítica,
missão realmente crítica, o tipo de aplicação que precisa funcionar 100%, jamais usaríamos computadores
controlados por software. A hidráulica é o certo. Software é simplesmente muito pouco confiável”.
Meu rosto ficou vermelho – afinal, minha vida
gira em torno de softwares e computadores digitais.
Sistemas que ajudei a criar já levaram astronautas à
lua, gerenciam grandes depósitos e cuidam de outros trabalhos de “missão crítica”. Mas sentado lá e
escutando as histórias de como a Chevron perdeu
US$ 60 milhões por dia por causa de uma pessoa do
software que não testou seu código, lembrei-me de
alguns projetos em que os testes pareciam ser uma
questão “para depois”.
Testando
Maddog autografou revistas no estande da Linux Magazine na
LinuxFest Northwest 2009.
26
Eu me lembro de uma vez ter recebido uma cópia de
um software de teste de campo e ter tentado instalá-lo
no meu computador, mas sem sucesso. Acreditando
ser por causa de alguma configuração particular do
meu hardware, examinei o código-fonte do programa
de instalação, que felizmente estava escrito numa linguagem de script, e vi que era impossível entender os
fontes. Em outras palavras, o engenheiro que escreveu
o código não havia tentado executá-lo uma única vez.
http://www.linuxmagazine.com.br
Maddog | CORPORATE
Imediatamente, fui até o escritório do engenheiro e
o adverti de que ele havia posto em risco todo o teste
de campo do produto e, portanto, todo o prazo de finalização do software. As empresas e as vidas das pessoas
dependiam do nosso cumprimento daqueles prazos, e
apesar de não querermos comercializar um produto
defeituoso, era importante cumprir os prazos.
Em outra ocasião, determinamos – apesar de não ter
sido falha da Digital – que 12 mil placas de memória
tinham um chip defeituoso, o que significava que todas
as 12 mil precisariam ser retornadas e remanufaturadas.
Naquela época, o preço da memória era próximo de
US$ 1.000 por megabyte, então não apenas havia o
risco potencial de US$ 12 milhões em perdas para a
empresa, como também o de um atraso na entrega do
novo sistema.
Uma solução potencial foi fazer um strobe da memória a cada poucos milissegundos; porém, o soft­ware
não conseguiria dizer se a placa de algum sistema
particular tinha esse defeito ou se estava operando
normalmente. Então, esses sistemas modelados específicos teriam que fazer o strobe da memória enquanto
estivessem em uso.
Um engenheiro de hardware propôs que o Ultrix
(nosso sistema Unix na época) simplesmente incluísse
seu software de strobe no kernel, “solucionando” assim
o problema. Eu disse que o problema estava no hardware, e não havia garantias de que esse hardware continuaria com o Ultrix. Algum dia ele poderia rodar do
VAX/Eln, um sistema operacional de tempo real usado
para várias operações de missão crítica.
Eu disse que talvez quando os pinos de controle do
reator nuclear precisassem ser abaixados, o VAX/Eln
pararia alguns milissegundos para fazer o strobe da
memória, mas quando continuasse baixando os pinos,
o reator nuclear seria uma pilha de cinzas.
O grupo de hardware acabou remanufaturando as
placas de memória.
Engenharia de software de qualidade é um trabalho
sério. Precisamos de mais dela. n
Jon ‘maddog’ Hall é presidente da Linux International, instituição internacional dedicada a promover o Linux e o Software Livre. Maddog viaja o
mundo ministrando palestras e debatendo com decisores sobre o uso do
Software Livre em âmbito tanto corporativo quanto comunitário.
OSPRE
R
Linux Magazine #56 | Julho de 2009
Linux
Professional
Institute
27