Apontamentos para Enriquecer o Perfil do Engenheiro de Software

Cássio Adriano Nunes Teixeira, Henrique Luiz Cukierman

Programa de Engenharia de Sistemas e Computação, COPPE/UFRJ, Bloco H, CT, Cidade Universitária, Ilha do Fundão, Rio de Janeiro, RJ, CEP. 21.995-970

{cant, hcukier}@cos.ufrj.br

Abstract. Software Engineering (SE) is of vital importance for today's society, given the ubiquity of its product: software. However, influenced by western scientific rationality, SE presents a very strong technicist bias in its teaching and practice. In this paper, we discuss the need to restrict this bias. We use the sociotechnical approach of Science Studies (SS) to discuss some questions and we suggest this approach as a valuable resource in the search for answers.

Resumo. A engenharia de software (ES) tem vital importância para a sociedade atual, dada a ubiqüidade de seu produto: o software. Contudo, influenciada pela racionalidade cientifica ocidental, a ES apresenta um viés tecnicista muito forte em seu ensino e prática. Neste artigo discutimos a necessidade de rompermos este viés. Utilizamos a abordagem sociotécnica dos Estudos de Ciência e Tecnologia (ECT) para problematizarmos algumas questões e a sugerimos como insumo valioso na busca de respostas.

1. Introdução

É truísmo dizer que os sistemas de software são ubíquos. Em menos de quatro décadas eles evoluíram do suporte às atividades administrativas básicas das empresas – folha de pagamento, contabilidade, etc. – para estarem em todos instantes de nossas vidas (HIRSCHHEIM, 1995, p.1). Para nossa sociedade, portanto, é de suma importância devotarmos atenção à engenharia de software (ES) e ao perfil do engenheiro de software. Como a ensinamos e praticamos? Neste artigo, chamaremos a atenção para o risco de, talvez, o estarmos fazendo sob um rígido viés tecnicista. É uma provocação com a qual tentamos angariar aliados dispostos à tarefa de ampliar o foco de abrangência da ES. Para isso, trazemos na seção 2 o que é a ES segundo uma abordagem sociotécnica dos estudos de ciência e tecnologia (ECT)1. Na seção 3 esquadrinhamos, brevemente, o viés tecnicista existente no padrão de valores da ES, buscando sensibilizar para a necessidade de mudança. Em seguida, seção 4, ilustramos que a fronteira tecnicista é ilusória, e que o ciberespaço é um exemplo enfático a nos confrontar com a necessidade de expandir a ES. Para concluir, sugerimos que a abordagem sociotécnica dos ECT, vista sumariamente no artigo, pode nos ajudar em direção a uma ES mais ampla.

Este artigo, repetimos, é uma provocação, ou talvez melhor, uma problematização do tema pois apenas delineia alguns problemas sem sugerir

1 Tradução da denominação do campo interdisciplinar reconhecido internacionalmente como Science Studies.

XIII WEI 2314

explicitamente propostas de equacionamento. Contudo, acreditamos que uma problematização bem articulada pode constituir uma contribuição significativa. De nossa parte estamos iniciando a busca por respostas e esperamos que mais atores se interessem em fazer o mesmo.

2. Engenharia de Software (ES) como construção – traduções

O padrão IEEE 610.12-1990 define ES como (1) a aplicação de uma abordagem sistemática, disciplinada e mensurável ao desenvolvimento, operação e manutenção de software; ou seja, a aplicação da engenharia ao software; e (2) o estudo das abordagens que permitem a realização de (1) (PRESSMAN, 2001, p.20). São comuns definições do tipo: ES é uma disciplina cujo foco é desenvolver sistemas de software de alta qualidade com eficiência relativa ao custo (SOMMERVILLE, 2004, p.4); e ES lida com projeto e desenvolvimento de software de alta qualidade, para solucionar problemas cuja análise demonstrou a necessidade do uso de um sistema de software (PFLEEGER, 2001, pp.2-5). Atualmente, aceitamos com naturalidade que o desenvolvimento e a manutenção de software é, de fato, uma engenharia. Não existe nenhum problema com isso, mas precisamos atentar para os reflexos dessa definição no próprio escopo da ES. Tendemos a aceitar, como algo natural, que a ES deve lidar apenas com questões “técnicas”. Vejamos como surgiu o termo “engenharia” aplicado ao software, para, na próxima seção, questionarmos seu viés tecnicista.

Voltando ao ano de 1968, em uma conferência do comitê de ciência da OTAN – Organização do Tratado do Atlântico Norte –, veremos a primeira vez que o termo engenharia foi usado para se referir ao desenvolvimento de software. Naquela ocasião, os organizadores da conferência julgaram que o título – “engenharia” – iria provocar interesse (PARNAS, 1997, grifo nosso). Não estavam, ao que parece, portanto, primordialmente querendo defender que desenvolver software tratava-se de fato de engenharia. Simplesmente queriam alistar muitos outros aliados para os debates. A expressão “engenharia” não passava de uma metáfora, naquele momento. Mas essa metáfora alinhou esforços e interesses em infundir a disciplina da engenharia no processo de desenvolvimento. Inúmeros atores passaram a adaptar idéias de outras engenharias ao desenvolvimento de software. Houve um grande entendimento do papel da abstração e separação de conceitos, foram introduzidas as noções de modularidade e ciclo de vida de software, processos, medições, especificações abstratas e notações para fazê-las (LEVESON, 1997). Hoje, usualmente aceito na comunidade acadêmica e prática, o termo engenharia de software deixou de ser apenas metáfora, uma afirmação ou suposição qualquer, para tornar-se um fato.

Seria correto afirmar que a ES foi criada apenas pelos que a batizaram na citada conferência da OTAN? Certamente não. Desenvolver software hoje é engenharia graças a todos aqueles que, como nós, foram alistados pela metáfora inicial e passaram a orientar sua prática de maneira coerente com a inspiração que dela advinha. Com isso, ao longo do tempo, mais e mais fatos, artefatos2, e seus autores, foram surgindo reforçando a veracidade da metáfora “engenharia”, que, paulatinamente, tornou-se fato.

2 Qualquer objeto técnico.

XIII WEI 2315

Podemos imaginar atores, artefatos e afirmações adicionais sendo envolvidos em um “redemoinho3” que ia ganhando crescente amplitude. À medida que aumentava suas dimensões, o “redemoinho” protegia em seu centro a metáfora “engenharia”, cada vez mais distante das novas afirmações, artefatos e autores capturados. Da periferia do “redemoinho”, dificilmente se enxergava a metáfora que jazia no centro. Ao contrário, sob o ponto de vista da periferia, outros fatos, outros artefatos, outros autores, já capturados, conformavam a visão de que no centro havia a caixa-preta4: desenvolver software é engenharia. Os ECT dão o nome de tradução a este processo que ilustramos como um “redemoinho” crescente (figura 01).

Tradução é um processo coletivo no qual construtores de fatos e artefatos, em movimentos de ajustes mútuos e negociações de interesses com os elementos que querem alistar, buscam equivalências e coincidências, nem sempre existentes ab initio, que viabilizem a associação e socialização de todos estes elementos, para a construção e disseminação do fato ou artefato. O arcabouço metodológico trata com equivalência analítica todos os elementos alistados, não fazendo distinção alguma entre humanos e não humanos. Tampouco aceita a possibilidade de delimitações nítidas entre fatores “técnicos” e fatores “sociais”. O fato ou artefato produzido (conteúdo) é indissociável de seu contexto de produção. É definindo o conceito de rede sociotécnica para denominar a resultante do processo de tradução (LATOUR, 2000).

Fatos e artefatos – como a ES, uma teoria, um software, um motor, um processo de software – serão bem sucedidos (existirão de fato) somente se os processos de tradução relacionados lograrem êxito em enredar, ou envolver no “redemoinho”: valores, técnicas, crenças, métodos, políticas, ferramentas, cultura, orçamentos, pessoas e muitos outros elementos humanos e não humanos, constituindo concomitantemente sua respectiva rede sociotécnica. Existe uma forte característica de incerteza neste processo, pois, a priori, não se pode garantir que os elementos alistados agirão como esperado ou mesmo se permanecerão enredados5.

3 A metáfora do redemoinho não é totalmente apropriada, servindo apenas para ilustrar particularidades de uma realidade maior, de uma rede. O “redemoinho” explicaria uma configuração particular da rede formada pelos fatos, artefatos e seus autores. A ES não é apenas o centro do “redemoinho”, ela é o próprio redemoinho. Na verdade, a metáfora transformada em fato não apresenta um ponto central, pois surge de/em uma rede sociotécnica, como definiremos adiante, sem um centro definido. 4 Conceito dos ECT: caixa-preta é um fato plenamente aceito ou um objeto [artefato] não problemático. É um todo organizado que o construtor de fatos [e artefatos] quer propagar no tempo e no espaço e que dá a impressão de manter, por si só, o controle do comportamento de todos os seus componentes alistados, tendo ares de verdade pura (LATOUR, 2000, p.216). 5 Veja maiores detalhes em Bruno Latour (2000) ou Michel Callon (1999).

Figura 01 – Processo de tradução

No centro do “redemoinho” está uma metáfora. No “redemoinho” se envolvem fatos, artefatos e seus autores. Observadores como A ou D não vêem seu centro, eles tendem a reconhecer que lá existe um fato, uma caixa preta. Observadores como B e C têm a oportunidade (nem sempre aproveitada) de perceberem o centro como construção e não como “natureza”, algo “pronto” e descoberto.

XIII WEI 2316

Nomear o desenvolvimento de software de engenharia foi um claro movimento de tradução bem sucedido, pois logrou êxito em: (i) alistar aliados – a conferência (SOFTWARE ENGINEERING CONFERENCE, 1969) nos influencia até hoje; e (ii) controlar seu comportamento – passamos a tentar agir como engenheiros. Sem invalidar as definições apresentadas, podemos ver na ES uma metáfora conformada em fato, através de um processo coletivo de traduções, que, ao longo do tempo, enredou vários fatos e artefatos adicionais. Vê-la como resultante de sua própria rede sociotécnica, com inevitáveis traduções envolvidas, nos permite admitir sua imbricação com contextos específicos, e julgar com atenção e propriedade as reivindicações de naturalidade e universalidade para seus preceitos. Neste artigo, por exemplo, negamos a inerência do viés rigidamente tecnicista da ES. Ao contrário, encaramos esse viés como uma realidade conformada, contingente e historicamente urdida, em vez de algo inevitável ou intrínseco à “natureza do desenvolvimento de software”. As redes sociotécnicas – “redemoinhos” – sempre podem perder força, mudar de direção, perder elementos, envolver novos, constituir outros “centros”, se transformar...

3. Padrão de valores da ES – alertas contrários ao viés tecnicista

Com Descartes, a racionalidade científica ocidental passou a valorizar o método como diretriz para a verdade, o que se entranhou na matemática e nas ciências naturais, que, de sua parte, influenciaram o estabelecimento daquilo que conta como conhecimento, ou não, no ocidente (HIRSCHHEIM, 1995, p.21). Também sob essa influência, à medida que veio se constituindo, a ES buscou extirpar “contaminantes” sociais, políticos e culturais, tentando estabelecer-se e manter-se como disciplina puramente técnica. Nos primeiros 50 anos vimos o desenvolvimento do conceito de software como um produto de engenharia e um objeto matemático, com pouca atenção devotada ao software como um produto humano (LEVESON, 1997).

A maioria das abordagens considera que projeto e desenvolvimento de software tratam-se apenas de uma questão técnica, quando muito, com conseqüências sociais. Isto conformou a ES em uma disciplina que crê lidar, sobretudo, com objetos de complexidade “técnica”, demandando somente, e cada vez mais, ferramentas, métodos, modelos e princípios técnicos (HIRSCHHEIM, 1995, p.1). É notória a grande evolução da ES nas fases finais do ciclo de vida de desenvolvimento de software, a saber, codificação e testes6. Estas abordagens trazem implícitas as seguintes suposições7, questionáveis quando se opta por um olhar construtivista:

• Realismo – os componentes da modelagem do sistema – classes de objetos, entidades, relacionamentos, processos – existem no mundo real. O trabalho do desenvolvedor seria o de encontrar estes elementos que comporão o sistema, ‘como se fossem um tesouro afundado’;

• Objetivismo – existe um conjunto, objetivamente definido, de elementos componentes do sistema que independe da percepção do desenvolvedor. Assim, se dois desenvolvedores apresentam soluções divergentes para um mesmo problema, a explicação seria que um não está vendo tão bem ou não é tão experiente quanto o outro.

6 As fases finais do ciclo de vida de desenvolvimento de software contam com o suporte de inúmeras ferramentas. São as lower-CASE – Computer-Aided Software Engineering –, por exemplo: depuradores, analisadores de programas, geradores de casos-de-teste, editores de programas, ambientes integrados de desenvolvimento (SOMMERVILLE, I., 2000, Software engineering. 6th ed., Addson-Wesley, p.9). 7 Ibid., p.xii.

XIII WEI 2317

As abordagens tradicionais de ES consideram que os requisitos de um sistema são uma realidade existente a priori, que precisa apenas ser “descoberta” para, a partir daí, ordenar todo o processo de desenvolvimento do software (HIRSCHHEIM, 1995, p.33). Atualmente é aceita a impossibilidade de elicitação completa destes requisitos a priori, visto que o próprio sistema, inserido no contexto organizacional, nunca estará concluído, demandando continuamente revisões e adaptações (SCACCHI, 2004). A abordagem sociotécnica dos ECT reforça este ponto de vista. O software produzido resultará de (em) sua rede sociotécnica. Vários elementos (humanos e não humanos) deverão ser alistados ao longo do processo de tradução, inclusive os requisitos. Façamos uma analogia com a própria ES: não existia a priori um “requisito” do tipo “desenvolvimento de software tem que ser engenharia”. Traduções conformaram-no à medida que conformaram o próprio desenvolvimento de software em engenharia.

Como qualquer disciplina, a ES tem um conjunto próprio de valores construídos e também enredados pelas traduções. Este conjunto de valores congrega os membros da disciplina e dirige suas decisões. Por exemplo, um engenheiro de software julga a qualidade de um programa sempre a partir de valores, como: é completamente testável, é estruturado, está bem documentado, executa eficientemente, é fácil de manter? Todas as propriedades de um “bom” software refletem e constituem valores. Um conjunto de valores relacionados, compartilhados pelos membros de uma disciplina, compõe o padrão de valores que baliza todas as discussões e decisões da comunidade congregada. O padrão de valores pode até não ser notado, estar implícito, mas sempre existirá (MOOR, 1998).

Dificilmente existirão controvérsias explícitas sobre os valores. Normalmente, elas existirão em torno das afirmações que se tornarão fato, ou não, dependendo do sucesso em se vencer as controvérsias8. Por exemplo, tomemos a controvérsia existente na comunidade de ES sobre a adequação, ou não, da abordagem de orientação por objetos (OO). Os valores que permitem o julgamento sobre se OO é boa ou ruim não estão, pelo menos por ora, em controvérsia, pois compõem o padrão de valores aceito pelos engenheiros de software, tais como modularidade, baixo nível de bugs, facilidade de manutenção, clareza do código, etc. A controvérsia, no caso, está em se admitir, ou não, que a OO os assegura (MOOR, 1998, HATTON, 1998).

Chegamos à provocação central do artigo: o padrão de valores da ES precisa ser expandido? Podemos continuar considerando problemas de ES somente aqueles relacionados a questões supostamente técnicas? O engenheiro de software tem 8 Uma afirmação, por si só, não é capaz de estabelecer-se como fato – científico ou técnico –, ou, ao contrário, ser relegada à categoria de ficção. Somente o uso que os outros dela fizerem, somado a afirmações ulteriores, fará com que uma afirmação de um determinado autor sofra transformações e consolide-se em fato ou evapore como ficção. Para existir como fato, uma afirmação qualquer precisa superar as controvérsias em torno de sua validade. Deve resistir às provas de força que surgirão. Se vencer as controvérsias, a afirmação se tornará fato e a realidade subjacente a ela, finalmente, será conformada. A verdade surge somente quando a controvérsia se encerra. E, a partir deste instante, passamos a aceitar que ela estivera lá o tempo todo. Quando isto ocorre, foi produzida uma caixa-preta. O que foi dito sobre os fatos também vale para os artefatos (ou objetos técnicos) (LATOUR, 2000). A prova de força é o questionamento da validade de uma afirmação frente ao que ela representa, a explicitação daquilo que sustenta a afirmação (LATOUR, 2000, p.129). Como exemplo, tomemos a afirmação o Sol gira em torno da Terra, real durante o longo período em que resistiu às provas de força. Hoje a realidade que aceitamos, porque foi conformada, é que a Terra gira em torno do Sol. Cessada a controvérsia, consideramos que a realidade “sempre” foi esta, relegando à ficção o que se acreditou por vários séculos.

XIII WEI 2318

responsabilidades estritamente técnicas? Defendemos a importância de retirarmos este viés e ampliarmos o campo de discussão, ensino e prática da ES. Poucos cientistas da computação têm se preocupado em considerar o efeito decorrente da extraordinária interação entre tecnologia e sociedade. É fundamental, para a ES, atentar para isto. Os desafios existentes requerem que a ES seja mais centrada nesta interação, reconhecendo a importância e estreitando laços com as ciências sociais e a psicologia cognitiva (LEVESON, 1997). Em sua visão, Leveson acha que “o fervor e a excitação na busca de se desenvolver uma tecnologia revolucionária, com potencial de mudar o mundo de forma profunda, pode estar concentrando [a discussão] apenas no técnico e excluindo o social”. Este raciocínio é corroborado por Hirschheim (1995, p.33) quando afirma que o desenvolvimento de sistemas de software parece envolto numa “ortodoxia técnica” sendo visto apenas como um processo técnico, a ser realizado por pessoal técnico, auxiliados por soluções técnicas. Vejamos outras observações sobre a necessidade de rompermos esta “ortodoxia técnica”.

É importante que humanistas e cientistas sociais parem de encapsular “detalhes técnicos” – deixando que outros os tratem – enquanto focalizam os impactos sociais da tecnologia. É preciso mergulhar nas arquiteturas, códigos, algoritmos, porque eles explicarão questões essenciais das dimensões social, ética e política. Por sua vez, engenheiros de software não podem se iludir crendo possível extirpar “detalhes sociais” da prática e dos produtos da ES – deixando para outros estudarem sua influência – (NISSENBAUM, 2001). A comunidade de ES não pode se eximir das controvérsias filosóficas que têm banhado as pesquisas sociais. A pesquisa sobre sistemas de informações é basicamente um estudo de nossa condição social – conhecimento e comunicação – um problema de complexidade social (HIRSCHHEIM, 1995, p.6).

O impacto dos sistemas computacionais em nossas vidas tem sido alardeado por muitos, de vários modos. É comum focalizar as alterações que provocam em nosso arranjo social, como o distúrbio causado na cadeia de responsabilidade em que um elo humano é substituído por um sistema. Também é usual o foco direto nos valores como, por exemplo, a privacidade, ora sob intenso debate devido à interferência que sofre da tecnologia. Notamos, nos dois casos, a visão da tecnologia de informação como agente de transformação do mundo. No entanto, é importante considerar o oposto também: a tecnologia é moldada por valores de quem a produz (NISSENBAUM, 2001), ficando assim colocada em questão a própria noção de “impacto”, abrindo espaço à noção alternativa e mais esclarecedora de “construção mútua” entre tecnologia e sociedade.

A incorporação de valores nos sistemas computacionais é inevitável. Ignorar isto é perder para o acaso, ou uma outra força qualquer, esta importante dimensão do processo de moldagem dos sistemas de computação. Cientistas da computação e engenheiros de software devem expandir o conjunto de critérios que normalmente utilizam nos projetos de construção de seus sistemas, manifestamente incorporando critérios sociais, éticos e políticos, inevitavelmente presentes. Um complexo inter-relacionamento – entre o sistema, quem o fez e o que tinha em mente, as condições de uso, e as dimensões natural, cultural, social e política existentes – pode esclarecer bastante sobre os valores incorporados nos sistemas de computação9. Os ECT corroboram esta afirmação e o processo de tradução a explica.

9 Ibid.

XIII WEI 2319

É notória a proeminência da discussão relativa à computação no campo da ética (computer ethics). Possivelmente, nos últimos dois séculos, a computação é a tecnologia mais imbricada com a vida e sociedade humanas devido ao que Moor (1998) denomina: maleabilidade lógica e enriquecimento informacional. A primeira denota a capacidade dos computadores poderem ser manipulados para desempenhar qualquer atividade que possa ser caracterizada em termos de entrada, saída e conexões de operações lógicas. O enriquecimento informacional deriva da maleabilidade lógica e diz respeito ao poder dos computadores de transformar nossas atividades em algo tão dependente do processamento de informações que, às vezes, chegamos a deixar de perceber a possibilidade de existência destas atividades sem o recurso computacional. Quando isso ocorre, as atividades e nossa concepção sobre elas se tornam informacionalmente enriquecidas. Diferentes de quaisquer outros, computadores são artefatos de propósito geral, por isso pervagam nossas vidas. Não deve ser mistério algum que focalizá-los seja tão mais importante que focalizar, por exemplo, torradeiras, locomotivas e máquinas de costura quando discutimos ética (MOOR, 1998). Por isso, o engenheiro de software, em sua prática, talvez precise considerar, mais que um engenheiro de outra modalidade, as derivações éticas, políticas e sociais de suas decisões.

Felizmente, muitos movimentos têm percebido que a tecnologia da informação é algo inevitavelmente social e, com isso, têm tentado focalizar a ES como um problema também de complexidade social (HIRSCHHEIM, 1995, p.2). É importante ressaltar que sob o nosso ponto de vista – abordagem sociotécnica dos ECT – a divisão entre complexidades, ou fatores, ou aspectos “técnicos x sociais” não é apropriada. Forçoso é reconhecer que, na prática, os engenheiros de sucesso são exatamente aqueles que expandem sua atuação para fora dos limites ditos “técnicos”, normalmente recebendo qualificações do tipo: bons políticos, líderes, empreendedores, facilitadores. Eles percebem que o sucesso de sua prática não dependerá simplesmente do nível de qualidade “técnica” do projeto e do software que desenvolvem. Vitalari (apud HIRSCHHEIM, 1995, p.18) registrou que “os analistas [de sistemas] experientes e bem sucedidos percebem os aspectos políticos [inevitavelmente] relacionados ao desenvolvimento de sistemas, ao passo que os menos experientes não”.

4. Necessidade de expandir o debate sobre Engenharia de Software

Acreditamos que a ES foi conformada coletivamente, herdando da racionalidade científica ocidental a tentativa de focalizar sua atuação dentro de uma “pureza técnica”. No entanto, valores, e outras “impurezas sociais”, sempre corromperão esta inatingível “pureza técnica”. De fato não existe uma “condição natural”, ou uma “lei imutável”, que nos leve a tratar a ES com tamanho viés tecnicista. Por isso ilustramos, nesta seção, duas questões que nos alertam para a necessidade de respondermos, dada a importância do software em nossa sociedade, se é preciso, ou não, expandirmos o foco da ES.

Precisamos romper a fronteira que limita nosso ensino e prática da ES por, no mínimo, dois motivos: (i) esta fronteira é convencional, (por ora escolhemos nos prender a ela) portanto pode ser redesenhada; (ii) a prática da ES, lidar com “problemas de projeto de sistemas de informações, é um fenômeno muito mais complexo que se imagina na maioria dos casos, pois afeta as condições de existência humana de maneira similar à promulgação de leis (...)” (HIRSCHHEIM, 1995, p.2, grifo nosso).

XIII WEI 2320

4.1. A fronteira tecnicista não existe

Parece estranho afirmar, mas quanto mais “técnico”, especializado, “engenharia” tentarmos fazer o desenvolvimento de software, tanto mais “social” ele será. Desenvolver software se tornou engenharia porque o “redemoinho” ainda crescente estabiliza traduções que transformam a metáfora “engenharia” cada vez mais em fato. Quando novas técnicas, ferramentas e/ou fatos são enredados, necessariamente seus autores e valores subjacentes também são socializados na rede sociotécnica da ES. A produção de fatos e artefatos logrará êxito somente se conseguir arregimentar e socializar diversos aliados em torno do que se quer produzir. Controvérsias precisarão ser vencidas. Até mesmo não aliados têm que ser socializados, senão o autor não terá interlocutores sequer para resolver as controvérsias, ou melhor, nem haverá controvérsias. Por isso, hipertrofiar o “lado técnico” simultaneamente significará hipertrofiar o “lado social” (LATOUR, 2000, p.103). Como conseqüência é impossível divisar uma fronteira nítida entre o técnico e o social. Tentemos separar o técnico do social na utilização do termo “engenharia” na conferência da OTAN: artifício social – atrair atenção? Algo técnico – infundir novo rigor ao desenvolvimento de software?

Outro exemplo: a criação da abordagem OO remonta o ano de 1962 quando a linguagem destinada a simulação por eventos discretos – SIMULA – estava sendo projetada. Seus autores, Ole-Johan Dahl e Kristen Nygaard, ao desenvolvê-la, utilizando idéias já existentes, perceberam ser muito útil, para o problema em que estavam envolvidos, criar um conceito que associasse estrutura de dados e operações – os objetos. Divertidamente, um dos motivos que levou seus autores a se basearem na linguagem ALGOL 60 para seu desenvolvimento foi o “patriotismo europeu” (DAHL, 2002, p.80). Como arbitrar se a influência foi técnica ou social nesse caso? E onde termina o “social” e começa o “técnico” nas afirmações a seguir? (i) “Pessoas motivadas com seu trabalho são provavelmente as mais fortes tecnicamente (SOMMERVILLE, 2004, p.600, grifo nosso); (ii) “é importante que qualquer um escolhido para realizar uma tarefa esteja empolgado em fazê-la, não importa por qual razão (PFLEEGER, 2001, p.91, grifo nosso).

Se nos debruçarmos na história da ES veremos inumeráveis exemplos que retratam a dificuldade de traçarmos esta linha divisória, o que nos mostra a precariedade do viés estritamente tecnicista. Se este artigo tiver alguma utilidade, que seja a de convidar a comunidade de ES à investigação do apelo da abordagem sociotécnica para nossa disciplina.

4.2. A ubiqüidade do software nas condições de existência humana – o ciberespaço

O segundo motivo que trazemos para exemplificar a necessidade de expandirmos o foco da ES, seu padrão de valores, se relaciona com a possibilidade dos projetos de sistemas de informações afetarem nossas vidas semelhante às leis. Usaremos a argumentação de Lawrence Lessig – advogado constitucionalista norte-americano – a respeito do poder regulador do código sobre nossas vidas, sobretudo sua opinião de que software não deve ser tratado como uma questão de engenharia apenas.

A transparência da regulamentação em um Estado democrático, em tese, está presente quando o governo regulamenta diretamente, pois o governo é eleito; seu exercício de regulamentação é restrito por limites constitucionais; e, supostamente, suas ações são públicas. No entanto, a regulamentação não é materializada apenas através

XIII WEI 2321

das leis. Além das leis, as seguintes forças adicionais regulam a vida dos indivíduos: as normas sociais, o mercado e a arquitetura / código. Estas quatro forças reguladoras são interdependentes e o governo se vale de todas elas para regular, direta e indiretamente, nossas vidas. É conferido maior ou menor peso à utilização de uma delas em função dos custos e benefícios relacionados com o fim desejado (LESSIG, 1999, pp.86-92).

Ao regulamentar indiretamente o governo usa outras estruturas para impor a restrição que deseja. Ele pode ocultar sua responsabilidade sobre a restrição imposta para não solapar seu capital político. A transparência é um importante valor nos governos constitucionais, ameaçado quando a regulamentação indireta ocorre. A indireção permite confundir de quem é a responsabilidade e, portanto, obscurecer a política seguida (LESSIG, 1999, pp.96-98). A argumentação de Lessig está embasada em uma reflexão sobre o ciberespaço. Vale a pena apreender com detalhes sua reflexão. Neste artigo, apenas destacaremos o mínimo necessário ao nosso escopo.

Hoje vivemos num mundo cuja arquitetura que regula ordinariamente nossas vidas está cada vez mais sob o enorme poder regulador do código. De forma ubíqua, e a todo instante, o código regula nossas vidas10. Como advogado constitucionalista, a preocupação de Lessig é que a regulação pode estar passando das mãos dos legisladores – cujo processo em tese é público e transparente – para as mãos dos “desenvolvedores de código”. Para ele, a questão que deveria ser colocada é se isto não deveria ser controlado. A sociedade não deveria estar ciente de quem são os “desenvolvedores de código” e quais valores eles levam para seu trabalho11?

Dispondo de enorme poder, funcionando como lei, o código estaria criando uma nova jurisdição fora da possibilidade dos mecanismos de revisão constitucional. Valores constitucionais como privacidade, direito ao acesso à informação, direito ao anonimato, igualdade, liberdade de expressão não precisariam impor restrição alguma a este novo mundo criado via código, posto que ele é privado. Queremos deixar a regulação pelo código correr à margem da revisão constitucional? Ou devemos estendê-la para as forças reguladoras privadas, em nome da preservação de valores fundamentais12? O ciberespaço, como qualquer outro artefato, é construído e indissociável de seu contexto.

Sua natureza não é dada. Sua natureza é o seu código, e seu código está mudando de uma posição que desabilitava o controle para uma outra, que permitirá um tipo extraordinário de controle. É o comércio que está fazendo com que isso ocorra; o governo irá ajudar. Antes que isso aconteça, deveríamos decidir se é desse jeito que queremos que as coisas sejam13.

A utilização do ciberespaço pelo comércio eletrônico, com o suporte do governo (norte-americano), está construindo uma nova arquitetura sobre a arquitetura de protocolos originais, que não apenas o está tornando menos livre como também, o que é mais assustador, está tornando nossa própria vida passível de uma regulação e controle jamais vistos pela humanidade (a materialização do “big brother”14). Regulamentando indiretamente, o que impede a transparência necessária, e este é o sinal de alerta, o governo quer ver disponível esta nova arquitetura que permitiria a identificação de

10 Ibid., p.233 11 Ibid., p.207 12 Ibid., pp.217-218 13 Ibid., p.61 14 George Orwell, no livro 1984, de 1949, usa o termo “big brother” para denotar o intrusivo poder do Estado futuro sobre nossas vidas.

XIII WEI 2322

emissores e receptores de informações no ciberespaço. Com ela seria possível, também, implementar rastreabilidade e controle onipresentes em nossas vidas.

Esta arquitetura na qual o ciberespaço está se transformando delimitará poder social e legal. Quais valores fundamentais queremos ver imbricados nela? Se o ciberespaço vai se tornar um instrumento poderoso de controle, ou se a liberdade será um valor nele (re)construído, vai depender de decisões políticas que estabelecerão sua arquitetura.

Podemos construir, ou arquitetar, ou codificar o ciberespaço para proteger valores que reputamos fundamentais [– privacidade, igualdade, liberdade de expressão –], ou podemos construir, arquitetar, ou codificar o ciberespaço de forma a permitir que estes valores desapareçam. (...) Da forma como o mundo está atualmente, o desenvolvedor de código cada vez mais é o legislador (LESSIG, 1999, pp.59-60).

Esta ameaça aos valores revelada pelo ciberespaço não lhe é inerente. Tratam-se de problemas do mundo real para os quais o ciberespaço, enfaticamente, nos provoca a elaborarmos respostas15. Olhemos o tão divulgado bug do milênio (Y2K).

Assim como legisladores de visão curta, codificadores de visão curta criaram uma crise, talvez a primeira crise do código, de proporções jamais vista. Anos depois do primeiro código ruim ser compilado, nos confrontamos com um tipo de desastre ‘ambiental’: estávamos rodeados de softwares que crítica e imprevisivelmente poderiam falhar – no mínimo causando prejuízos de milhões de dólares e coisas muito piores, nos cenários de juízo final traçados –. O Y2K é produto de não se ter percebido o poder regulador do código. Milhares de desenvolvedores ocuparam-se de seus trabalhos como se suas ações dissessem respeito somente a eles próprios. O Y2K é produto da lei não tratar apropriadamente os responsáveis pela codificação.16

Lessig não aponta respostas fechadas, mas considera o código aberto um importante instrumento para se viabilizar transparência na regulamentação inexorável imposta pelo código. Sob o ponto de vista constitucional, o melhor código seria o modular e aberto. Modularidade para garantir a fácil substituição por componentes melhores e viabilizar o aumento da competição, o que redundaria em melhorias. Sendo abertos, a transparência dos componentes de software se tornaria vantagem competitiva17. No entanto, a lei atual de direitos autorais (copyright) trabalha contra a publicidade e transparência do código, dando aos produtores de software termos de proteção efetivamente ilimitados18.

Existem três grandes limitadores que atrapalham a solução dos problemas que o ciberespaço incisivamente nos mostra: “um judiciário limitado, um legislativo patético, e nossa visão de que o código é algo intocável”19. Interpretamos o item em destaque como uma crítica de Lessig à “proibição” de questionarmos a conformação, a forma de produção e os impactos do código, porque, supostamente, tudo seria resultado de decisões “técnicas”, corroborando uma suposta inevitabilidade do progresso tecnológico que leva essas decisões a seguirem seu “único caminho possível”. “Código é lei, (...) codifica valores, mesmo assim, espantosamente, muitas pessoas insistem em dizer que código é apenas uma questão de engenharia”20.

15 Ibid., p.213. 16 Ibid., p. 232. 17 Ibid., pp.224-225. 18 Ibid., p. 225. 19 Ibid., p.221, grifo nosso. 20 Ibid., p.59, grifo nosso.

XIII WEI 2323

O espanto de Lessig muito nos interessa e pode ter duas interpretações: (1) é correto achar que código não é apenas questão de engenharia; ou, a que preferimos, (2) algumas questões – como as que ele aponta – indevidamente parecem não pertencer à ES, em decorrência de seu viés tecnicista. A nosso ver, a ES não pode se restringir apenas à aplicação de habilidades técnicas (SOMMERVILLE, 2004, p.14), de forma sectária. A ES já está madura o bastante para assumir plenamente a responsabilidade sobre o que faz, devendo reconhecer o profundo efeito que tem sobre a vida e sociedade humanas. Outras engenharias, em seus códigos de conduta profissional, têm como preceito básico no exercício da profissão manter com preeminência a segurança, saúde e bem estar públicos. A ES deve seguir este exemplo e criar seus próprios padrões e códigos de conduta, aceitando a responsabilidade sobre o uso e o mau uso potencial de suas invenções, bem como sobre os efeitos que causarem (LEVESON, 1997).

Dado o papel do software como regulador, também não podemos deixar de lado a responsabilidade para a preservação / (re)criação de valores democráticos como transparência, privacidade, igualdade, liberdade de expressão, justiça. Temos que romper com o foco tecnicista que impõe restrições desnecessárias à própria ES, pois, além de não abordar uma série de problemas, outorga aos advogados uma discussão mais ampla sobre modularidade e transparência de componentes, por exemplo. A abordagem sociotécnica é uma alternativa metodológica, pois já parte da aceitação da imbricação entre social e técnico, não criando barreiras artificiais que só dificultam a compreensão e solução dos problemas, podendo contribuir para formação de engenheiros de software com perfil mais abrangente e eficaz.

5. Conclusão

Mesmo nos eximindo de encarar os desafios sociais, éticos e políticos que a prática da ES nos impõe, uma investigação da abordagem sociotécnica pode trazer valiosos insumos para o ensino e prática da ES. Se o objetivo da ES for apenas produzir softwares de qualidade, entender que a construção e distribuição deles ocorrem em redes sociotécnicas com inevitáveis traduções já trará benefícios. O bom engenheiro de software terá perfil de bom tradutor. Contudo, acreditamos que podemos e devemos expandir o enfoque da ES para algo muito mais além, algo muito mais importante.

O padrão de valores da ES permitiu – e até estabeleceu como boa prática – a retirada de dois bytes, relativos ao século, nas datas dos antigos programas que rodavam em ambientes computacionais de restrita capacidade de memória. Todos lembramos das conseqüências disso no final da década de 1990. Mas, atenção, talvez hoje este padrão de valores que construímos, junto à construção da própria ES, esteja nos limitando. Ele nos compele a retirar “bytes relativos aos contaminantes” sociais, culturais e políticos da ES, na tentativa de resguardá-la sob uma redoma puramente técnica. Isto é impossível, dada a inevitável imbricação do social e do técnico. Contudo, quais conseqüências futuras a busca desta ilusória pureza técnica poderá trazer? É absurdo esperar que a magnitude das conseqüências, no mínimo, não será menor que a observada na véspera da virada do milênio, com o Y2K? A “ortodoxia técnica” nos faz outorgar a responsabilidade sobre diversas questões para outras áreas.

A abordagem sociotécnica dos ECT pode ser alistada para complementar, enriquecer e expandir a ES. Estamos iniciando a busca por soluções potenciais para os problemas apresentados. Porém, de antemão, acreditamos que será valioso: 1) entender

XIII WEI 2324

a ES como uma construção sociotécnica, ressaltando sua historicidade e negando a “naturalidade” de seus preceitos; 2) estreitar laços com as ciências sociais; 3) tratar a inevitável incorporação de valores nos projetos (design) de software; e 4) valorizar o ensino baseado em estudos de caso bem contextualizados. Está em nossas mãos definirmos qual perfil deverá ter o bom engenheiro de software e como nos instrumentar para formá-los.

6. Bibliografia

CALLON, M., 1999, “Some Elements of a Sociology of Translation: domestication of the scallops and the fishermen of St. Brieuc bay”. In: BIAGIOLI, M., The science studies reader, New York, Routledge, pp.67-83.

DAHL, O.-J., 2002, “The Roots of Object Orientation: the SIMULA language”. In: BROY, M., DENERT, E. (eds), Software Pioneers: contributions to software engineering, Berlin, Germany, Springer-Verlag, pp.79-90.

HATTON, L., 1998, “Does OO Sync with How We Think?”. In: IEEE Software, may.

HIRSCHHEIM, R, HEINZ, K.K., LYYTINEN, K., 1995, Information Systems Development and Data Modeling: Conceptual and Philosophical Foundations. Cambridge University Press.

LATOUR, B., 2000, Ciência em Ação: como seguir cientistas e engenheiros sociedade afora. São Paulo, Editora UNESP.

LATOUR, B., 2001, A Esperança de Pandora. Bauru, SP, Editora EDUSC.

LEVESON, N.G., 1997, “Software Engineering: Stretching the Limits of Complexity”. In: Communications of the ACM, v. 40, n. 2, pp.129-131.

LESSIG, L., 1999, CODE and Other Laws of Cyberspace. New York, Basic Books.

MOOR, J.H., 1998, “Reason, Relativity, and Responsibility in Computer Ethics”. In: Computers and Society, march, pp.14-21.

NISSENBAUM, H., 2001, “How Computer Systems Embody Values”. In: Computer, march, pp.118-120.

PARNAS, D. L., 1997, “Software Engineering: An Unconsummated Marriage”. In: Communications of the ACM, v. 40, n. 9, p.128.

PFLEEGER, S.L., 2001, Software Engineering: theory and practice. 2nd ed., Upper Saddle River, New Jersey, PTR Prentice Hall.

PRESSMAN, R.S., 2001, Software engineering: a practitioner’s approach. 5th ed., McGraw-Hill.

SCACCHI, W., 2004, “Socio-Technical Design”. In BAINBRIDGE, W.S. (ed.), The Encyclopedia of Human-Computer Interaction, Berkshire Publishing Group. Obtido no endereço: http://www.icsuci.edu/~wscacchi, acessado em 30/08/2004.

SOFTWARE ENGINEERING CONFERENCE, 1., 1968, Garmish, Germany. Report... Brussels: NATO Science Committee, Peter Naur and Brian Randell, 1969.

SOMMERVILLE, I., 2004, Software engineering. 7th ed., Addson-Wesley.

XIII WEI 2325