Eles escrevem as coisas certas

Enquanto o ônibus espacial de 120 toneladas está rodeado por quase 4 milhões de libras de combustível de foguete, exalando gases nocivos, visivelmente impaciente para desafiar a gravidade, seus computadores de bordo assumem o comando.

Eles escrevem as coisas certas

O material certo entra em ação em T-menos 31 segundos.

Enquanto o ônibus espacial de 120 toneladas está rodeado por quase 4 milhões de libras de combustível de foguete, exalando gases nocivos, visivelmente impaciente para desafiar a gravidade, seus computadores de bordo assumem o comando. Quatro máquinas idênticas, rodando software idêntico, extraem informações de milhares de sensores, tomam centenas de decisões de milissegundos, votam em todas as decisões, verificam uns com os outros 250 vezes por segundo. Um quinto computador, com software diferente, fica à disposição para assumir o controle, caso os outros quatro não funcionem bem.

Em T-menos 6,6 segundos, se as pressões, bombas e temperaturas forem nominais, os computadores dão a ordem para acender os motores principais do ônibus espacial - cada um dos três motores disparando com intervalo de exatamente 160 milissegundos, despejando toneladas de combustível líquido super-resfriado em câmaras de combustão, o navio balançando em sua plataforma de lançamento, preso ao solo apenas por parafusos. À medida que os motores principais atingem um milhão de libras de empuxo, seus escapamentos se transformam em diamantes azuis de chama.

Mais de Charles Fishman

  • Cientistas descobrem o maior e mais antigo corpo d'água da existência - no espaço
  • Como é ser um arquiteto do Walmart
  • O caminho para a resiliência: como a inovação não científica salvou a Marlin Steel

Então, e somente então, em T-menos zero segundos, se os computadores ficarem satisfeitos que os motores estão funcionando corretamente, eles darão a ordem para acender os foguetes propulsores sólidos. Em menos de um segundo, eles atingem 6,6 milhões de libras de empuxo. E, naquele exato momento, os computadores dão a ordem para que os parafusos explosivos explodam e 4,5 milhões de libras de espaçonave se elevam majestosamente de sua plataforma de lançamento.



É uma exibição incrível de proezas de hardware. Mas nenhum ser humano aperta um botão para que isso aconteça, nenhum astronauta usa um joystick para colocar o ônibus espacial em órbita.

A coisa certa é o software. O software dá as ordens para girar os motores principais, executando o giro dramático que o ônibus espacial faz logo depois de passar pela torre. O software regula os motores para garantir que a nave não acelere muito rápido. Ele mantém o controle de onde o ônibus espacial está, ordena que os impulsionadores do foguete sólido se afastem, faz pequenas correções de curso e, após cerca de 10 minutos, coloca o ônibus espacial em órbita a mais de 160 quilômetros de altitude. Quando o software está satisfeito com a posição do ônibus espacial no espaço, ele ordena que os motores principais desliguem - a gravidade zero começa e tudo começa a flutuar.

Mas a quantidade de trabalho que o software realiza não é o que o torna notável. O que o torna notável é como o software funciona bem. Este software nunca falha. Ele nunca precisa ser reiniciado. Este software está livre de erros. É perfeito, tão perfeito quanto os seres humanos o alcançaram. Considere estas estatísticas: as últimas três versões do programa - cada 420.000 linhas - tiveram apenas um erro cada. As últimas 11 versões deste software tiveram um total de 17 erros. Os programas comerciais de complexidade equivalente teriam 5.000 erros.

Este software é o trabalho de 260 mulheres e homens em um prédio de escritórios anônimo em frente ao Centro Espacial Johnson em Clear Lake, Texas, a sudeste de Houston. Eles trabalham para o grupo de ônibus espacial a bordo, um ramo da divisão de sistemas de missão espacial da Lockheed Martin Corps, e suas proezas são mundialmente conhecidas: o grupo de software do ônibus espacial é um dos apenas quatro grupos no mundo a ganhar o cobiçado nível 5 do ranking dos governos federais Software Engineering Institute (SEI) uma medida da sofisticação e confiabilidade da maneira como eles fazem seu trabalho. Na verdade, o SEI baseou seus padrões em parte ao observar o grupo de ônibus espaciais a bordo fazer seu trabalho.

O grupo escreve software tão bom porque é assim que tem que ser bom. Cada vez que o ônibus espacial é acionado, seu software está controlando um equipamento de US $ 4 bilhões, a vida de meia dúzia de astronautas e os sonhos da nação. Mesmo o menor erro no espaço pode ter consequências enormes: o ônibus espacial em órbita viaja a 17.500 milhas por hora; um bug que causa um problema de cronometragem de apenas dois terços de segundo coloca o ônibus espacial a 5 km do curso.

A NASA sabe como o software deve ser bom. Antes de cada voo, Ted Keller, o gerente técnico sênior do grupo de ônibus espacial a bordo, voa para a Flórida, onde assina um documento certificando que o software não colocará o ônibus em perigo. Se Keller não puder ir, uma linha formal de sucessão dita quem pode assinar em seu lugar.

Bill Pate, que trabalhou no software de voo espacial nos últimos 22 anos, [/ url] diz que o grupo entende o que está em jogo: se o software não for perfeito, algumas das pessoas com quem vamos às reuniões podem morrer.

O software é tudo. (Também é uma merda.)

Na história da tecnologia humana, nada se tornou tão essencial tão rápido quanto o software.

Praticamente tudo - desde o sistema monetário internacional e grandes usinas de energia até liquidificadores e fornos de micro-ondas - funciona com software. Em edifícios de escritórios, os elevadores, as luzes, a água, o ar condicionado são controlados por software. Nos carros, a transmissão, o ponto de ignição, o air bag e até as travas das portas são controlados por software. Na maioria das cidades, o mesmo acontece com os semáforos. Quase toda comunicação escrita que é mais complicada do que um cartão postal depende de software; toda conversa telefônica e toda entrega de pacote noturno exige isso.

O software é tudo. Também é uma merda.

É como a civilização pré-suméria, diz Brad Cox, que escreveu o software para o computador Steve Jobs NeXT e é professor da George Mason University. A forma como construímos software está no estágio de caçador-coletor.

John Munson, engenheiro de software e professor de ciência da computação na Universidade de Idaho, não é tão generoso. Arte nas cavernas, diz ele. É primitivo. Supostamente ensinamos ciência da computação. Não há ciência aqui.

O software pode impulsionar o mundo pós-industrial, mas a criação de software continua sendo um comércio pré-industrial. De acordo com os estudos da SEI, quase 70% das organizações de software estão presas nos primeiros dois níveis da escala de sofisticação da SEI: caos e um pouco melhor do que o caos. A situação é tão grave que alguns pioneiros de software de empresas como a Microsoft se separaram para ensinar a arte da criação de software (veja Abandone e Codifique-me Vinte!)

Mark Paulk, um membro sênior do SEI Technical, diz que o sucesso do software torna suas fraquezas ainda mais dramáticas. Desenvolvemos produtos de software extremamente complexos e poderosos. Somos extremamente dependentes disso, diz Paulk. Mesmo assim, todos reclamam como o software é ruim, com todos os defeitos. Se você comprou um carro com 5.000 defeitos, você ficaria muito chateado.

Nesse pântano de software, o grupo de transporte a bordo se destaca como uma exceção. Dez anos atrás, o grupo do ônibus espacial era considerado de classe mundial. Desde então, cortou sua própria taxa de erro em 90%.

Para ser tão bom, o grupo de ônibus espacial a bordo tem que ser muito diferente - a antítese dos programadores de software de hóquei em pizza e patins que acordaram a noite toda que capturaram a imaginação do público. Para ser tão bom, o grupo de transporte a bordo tem que ser muito comum - indistinguível de qualquer empresa criativa focada, disciplinada e gerida metodicamente.

Na verdade, o grupo oferece um conjunto de lições de livros que se aplicam igualmente a programadores, em particular, e produtores, em geral. Um olhar sobre a cultura que eles criaram e o processo que eles aperfeiçoaram mostra o que a escrita de software deve se tornar para que o software cumpra sua promessa e ilustra o que quase qualquer operação baseada em equipe pode fazer para impulsionar seu desempenho e alcançar resultados quase perfeitos .

Software para adultos

O inferno do transporte marítimo continuou hoje. Moer, moer, moer. Nós nunca vamos conseguir. Eu já disse isso? Por que sempre subestimamos nossas programações de envio? Eu simplesmente não entendo. In às 9h30; às 23h30 Dominos para o jantar. E três Cocas diet.

Não, não é o grupo de transporte a bordo. É o Microserf de Douglas Coupland, um relato fictício real da vida na via rápida do software. E é a imagem dominante do mundo do desenvolvimento de software: os membros da Geração X exibem camisetas e olhares distraídos, comprimindo muito código heróico em muito pouco tempo; patins e bicicletas de montanha dobradas nos cantos; caixas de pizza e copos Starbucks descartados em salas de conferência; duelos de músicas de Smashing Pumpkins, Alanis Morrisette and the Fugees. É o mundo que se tornou famoso, romântico e até mesmo inevitável por histórias da Sun Microsystems, Microsoft e Netscape.

Por que o Chrome está funcionando tão lento?

Não é a história do grupo de ônibus espaciais a bordo. Seus aposentos são um estudo para pedestres de colarinho branco. O mais impressionante é como eles parecem comuns. Além de algumas lembranças ocasionais do ônibus espacial, você pode estar nos escritórios de qualquer pequena empresa ou agência governamental. Todos têm seu próprio pequeno escritório, e os escritórios têm escrivaninhas, PCs e poucos artefatos pessoais. As pessoas usam roupas moderadamente elegantes para trabalhar, elegantes, mas nada chamativas, certamente nada sujo.

É estritamente um tipo de lugar de 8 às 5 - até tarde da noite, mas eles são a exceção. Os programadores são intensos, mas discretos. Muitos deles trabalharam durante anos para a IBM (que possuía o grupo de ônibus espaciais até 1994) ou diretamente no software do ônibus espacial. Eles são adultos, com cônjuges e filhos e vivem além de seu notável programa de software.

Essa é a cultura: o grupo de transporte a bordo produz software para adultos, e a maneira como eles fazem isso é sendo adultos. Pode não ser sexy, pode não ser uma viagem do ego de codificação - mas é o futuro do software. Quando você estiver pronto para dar o próximo passo - quando você tiver que escrever um software perfeito em vez de um software que seja bom o suficiente - então é hora de crescer.

Ted Keller, 48, o gerente técnico sênior do grupo, parece e soa como o diretor de uma pequena escola particular. É trabalho de Keller garantir que o software seja entregue no prazo, com todos os seus recursos, sem levar em conta as disputas territoriais. Ele é um homem compacto e careca, um pouco intrometido e exigente, qualidades que qualquer astronauta consideraria reconfortantes. Ele tem um senso de humor gentil e geek, não tanto com estranhos, mas com sua turma.

Ele foi divulgado em uma reunião entre membros do grupo de software e seus colegas da NASA. É realizado em uma pequena sala de conferências abarrotada com 22 pessoas e um retroprojetor. Várias vezes, do fundo da sala, Keller faz um comentário irônico sobre a velocidade de entrega do código, ou o detalhe de algumas especificações, e a sala se ilumina de tanto rir.

Caso contrário, a reunião de uma hora é sóbria e reveladora, uma breve janela sobre a cultura. Por um lado, 12 das 22 pessoas na sala são mulheres, muitas delas gerentes seniores ou pessoal técnico sênior. O grupo de ônibus espaciais a bordo, com sua estabilidade e profissionalismo, parece particularmente atraente para programadoras mulheres.

por que o mercado está baixo hoje

Por outro lado, é um exercício de ordem, detalhe e reiteração metódica. A reunião é uma apresentação clássica da NASA - um ensaio para uma reunião quase idêntica a várias semanas de distância. Consiste em percorrer um enorme pacote de dados e visualizações - gráficos que descrevem o andamento e o status do software linha por linha. Exceto pelos comentários ocasionais de Keller, o tom é profissional, quase formal, a visão - gráficos passando tão rápido quanto podem ser lidos, um borrão de siglas, gráficos e tabelas.

O que está acontecendo aqui é o tipo de trabalho básico que define o impulso para a perfeição do grupo - um impulso que é agressivamente intolerante com figurões impulsionados pelo ego. Na cultura do grupo ônibus espacial, não existem programadores superestrelas. Toda a abordagem de desenvolvimento de software é intencionalmente projetada para não depender de nenhuma pessoa em particular.

Mais deste problema


  • Por que o ônibus espacial é canhoto
  • Ele transforma ideias em empresas - na velocidade da rede
  • Largue e codifique-me vinte
  • O que vem depois do sucesso?
  • O vírus do marketing

E a cultura é igualmente intolerante com a criatividade, a codificação individual floresce e os estilos que são a assinatura do mundo do software noturno. As pessoas perguntam: esse processo não sufoca a criatividade? Você tem que fazer exatamente o que o manual diz, e você tem alguém olhando por cima do seu ombro, diz Keller. A resposta é, sim, o processo sufoca a criatividade.

E esse é precisamente o ponto - você não pode ter pessoas trabalhando como freelancers em códigos de software que voam em uma espaçonave, e então, com a vida de outras pessoas dependendo disso, tente consertá-lo assim que estiver em órbita. Houston, nós temos um problema, pode ser um bom filme; não é maneira de escrever software. As pessoas precisam canalizar sua criatividade para mudar o processo, diz Keller, não para mudar o software.

As rígidas restrições que o grupo pratica podem tornar o canto da sereia do mundo do software rock n roll difícil de resistir. Quinn Larson, 34, trabalhou no software do ônibus espacial por sete anos quando saiu em janeiro passado para trabalhar para a Micron Technology em Boise, Idaho, automatizando a fabricação de chips de memória Microns.

Na Micron, Larson recebeu a tarefa de automatizar as serras que cortam wafers de cavacos acabados no tamanho certo. Dane-se o programa, você destrói os valiosos wafers.

Cabia a mim decidir o que fazer, diz Larson. Não houve reuniões, não houve manutenção de registros. Ele tinha liberdade; foi um verdadeiro chute. Mas, na maneira de pensar de Larson, a cultura não se concentrava, bem, nas coisas certas. A velocidade ali era o mais importante, diz ele. Os engenheiros diriam: essas são nossas principais prioridades e precisamos resolvê-las o mais rápido possível. Mas a impressão que Larson teve foi que os engenheiros não pareciam muito preocupados com o quão bem o software acabado realmente funcionava. Basicamente, eles queriam um software rápido - basta colocá-lo no mercado.

Larson voltou ao grupo de transporte em meados de agosto. As pessoas aqui são do mais alto calibre, disse ele em seu primeiro dia de volta a Clear Lake.

É o processo

Como eles escrevem as coisas certas?

A resposta é: é o processo. A criação mais importante do grupo não é o software perfeito que eles escrevem - é o processo que eles inventaram que escreve o software perfeito.

É o processo que permite que eles vivam uma vida normal, estabeleçam prazos que realmente cumpram, permaneçam dentro do orçamento, entreguem software que faça exatamente o que promete. É o processo que define o que esses programadores nas planícies do sudeste do subúrbio de Houston sabem que todo mundo no mundo do software ainda está procurando. É o processo que oferece um modelo para qualquer empresa criativa que está procurando um método para produzir qualidade consistente - e melhorar consistentemente.

O processo pode ser reduzido a quatro proposições simples:

1. O produto é tão bom quanto o plano para o produto.No grupo de transporte a bordo, cerca de um terço do processo de escrita do software acontece antes que alguém escreva uma linha de código. A NASA e o grupo Lockheed Martin concordam nos mínimos detalhes sobre tudo o que o novo código deve fazer - e eles colocam esse entendimento no papel, com o tipo de especificidade e precisão normalmente encontrada em projetos. Nada nas especificações é alterado sem acordo e entendimento de ambos os lados. E nenhum codificador altera uma única linha de código sem as especificações delineando cuidadosamente a alteração. Faça o upgrade do software para permitir que o ônibus espacial navegue com os Satélites de Posicionamento Global, uma mudança que envolve apenas 1,5% do programa, ou 6.366 linhas de código. As especificações para essa mudança têm 2.500 páginas, um volume mais espesso que uma lista telefônica. As especificações do programa atual preenchem 30 volumes e têm 40.000 páginas.

Nossos requisitos são quase um pseudo-código, diz William R. Pruett, que gerencia o projeto de software para a NASA. Dizem, você tem que fazer exatamente isso, fazer exatamente assim, dada essa condição e essa circunstância.

Este cuidadoso processo de design por si só é suficiente para colocar a organização do ônibus espacial em uma classe à parte, diz John Munson, da Universidade de Idaho. A maioria das organizações se lança até mesmo em grandes projetos sem planejar o que o software deve fazer em detalhes semelhantes a um blueprint. Portanto, depois que os programadores já começaram a escrever um programa, o cliente está mudando ativamente seu design. O resultado é uma programação caótica e cara, em que o código é constantemente alterado e infectado com erros, mesmo enquanto está sendo projetado.

A maioria das pessoas opta por gastar seu dinheiro do lado errado do processo, diz Munson. No ambiente de software moderno, 80% do custo do software é gasto depois que o software é escrito pela primeira vez - eles não acertam na primeira vez, então gastam tempo açoitando-o. No ônibus espacial, eles acertam da primeira vez. E eles não mudam o software sem mudar o projeto. É por isso que seu software é tão perfeito.

2. O melhor trabalho em equipe é uma rivalidade saudável.Dentro do grupo de software, existem subgrupos e subculturas. Mas o que poderia ser uma divisão política em outras organizações é, na verdade, uma parte crítica do processo.

O grupo central se divide em duas equipes principais: os codificadores - as pessoas que sentam e escrevem o código - e os verificadores - as pessoas que tentam encontrar falhas no código. As duas unidades se reportam a chefes separados e funcionam sob ordens de marcha opostas. O grupo de desenvolvimento deve fornecer código completamente livre de erros, tão perfeito que os testadores não encontram nenhuma falha. O grupo de teste deve golpear o código com cenários de vôo e simulações que revelam o máximo de falhas possível. O resultado é o que Tom Peterson chama de relacionamento amigável e adversário.

Eles estão competindo para ver quem vai encontrar os erros, diz Keller. Às vezes, eles lutam como cães e gatos. Os desenvolvedores querem detectar todos os seus próprios erros. Os verificadores ficam bravos, ‘Ei, desista! Você está tirando nosso tempo para testar o software! & Apos;

Os desenvolvedores até começaram suas próprias inspeções formais do código em sessões cuidadosamente moderadas, uma revisão rigorosa que eles esperam confundir os testadores. Os verificadores, por sua vez, argumentam que merecem crédito por alguns erros encontrados antes mesmo de iniciarem o teste. Da perspectiva do grupo de verificação, diz Pat McLellan, um gerente sênior, estamos cientes de que, se não houvesse um grupo de verificação independente, os desenvolvedores tenderiam a ser mais relaxados. Só a presença do nosso grupo os torna mais cuidadosos.

Os resultados dessa rivalidade amigável: o grupo de ônibus espaciais agora encontra 85% de seus erros antes do início do teste formal e 99,9% antes de o programa ser entregue à NASA.

3. O banco de dados é a base do software.Existe o software. E há os bancos de dados sob o software, dois bancos de dados enormes, enciclopédicos em sua abrangência.

Um é o histórico do próprio código - com cada linha anotada, mostrando cada vez que foi alterado, por que foi alterado, quando foi alterado, qual foi o propósito da alteração, quais documentos de especificações detalham a alteração. Tudo o que acontece com o programa é registrado em sua história mestre. A genealogia de cada linha de código - o motivo pelo qual é do jeito que é - está instantaneamente disponível para todos.

O outro banco de dados - o banco de dados de erros - é uma espécie de monumento à maneira como o grupo de ônibus espaciais a bordo realiza seu trabalho. Aqui estão registrados todos os erros cometidos ao escrever ou trabalhar no software, remontando a quase 20 anos. Para cada um desses erros, o banco de dados registra quando o erro foi descoberto; qual conjunto de comandos revelou o erro; quem o descobriu; que atividade estava acontecendo quando foi descoberta - teste, treinamento ou vôo. Ele rastreia como o erro foi introduzido no programa; como o erro conseguiu escapar dos filtros configurados em cada estágio para detectar erros - por que não foi detectado durante o design? durante as inspeções de desenvolvimento? durante a verificação? Finalmente, o banco de dados registra como o erro foi corrigido e se erros semelhantes podem ter escapado pelos mesmos buracos.

O grupo tem tantos dados acumulados sobre como faz seu trabalho que escreveu programas de software que modelam o processo de escrita de código. Como os modelos de computador que prevêem o tempo, os modelos de codificação prevêem quantos erros o grupo deve cometer ao escrever cada nova versão do software. Fiel à regra, se os codificadores e testadores encontrarem poucos erros, todos trabalharão no processo até que a realidade e as previsões coincidam.

Nunca abrimos mão de nada, diz Patti Thornton, uma gerente sênior. Fazemos exatamente o contrário: deixamos que tudo nos incomode.

4. Não conserte apenas os erros - conserte o que quer que tenha permitido o erro em primeiro lugar.

O processo é tão difundido que leva a culpa por qualquer erro - se houver uma falha no software, deve haver algo errado com a forma como está sendo escrito, algo que pode ser corrigido. Qualquer erro não encontrado no estágio de planejamento passou por pelo menos algumas verificações. Por quê? Há algo de errado com o processo de inspeção? Uma pergunta precisa ser adicionada a uma lista de verificação?

É importante ressaltar que o grupo evita culpar as pessoas por erros. O processo assume a culpa - e é o processo que é analisado para descobrir por que e como um erro passou. Ao mesmo tempo, a responsabilidade é um conceito de equipe: ninguém é o único responsável por escrever ou inspecionar o código. Você não é punido por cometer erros, diz Marjorie Seiter, um membro sênior da equipe técnica. Se eu cometer um erro e outros revisarem meu trabalho, então não estou sozinho. Eu não estou sendo culpado por isso.

Ted Keller oferece um exemplo da recompensa da abordagem, envolvendo o braço manipulador remoto do ônibus espacial. Fornecemos software para treinamento da tripulação, diz Keller, que permite aos astronautas manipular o braço e lidar com a carga útil. Quando o braço chegou a um certo ponto, ele simplesmente parou de se mover.

O software estava confuso devido a um erro de programação. Quando o pulso do braço remoto se aproximou de uma rotação completa de 360 ​​graus, cálculos errados fizeram com que o software pensasse que o braço havia passado de uma rotação completa - o que o software sabia estar incorreto. O problema tinha a ver com o arredondamento da resposta para um problema comum de matemática, mas revelou uma cascata de outros problemas.

não pise na minha wiki

Embora isso não fosse crítico, diz Keller, voltamos e perguntamos quais outras linhas de código poderiam ter exatamente o mesmo tipo de problema. Eles encontraram oito dessas situações no código e, em sete delas, a função de arredondamento não foi um problema. Um deles envolveu a rotina de apontamento de antena de alto ganho, diz Keller. Essa é a antena principal. Se tivesse desenvolvido esse problema, poderia ter interrompido as comunicações com o solo em um momento crítico. Isso é muito mais sério.

Da maneira como funciona o processo, não só encontra erros no software. O processo encontra erros no processo.

Apenas um problema de software

O bombardeiro B-2 não voaria em seu vôo inaugural - mas era apenas um problema de software. O novo aeroporto de Denver teve sua abertura com meses de atraso e milhões de dólares acima do orçamento porque seu sistema de manuseio de bagagem não funcionava direito - mas era apenas um problema de software. Nesta primavera, o novo foguete Ariane 5 da Agência Espacial Europeia explodiu em seu lançamento inaugural por causa de um pequeno problema de software. As principais agências do governo federal - do IRS ao Serviço Nacional de Meteorologia - estão repletas de projetos que estão anos atrasados ​​e centenas de milhões de dólares acima do orçamento, muitas vezes por causa de simples problemas de software. O software está se tornando cada vez mais comum e cada vez mais importante, mas não parece estar cada vez mais confiável.

Enquanto o resto do mundo luta com o básico, o grupo de ônibus espacial a bordo se aproxima cada vez mais do software perfeito. É certo que eles têm muitas vantagens sobre o resto do mundo do software. Eles têm um único produto: um programa que pilota uma nave espacial. Eles entendem seu software intimamente e ficam mais familiarizados com ele o tempo todo. O grupo tem um cliente inteligente. E o dinheiro não é a restrição crítica: o orçamento do grupo de US $ 35 milhões por ano é uma fatia trivial do bolo da NASA, mas em uma base de dólares por linha, torna o grupo uma das organizações de software mais caras do país.

E esse é o ponto: o processo de transporte é tão extremo, a busca pela perfeição é tão focada, que revela o que é necessário para alcançar uma execução implacável. As coisas mais importantes que o grupo de transporte faz - planejar cuidadosamente o software com antecedência, não escrever código até que o design esteja completo, não fazer alterações sem suportar projetos, manter um registro totalmente preciso do código - não são caras. O processo nem é ciência do foguete. Sua prática padrão em quase todas as disciplinas de engenharia, exceto engenharia de software.

Colado na parede de uma sala de conferências, um slogan informal do grupo de ônibus espaciais captura a essência de manter o foco no processo: quanto antes você ficar para trás, mais tempo terá para acompanhar.

Charles Fishman (fish@nando.net) é um escritor que mora em Raleigh, Carolina do Norte.