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: a resposta da NASA não foi só refazer a engenharia mecânica do anel de vedação, foi reestruturar o próprio fluxo de decisão (dois anos de programa parado, engenheiros com poder de veto). Não é uma linha reta de causa e efeito — é um laço:
flowchart TB
A["🏢 Cultura<br/>Organizacional"]
B["⚙️ Decisão<br/>Técnica"]
C["💥 O Desastre<br/>Físico"]
D["🔄 Cultura<br/>Remoldada"]
A -->|"Molda"| B
B -->|"Causa"| C
C -->|"Provoca"| D
D -->|"Altera"| A
classDef org fill:#f59e0b,stroke:#b45309,stroke-width:2px,color:#fff;
classDef tech fill:#3b82f6,stroke:#1d4ed8,stroke-width:2px,color:#fff;
classDef disaster fill:#ef4444,stroke:#b91c1c,stroke-width:2px,color:#fff;
classDef remold fill:#10b981,stroke:#047857,stroke-width:2px,color:#fff;
class A org;
class B tech;
class C disaster;
class D remold;
A cultura da NASA moldou a decisão técnica, e o resultado material dessa decisão (a explosão) forçou a mudança na estrutura de poder organizacional da agência.
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)
Os viadutos ficavam nas parkways de Long Island que davam acesso a Jones Beach — a praia pública mais famosa da região. 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 lei segregacionista escrita, 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.”
Se mesmo uma decisão “banal” de projeto — um parafuso — embute uma visão de mundo sobre gênero, a pergunta que importa deixa de ser só “a tecnologia é boa ou má” e passa a ser quem estava na sala quando a decisão foi tomada. A falta de diversidade entre quem projeta é o que permite que vieses, muitas vezes inconscientes, se tornem “detalhes” codificados no produto final — um fio que a Aula 9 (gênero e diversidade em computação) retoma com mais profundidade.
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)
flowchart TB
D["Desenvolvedores<br/>e produtores"]
U["Usuários"]
R["Reguladores"]
O["Outros atores<br/>(associações, sindicatos)"]
DT["Desenvolvimento<br/>Tecnológico"]
S["Interessados<br/>(Stakeholders)"]
D --> DT
U --> DT
R --> DT
O --> DT
DT -.->|"Afeta, mas não<br/>necessariamente influencia"| S
classDef atores fill:#3b82f6,stroke:#1d4ed8,stroke-width:2px,color:#fff;
classDef processo fill:#10b981,stroke:#047857,stroke-width:2px,color:#fff;
classDef stake fill:#ef4444,stroke:#b91c1c,stroke-width:2px,color:#fff;
class D,U,R,O atores;
class DT processo;
class S stake;
(Diagrama acima recriado a partir da Figura 1.6 de Van de Poel & Royakkers, 2011, p. 26 — “Technological development map of actors” — com a adição da seta para interessados, que não está na figura original mas foi discutida no texto que a segue.)
Os interesses desses atores frequentemente conflitam, então não há acordo automático sobre a direção “certa” do desenvolvimento tecnológico. E mesmo quando todos concordam, o resultado pode ser imprevisível — o caso do Teflon é o exemplo do livro: descoberto por acidente em 1938 (um químico da DuPont tentando desenvolver um refrigerante), décadas depois seu uso mais difundido — frigideiras antiaderentes — trouxe uma preocupação de saúde (o composto PFOA, “likely carcinogenic” segundo a EPA em 2005) que ninguém em 1938 tinha meios de prever. Esse é o dilema de Collingridge: não se pode prever as consequências no início do desenvolvimento tecnológico, mas quando elas aparecem, a tecnologia já está tão entranhada na sociedade que é difícil mudar de direção.
Uma resposta institucional a esse dilema, que vale nomear mesmo sem detalhar (Van de Poel & Royakkers, 2011, p. 28):
“The idea behind Constructive Technology Assessment (CTA) is that TA-like efforts are to be carried out parallel to the process of technological development and are fed back to the development and design process of technology. […] CTA aims at broadening the design process, both in terms of actors involved and in terms of interests, considerations and values taken into account in technological development.”
Ou seja: se prever o futuro é impossível e mudar o fim é tarde demais, a resposta é mudar o meio do processo, continuamente — em duas frentes:
- Expande-se a mesa — mais atores e stakeholders dentro do processo de design desde o início, não só ao final.
- Expandem-se os valores — considerações sociais avaliadas em paralelo ao desenvolvimento técnico, não depois dele.
Não é uma vacina contra o dilema de Collingridge — é uma forma de conviver com ele, corrigindo a rota mais cedo.
5 Feedback Loop e Responsabilidade
Um exemplo contemporâneo de computação, para fechar. Algoritmos de redes sociais otimizados para tempo de tela usam, nas palavras de Steen (2022, p. 32):
“decades of knowledge from the domain of gambling and slot machines. With buzzing sounds and flashing icons, they grab our attention as often as possible. With infinite scrolling and seductive suggestions (‘watch next’), they hold our attention as long as possible.”
Não é acusação abstrata — tem nome de quem trabalhou por dentro e saiu para denunciar:
“Former Google designer Tristan Harris is one of the people who helped to expose such practices. We are vulnerable to how these designs activate our behavioural impulses. Our brains have evolved to be activated by novel or interesting sensory input.” (Steen, 2022, p. 32)
O comportamento capturado gera os dados que retreinam o algoritmo, que fica melhor em capturar atenção — um feedback loop não-técnico entre projeto de produto e comportamento humano em massa:
flowchart TB
A["💻 Projeto do<br/>Algoritmo"]
B["🧠 Comportamento<br/>do Usuário"]
C["📊 Dados de<br/>Engajamento"]
D["⚙️ Retreinamento<br/>(Machine Learning)"]
A -->|"induz"| B
B -->|"gera"| C
C -->|"alimenta"| D
D -->|"reforça"| A
classDef tech fill:#3b82f6,stroke:#1d4ed8,stroke-width:2px,color:#fff;
classDef human fill:#ef4444,stroke:#b91c1c,stroke-width:2px,color:#fff;
classDef data fill:#10b981,stroke:#047857,stroke-width:2px,color:#fff;
class A tech;
class B human;
class C data;
class D tech;
Nenhuma linha de código isolada “causa” o resultado — ele emerge do ciclo contínuo: o código molda o comportamento, que gera dados, que reescrevem o código.
Isso nos leva de volta à pergunta de responsabilidade que o Challenger já tinha levantado. Van de Poel & Royakkers (2011, p. 28) chegam a uma conclusão quase contraintuitiva:
“In one sense, it diminishes the responsibility of engineers because it makes clear that engineers are just one of the many actors involved in technology development and cannot alone determine technological development and its social consequences. In another sense, however, it extends the responsibility of engineers because they have to take into account a range of stakeholders and their interests.”
O contexto social diminui a responsabilidade individual (você é só um entre muitos atores; o desenvolvedor isolado não determina todas as consequências sociais do produto) e, ao mesmo tempo, amplia essa responsabilidade (você precisa considerar interessados que não estão na sala). Não são a mesma pergunta, e confundir uma com a outra é o erro mais comum ao discutir “de quem é a culpa” quando um sistema falha: não ser o único culpado não significa estar isento de responsabilidade moral sobre o que se projeta.
Ponte para a Aula 2
Falta uma ferramenta: se ninguém decide isoladamente, e as consequências são difíceis de prever, como raciocinar sistematicamente sobre o que é certo fazer dentro dessa teia sociotécnica? É o assunto da Aula 2 — as principais correntes da ética normativa (consequencialismo, deontologia, ética das virtudes) e o Ciclo Ético como método de deliberação.