flowchart LR
A["jul/1985<br/>memo de Boisjoly<br/>alerta sobre o O-ring"] --> B["27/jan/1986<br/>véspera do lançamento<br/>4 gerentes votam sem<br/>os engenheiros"]
B --> C["28/jan/1986<br/>lançamento<br/>explosão em 73s"]
C --> D["comissão presidencial<br/>'inadequate communication<br/>at NASA'"]
D --> E["2 anos de programa<br/>parado + engenheiros<br/>ganham poder de veto"]
Aula 1: Computação como Sistema Sociotécnico
Computação e Sociedade
1 Challenger — um desastre “técnico”?
Em janeiro de 1985, o engenheiro Roger Boisjoly, da Morton Thiokol, alertou por escrito sobre um problema nos anéis de vedação (O-rings) do foguete Challenger: em baixas temperaturas, o material perde elasticidade e não veda mais a junta do foguete propulsor, deixando escapar gases quentes.
“I am really afraid that if we do not take immediate steps we will place both the flight and the launching pad in serious danger. The consequences would be catastrophic and human lives would be put at risk.” (Van de Poel & Royakkers, 2011, p. 7)
A recomendação técnica era clara: não lançar em temperatura baixa. Na véspera do lançamento de janeiro de 1986, sob pressão organizacional — risco político e financeiro de mais um atraso — quatro gerentes da Thiokol decidiram por voto, sem os engenheiros presentes, recomendar o lançamento. A manhã do lançamento estava quase 4°C abaixo do ponto de congelamento. O Challenger explodiu 73 segundos depois, matando os sete astronautas a bordo — incluindo a professora Christa McAuliffe, a primeira civil selecionada para ir ao espaço, o que tinha atraído atenção de mídia bem acima do normal para aquele lançamento.
A comissão presidencial que investigou o desastre não concluiu “o anel de vedação falhou” — concluiu:
“A Presidential Commission determined that the whole disaster was due to inadequate communication at NASA.” (p. 9)
E o desfecho institucional reforça o ponto: a Thiokol não perdeu o contrato com a NASA, mas a agência mudou como funcionava —
“Engineers were given more of a say in matters. In the future, they will have the power to halt a flight if they had their doubts.” (p. 9)
NotaA pergunta que abre a aula
Se a causa raiz de um dos maiores desastres da história da engenharia não foi um erro técnico isolado, em que sentido isso ainda é um problema de engenharia? A resposta desta aula: porque engenharia — e computação — nunca foi só técnica.
2 Sistemas Sociotécnicos
Computação não é feita só de hardware e software. É um sistema sociotécnico: tecnologia, pessoas, organizações e cultura se influenciam mutuamente — nenhuma delas determina as outras isoladamente.
“We shape our tools and thereafter they shape us”, disse John Culkin numa entrevista com o teórico da mídia Marshall McLuhan (citado em Steen, 2022, p. 29).
Essa ideia de coformação mútua rejeita duas posições mais simples e mais confortáveis, que Steen (2022, p. 30) nomeia explicitamente:
“An instrumental view on technology is mistaken; we cannot use technologies as neutral instruments. A deterministic view is also erroneous; technologies do not determine our behaviours. Rather, the design and usage of technologies are embedded in a web of more or less intentional decisions, of both designers and users, and these decisions have effects on the ways in which people use these technologies.”
Ou seja: não é “a tecnologia é só uma ferramenta neutra, o problema é sempre humano” (visão instrumental), e não é “a tecnologia determina o comportamento, a sociedade só reage” (visão determinista). É uma teia de decisões — de quem projeta e de quem usa — que se afetam mutuamente.
O Challenger é exatamente essa tese em ação, num só caso: a cultura organizacional (medo político de mais um atraso, hierarquia que excluiu os engenheiros da votação) moldou a decisão técnica (lançar mesmo com o alerta). E a decisão técnica — via o desastre — depois remoldou a cultura organizacional: dois anos de programa parado, e uma política nova para encorajar que engenheiros levantassem dúvidas. Não é uma linha reta de causa e efeito — é um laço.
3 Tecnologia Não é Neutra
Se tecnologia não é neutra, como isso aparece concretamente, em objetos do dia a dia? Duas ilustrações do Cap. 3 de Steen (2022) — uma dramática, uma banal, para mostrar que a tese vale nos dois extremos.
ImportanteAs pontes de Robert Moses
Robert Moses ocupou cargos-chave no planejamento urbano de Nova York entre os anos 1920 e 1960. Ele mandou construir uma série de viadutos sobre as parkways deliberadamente baixos:
“These bridges were so low that they prevented buses from going underneath. Effectively, these bridges prevented poor people, who typically could not afford cars and depended on buses, mostly people of colour, from visiting the parks and beaches. Moses used technology to achieve racist outcomes.” (Winner, apud Steen, 2022, p. 29)
A altura de um viaduto de concreto — um detalhe de engenharia civil, aparentemente neutro — foi o mecanismo de uma política de exclusão racial. Nenhuma linha de código, nenhum algoritmo: só concreto. A tese vale igualmente, ou mais, para sistemas computacionais.
A segunda ilustração é deliberadamente banal, para mostrar que o fenômeno não exige um vilão nem uma intenção política explícita — só projeto (Steen, 2022, pp. 29–30):
“Shavers for men used to have screws, which suggests that men are able to do maintenance or repairs. Shavers for women, in contrast, have no screws, which suggests that they are unable to maintain or repair these devices. […] These features are referred to as scripts or affordances; these prescribe, to a smaller or larger extent, what people can and cannot do with these products.”
Um parafuso — ou a ausência dele — carrega uma suposição sobre quem tem permissão (ou capacidade) de abrir, entender e reparar um objeto. Em software, a mesma lógica aparece em toda parte: uma opção de configuração escondida, uma API fechada, um formato de arquivo proprietário são scripts — decisões de projeto que prescrevem o que o usuário pode e não pode fazer, silenciosamente.
O historiador da tecnologia Melvin Kranzberg resumiu isso numa frase (citada em Steen, 2022, p. 30):
“Technology is neither good nor bad; nor is it neutral.”
4 O Mapa de Atores do Desenvolvimento Tecnológico
Se tecnologia não é neutra e não se desenvolve isolada da sociedade, quem, concretamente, participa dessa formação mútua? Van de Poel & Royakkers (2011, §1.6, p. 25) chamam de ator qualquer pessoa ou grupo que pode decidir como agir e agir sobre essa decisão:
“We use the term actor here for any person or group that can make a decision how to act and that can act on that decision.”
Quatro categorias de ator aparecem tipicamente no desenvolvimento tecnológico:
- Desenvolvedores e produtores — empresas de engenharia, laboratórios, universidades.
- Usuários — quem usa a tecnologia e formula exigências sobre seu funcionamento.
- Reguladores — governos e agências que formulam regras (segurança, concorrência).
- Outros atores — associações profissionais, sindicatos, grupos de interesse.
Distinto de ator: interessado (stakeholder) é quem tem interesse no resultado, mas não necessariamente pode influenciá-lo:
“Stakeholders are actors that have an interest (‘a stake’) in the development of a technology, but who cannot necessarily influence the direction of technological development.” (p. 26)