Advancing Evidence-Based Social Sustainability in Software Engineering: A Research Roadmap
Este artigo apresenta uma revisão narrativa que define a sustentabilidade social na engenharia de software, identifica seus pilares fundamentais e propõe um roteiro abrangente para sua medição e integração prática nos processos de desenvolvimento.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que o desenvolvimento de software é como a construção de uma cidade inteira. Até hoje, os engenheiros e arquitetos (os programadores) focaram quase exclusivamente em duas coisas: se a cidade é forte (não desaba, o código não tem bugs) e se é barata e rápida de construir (o projeto não estoura o orçamento).
Mas, e a qualidade de vida dos moradores? E se a cidade for segura para todos, ou se ela criar bairros onde alguns ficam isolados e outros têm tudo? É aqui que entra o conceito de Sustentabilidade Social, que é o tema deste artigo.
Aqui está uma explicação simples do que os autores propõem, usando analogias do dia a dia:
1. O Problema: A Cidade que Funciona, mas não Cuida de Ninguém
O artigo começa dizendo que, embora o software tenha mudado o mundo, os pesquisadores de engenharia de software sempre olharam apenas para a "máquina" (velocidade, segurança técnica). Eles esqueceram de olhar para as pessoas.
- A Analogia: Imagine um elevador super rápido e que nunca quebra (ótimo tecnicamente), mas que é tão pequeno que só cabe uma pessoa de cada vez, deixando os idosos e cadeirantes esperando horas no hall. O elevador é "sustentável" tecnicamente? Sim. É socialmente sustentável? Não. Ele exclui pessoas e gera frustração.
- O que falta: Hoje, não temos uma definição clara do que é um software "socialmente sustentável". Às vezes, confunde-se o produto final (o app) com o processo de criação (como os programadores trabalham).
2. A Solução: Duas Definições Claras
Os autores propõem separar as coisas em duas caixas distintas para não ficar confuso:
Caixa 1: O Software Sustentável (O Produto)
- O que é: É o aplicativo ou sistema que você usa.
- A Analogia: É como um parque público. Um parque sustentável é aquele que é acessível para todos (crianças, idosos, pessoas com deficiência), que não polui o ar, que faz as pessoas se sentirem seguras e que une a comunidade em vez de separá-la.
- Definição: Um software que trata todos os usuários com justiça, protege a privacidade, melhora a vida das pessoas e não joga os problemas para gerações futuras ou para grupos vulneráveis.
Caixa 2: O Desenvolvimento Sustentável (O Processo)
- O que é: É como a equipe cria o software.
- A Analogia: É como a equipe de construção do parque. Eles trabalham sob sol forte sem água? Eles ganham um salário justo? Eles têm voz nas decisões? Ou são explorados até ficarem doentes?
- Definição: É garantir que os programadores e designers tenham condições de trabalho dignas, que todos possam participar das decisões e que ninguém seja explorado para que o software saia mais rápido.
3. O Desafio: Como Medir o "Invisível"?
Medir se um software é "justo" ou "feliz" é muito mais difícil do que medir se ele consome pouca energia (como medimos a sustentabilidade ambiental).
- O Problema: Você não pode colocar "justiça" ou "bem-estar" em um termômetro. Além disso, o que é justo no Brasil pode não ser justo no Japão. O que é bom para uma empresa pode ser ruim para a sociedade.
- A Metáfora: É como tentar medir o "amor" de uma família apenas contando quantas vezes eles se abraçaram. O número não diz tudo sobre a qualidade do relacionamento. Precisamos de novas ferramentas para entender essas nuances.
4. O Mapa do Tesouro (A Estrada para o Futuro)
Os autores não apenas apontam o problema, mas desenharam um mapa de 4 passos para a comunidade de tecnologia seguir:
- Criar Intervenções Práticas: Não basta falar, é preciso agir.
- Exemplo: Treinar programadores para terem mais empatia (como um médico aprende a ouvir o paciente) ou criar "semáforos" no código que avisam: "Ei, essa função pode discriminar pessoas com deficiência".
- Construir Ferramentas de Medição: Precisamos de réguas novas.
- Exemplo: Criar um "Índice de Inclusão" para apps, assim como temos o "Índice de Poluição". Precisamos saber exatamente o que estamos medindo.
- Fazer Experimentos Reais: Parar de apenas teorizar.
- Exemplo: Em vez de apenas escrever artigos, os pesquisadores devem testar essas novas regras em empresas reais ou com estudantes, para ver se realmente funcionam. É como testar um novo remédio em um grupo de pessoas antes de vender para todos.
- Trabalhar Juntos e Olhar para o Longo Prazo:
- Exemplo: Engenheiros precisam conversar com sociólogos, psicólogos e economistas. E precisamos de estudos que durem anos, porque os efeitos sociais de um software podem demorar para aparecer, assim como o efeito de um rio poluído na saúde de uma cidade leva anos para ser sentido.
Conclusão
O artigo diz que, assim como não podemos mais ignorar a poluição do ar, não podemos mais ignorar o "poluição social" que o software pode causar (como isolamento, desigualdade ou exploração de trabalhadores).
A mensagem final é: O software deve ser construído para servir à humanidade, não apenas para ser rápido ou lucrativo. Para isso, precisamos tratar a sustentabilidade social com a mesma seriedade científica que tratamos a segurança técnica.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.