Engenheiros de software - última esperança para a ética na tecnologia da informação?

Em março o Stack Overflow publicou a Pesquisa para Desenvolvedores de 2018 e, pela primeira vez, incluiu perguntas sobre ética. A boa notícia é que para pergunta "os desenvolvedores têm obrigação de considerar as implicações éticas de seu código?" quase 80% responderam "sim". No entanto, apenas 20% se sentiram responsáveis por seu código antiético. 40% escreveriam código antiético se solicitado (a maioria disse que "depende" - o que eu leio como 'sim' - "mas eu me sentiria mal"), e apenas 50% denunciariam código antiético se o vissem.

Se o código tivesse pouco impacto no mundo, talvez isso não fosse um problema. Se eu escrever um algoritmo que prejudique 100 pessoas, isso é ruim, mas o efeito é limitado. No entanto, se eu fizer a mesma coisa no Facebook ou no Google com bilhões de usuários, o resultado será muito mais grave. O aumento na escala pode ser ruim e bom.

A maioria de nós não trabalha para empresas de hiperescala, mas o objetivo geralmente é crescer, e cultura é algo difícil de mudar. Tomar atalhos ou usar práticas duvidosas no começo podem parecer algo justificado ou pragmático (como a decisão de Uber de testar um carro autônomo sem licença), mas é notoriamente difícil escalar de volta dessa escorregada ética mais tarde.

Há muito o que poderíamos fazer. Nós, desenvolvedores, temos que projetar, escrever, e implantar código. Se quiséssemos, poderíamos ser a última barreira de defesa contra coisas antiéticas que ocorressem. Todos conhecemos aquele mantra do DevOps, "seu código, você implanta". Assim, deveríamos assumir responsabilidade ética também? Legalmente, talvez já o fazemos, como os engenheiros da Volkswagen que agora têm tempo vago para refletir. Não quero me pegar dizendo "Eu estava apenas seguindo ordens" no tribunal, na primeira página dos jornais, ou em qualquer outro lugar. Mas, como posso evitá-lo de maneira realista?

Mas, o que é ética, afinal?

Esqueça o dilema do bonde desgovernado. A ética da tecnologia da informação não é um ramo obscuro da filosofia, é apenas um comportamento profissional razoável, e que pode ser definida considerando como problemas evitáveis, ou danos individuais ou de grupo, podem resultar de um sistema de TI e, em seguida, tomar medidas realistas para evitá-los.

O que isso significa na prática? O tipo de questões éticas que enfrentamos pessoalmente é surpreendentemente mundano. Por exemplo:

• Projetos criticamente com recursos insuficientes: um projeto não pode ser entregue com segurança porque não foram alocados recursos suficientes.
• Segurança de dados inadequada: as medidas que protegem os dados do cliente em um projeto não são boas o suficiente, o que poderia prejudicar os usuários expondo suas informações pessoais.
• Entusiasmo na coleta de dados: uma aplicação está assumindo um risco desnecessário armazenando mais dados do usuário do que o necessário.
• Backups inadequados: se houve uma falha, os usuários podem ser prejudicados pela perda de dados ou serviços importantes.

Nenhum desses problemas éticos é novo ou esotérico. Eles não são sobre vilões do James Bond em covis subterrâneos, ou denúncias de esquemas maléficos do governo. Eles são o tipo de problemas chatos, mas importantes, com os quais a maioria das empresas luta diariamente e os desenvolvedores já perdem o sono. Tenho certeza de que todos nós aceitamos coisas como essa antes e nos sentimos muito mal com isso.

Não é antiético só porque algo dá errado. É software - as coisas vão dar errado. Só é antiético (ou não profissional) se não fizermos esforços razoáveis para evitar que ele dê errado de maneira perigosa, detectar quando coisas ruins estão acontecendo, ou resolver problemas quando os encontrarmos.

Lidar com problemas éticos mais complexos, como evitar dados tendenciosos de treinamento em aprendizado (ML) de máquina, ou manter os usuários a salvo da manipulação política, é apenas uma extensão do comportamento profissional comum. Não há salto do reino de coisas normais que todos estamos qualificados para discutir (como por ex, backups) para questões filosóficas que precisam de um PhD para serem resolvidas. Em vez disso, é um espectro contínuo. De um lado, temos problemas familiares com melhores práticas bem definidas (os backups) e do outro, novas técnicas com modos de falha desconhecidos e menos diretrizes ainda (como o ML).

Por exemplo, vamos considerar o caso real do software de agendamento da Kronos, popular entre empresas americanas como a Starbucks. Em 2014, o jornal The New York Times (NYT) revelou que a maneira como o software otimizou a eficiência das lojas teve um impacto muito negativo na vida dos funcionários, controlados pelos algoritmos do Kronos. Tenho certeza de que os desenvolvedores não pretendiam isso, eles apenas não tinham previsto os problemas e não tinham diretrizes existentes para trabalhar.

O problema ético aqui não foi o erro dos desenvolvedores. Mas sim, perceber que, sem história para aprender, os erros poderiam acontecer e precisariam ser vistos e retificados sem a intervenção de um jornal nacional. Como ferramenta de observação, o NYT geralmente não é sua melhor opção. O problema não foi a falta de empatia dos desenvolvedores, foi uma falha em entender onde o software estava no espectro de problemas conhecidos e desconhecidos e agir de acordo. Eles não testaram ou monitoraram o suficiente, ou seja, problemas profissionais normais. Eles não precisavam de um mestrado em psicologia.

Eventualmente desenvolveremos coletivamente as melhores práticas para o uso de coisas novas, como ML, algoritmos personalizados, e todo o resto. O problema atual é que ainda não o fizemos, levando a uma (temporária) terra de ninguém. Isso não é qualitativamente diferente de quando a segurança ou a acessibilidade eram novas há 20 anos, mas é quantitativamente diferente porque muitas pessoas são afetadas agora quando erramos. Isso significa que precisamos agir e definir e compartilhar esses bons comportamentos muito mais rapidamente.

A capacidade de se autorregular deve corresponder à velocidade da inovação.

A chave para se comportar eticamente como um desenvolvedor é proteger as pessoas de danos conhecidos nas mãos virtuais do nosso software. Quer o dano seja causado por uma IA senciente e aterrorizante ou por um backup não testado, precisamos das melhores práticas para nos guiar. Há muito debate agora sobre se as regras para o comportamento ético ou profissional dos engenheiros de software devem ser definidas de cima para baixo (legislação governamental ou órgãos profissionais) ou de baixo para cima (nós nos policiamos). Na minha opinião, uma vez que a coisa mais importante é que criamos, compartilhamos, e seguimos as diretrizes rapidamente, e resolvemos os problemas rapidamente, precisamos de uma abordagem de base conduzida por engenheiros de software. De cima para baixo sozinho não seria suficiente - é muito lento.

Claro, é mais fácil falar do que fazer. Todos aceitamos coisas antiéticas no passado. Uma voz solitária raramente é suficiente. Se nem sempre conseguimos o orçamento para a recuperação de desastres decente (algo bem conhecido e simples de explicar), como, por exemplo, garantiremos os recursos para monitorar nossos algoritmos de preconceito racial? Especialmente quando nem sabemos como fazer isso ainda! Ou para persuadir nossos empregadores a abandonar uma feature que dá lucro constante, mas que suspeitamos estar agindo contra os interesses de nossos usuários? Isso parece impossível! Estamos todos condenados!

Com base no fato de que qualquer coisa é melhor do que "Decisão judicial: condenada", estou inclinada a começar pelas coisas mais simples. Várias empresas conseguem garantir os princípios éticos, como o patch de segurança, por isso, impor uma ação responsável não pode ser impossível. Que opções realistas os desenvolvedores têm para policiar o comportamento ético?

Exerça seu poder

O que um engenheiro de software pode fazer se ele vir algo antiético ou algo potencialmente antiético e mal monitorado? Quando se pergunta isso a um engenheiro típico, três ideias surgem:

• Levante a bandeira, mas continue com o trabalho (a gerência, provavelmente, não tomará nenhuma atitude porque já sabe que está se comportando mal).
• Tome uma atitude e saia do projeto (ou da empresa)!
• Torne-se um denunciante (a escolha mais difícil; você receberá pouca gratidão e terá que viver o resto de sua vida na Rússia).

Então, há uma opção que o engenheiro de software acha é improvável que funcione (levantar a bandeira, indicar que há um problema), e dois com um custo tão alto que é improvável que ele os tente. Foram esses os pensamentos dos entrevistados do Stack Overflow? Não admira que eles fossem tão derrotistas.

No entanto, só porque essas são as opções que vêm à mente não significa que elas são as únicas. Nós, desenvolvedores, temos muito mais poder do que imaginamos. Especificamente, temos poder de consumo e poder profissional. O que quero dizer com isso?

O poder do consumidor

Os engenheiros/ consumidores têm potencialmente o poder de decidir o que fazer com seu orçamento (poder do consumidor). Se você é cético sobre isso, considere as palestrantes em conferências. Dez anos atrás, quase não havia mulheres conversando em grandes conferências tecnológicas. Hoje, elas geralmente refletem, pelo menos, a proporção de mulheres na indústria (~15-20%). Isso não acontece porque os organizadores da conferência são um bando de benfeitores, e não é porque é uma vitória fácil - conseguir oradores fora do círculo de costume é um trabalho árduo. As comissões da conferência contratam mulheres porque recebem reclamações dos participantes se não o fizerem. É um exemplo de desenvolvedores exercendo seu poder coletivamente declarando o que querem pelo preço de seu ingresso.

O poder do consumidor é um caminho de baixo custo para impulsionar a mudança. Os engenheiros podem aplicar isso sempre que comprarem ou usarem produtos e serviços de tecnologia. Por exemplo, perguntar quais são as políticas de energia renovável de seus fornecedores de nuvem ajudará aperfeiçoá-los; ou mudando de um fornecedor que você considera antiético para outro que seja menos antiético - contanto que você deixe claro para eles o motivo pela qual está mudando!

Poder profissional

O segundo poder que os desenvolvedores têm é o da sua especialidade profissional. Técnicos estão em falta. As empresas estão dispostas a contratar, e muito interessadas em mantê-los. Se um processo técnico ético (também conhecido como profissional ou responsável) é algo que esperamos dos empregadores, nós o conseguiremos.

O que é um processo ético?

Eu disse que devemos esperar por processos éticos na tecnologia da informação, mas até agora não há nenhum! Precisamos trabalhar juntos como engenheiros de software para desenvolver alguns, pelo menos por três motivos:

• Assim, podemos ouvir, e evitar problemas que outras pessoas já encontraram.
• Com um processo claro, é mais fácil concordar se um recurso, combinado com seu nível de monitoramento, é ético.
• Depois de concordarmos com os processos, podemos automatizá-los!

Vamos começar definindo algumas checklists simples e testá-las para ver se serão eficazes. Checklists parecem uma coisa simples em termos de tecnologia, mas na indústria da aviação têm sido extraordinariamente eficazes para aumentar a segurança. Aprender com as melhores práticas existentes é uma ótima estratégia.

Como isso precisa ser dimensionado para todas as coisas novas que estamos construindo, todos precisaremos pensar em boas práticas em nossas novas áreas de antemão, em retrospectiva, e compartilhar nossos pensamentos. Pense no desenvolvimento orientado a testes: considerar os modos de falha antecipadamente muitas vezes funciona.

Não gostamos de usar o código-fonte open source sem testes, mas atualmente aceitamos o código-fonte sem qualquer orientação cuidadosa do autor ou de outros usuários sobre como usá-lo com ética.

Talvez não devêssemos?

Para dar um pontapé inicial nessa discussão, criamos uma conta do GitHub para recursos éticos para desenvolvedores https://github.com/coed-ethics/coedethics.github.io

Também estamos trabalhando com o conselho de especialistas em tecnologia do Reino Unido, Doteveryone, e muitos outros, para criar alguns checklists e processos éticos básicos, os quais compartilharemos para que todos possam contribuir.

Também temos alguns grupos da indústria preparados para testar e dar feedback sobre esses processos.

Falamos sobre os resultados de tudo isso na conferência Coed: Ethics em julho de 2018, em Londres.

Por favor, participe e nos ajude a fazer isso acontecer.

• Escreva orientação ética para o seu código open source.
• Contribua com nossas listas de verificação e diretrizes éticas
• Ou, conte-nos sobre desafios éticos que você mesmo experimentou.

Ninguém é especialista nessas coisas porque é tudo muito novo, mas precisamos usar nosso próprio julgamento e colocar a mão na massa .

Vamos tornar os desenvolvedores a última barreira de defesa contra códigos antiéticos!

Esse artigo faz parte de uma série de cinco artigos a respeito da ética na tecnologia da informação. Veja a seguir o link para os outros artigos da série:

• Ética - uma perspectiva psicológica
• A ética na segurança da informação
• Ética - qual o próximo passo?
• Cidadania e ética na tecnologia da informação: por que se importar?

Sobre os autores

Anne Currie está na indústria de tecnologia há mais de 20 anos trabalhando em tudo, desde Microsoft Back Office Servers nos anos 90 e lingerie internacional online nos anos 2000, até devops de ponta e o impacto de containers orquestrados em 2010. Anne é co-fundadora de startups de tecnologia nos espaços de produtividade, varejo, e devops. Ela atualmente trabalha em Londres para a Container Solutions.

Ádám Sándor passou do desenvolvimento de aplicações para uma carreira de consultoria em computação nativa em nuvem. Ele é consultor sênior da Container Solutions, sediada em Amsterdã; e está ajudando as empresas a obterem sucesso na melhoria do fornecimento de software crítico para os negócios, combinando sua experiência em desenvolvimento de software com o conhecimento da infraestrutura baseada em containers.

Confira esse artigo e muitos outros em nossa eMag de Ética