mnemetica

Respostas a perguntas de alunos de Engenharia de Software

(Uma tradução de EWD1305, bastante pertinente ao contexto)

[ A reconstrução aproximada das perguntas é um exercício destinado ao leitor. ]

• Geringonças não são necessariamente uma melhoria, vide a sucessão:
  Quadro Negro -> Retroprojetor -> Power Point
• E eu não preciso gastar o meu tempo com um computador apenas porque eu sou um cientista da computação.
  [ Não são exigidos a pesquisadores médicos sofrer das doenças que eles investigam ]
• Não é o negócio da ciência da computação promover a “automação”, por exemplo, criando aplicações que exijam mais hardware para criar um mercado para a próxima geração de hardware.
  [ Pesquisadores médicos não precisam criar novas doenças para criar um mercado para novos produtos farmacêuticos ]
• Não é tarefa da Universidade oferecer o que a sociedade quer mas dar o que a sociedade precisa.
  [ As coisas que a sociedade pede são geralmente entendidas, e você não precisa uma Universidade para isto; a universidade tem que oferecer o que nenhum outro pode fornecer. ]
• Somos todos modelados pelas ferramentas que usamos, em particular: os formalismos que usamos formam os nossos hábitos de pensamento, por bem ou por mal, e isto significa que você deve ser bastante cuidadoso ao escolher o que aprender e ensinar, visto que desaprender não é realmente possível.
  [ Há muitos anos atrás, caso eu precisasse de um assistente, um prequisito seria "Sem exposição prévia a FORTRAN", e em ensino de segundo grau da Sibéria, o ensino de BASIC não seria permitido. ]
• Um programador deve ser capaz de demonstrar que o seu programa possui as propriedades exigidas. Se isto é consequência, é improvável que ele seja capaz de atender aos requisitos: Somente se ele permite a sua obrigação influenciar o seu design, há esperança de que ele possa atender a expectativa. Uma verificação pura a posteriori lhe inibe um pouco desta influência holística e é portanto colocar a carroça na frente dos bois, mas isto é exatamente o que acontece nas fábricas de software aonde “programação” e “controle de qualidade” são feitos por equipes distintas. [ E sem dizer que estas fábricas entregam sem garantia. ]
• As técnicas exigidas de racionalização efetiva são bastante formais, mas enquanto a programação é feita por pessoas que não as dominam, a crise de software irá continuar conosco e será considerada uma doença sem cura. E você sabe o que doenças sem curas fazem: elas convidam macumbeiros e charlatões aonde, neste caso em particular, tomam a forma de gurus de Engenharia de Software.
• Alguns duvidam que a supracitada “técnicas de racionalização efetiva”, meigas como elas são para programas pequenos, irão escalonar, como dizem, “dada o assombroso tamanho e imensa complexidade da maioria dos programas”. Bem, eles podem ser inadequados se você tentar usá-las para desemaranhar a tremenda confusão produzida por um grupo de incompetentes, desorganizados programadores. O seu poder manifesta somente na fase de construção quando (i) eles tendem a conduzir para textos muito menores que seriam produzidos e (ii) comprimento de variações de programas tendem a crescer não muito mais que a linearidade dos comprimentos dos programas derivados. Finalmente os programas produzidos são infinitamente menores que o lixo usual.
• Não devemos jamais esquecer que programadores vivem em um mundo de artefatos, um fato que o distiguem de outros cientistas. Um programador não deve perguntar o quanto aplicáveis as técnicas de boa programação são aplicáveis, ele deve criar um mundo aonde elas são aplicáveis, e é a sua única maneira de entregar um design de alta qualidade. Sobre isso eu devo citar EWD898 (1984):
  

  “As capacidades das máquinas nos dão bastante recursos para fazê-la uma completa confusão. Oportunidades ilimitadas para estragar as coisas. Desenvolver a disciplina austera de manter as coisas suficientemente simples neste ambiente é um desafio formidável, tanto tecnicamente quando educacionalmente.”

• Em resposta a questões sobre porque ensinamos coisas sem valor que a indústria ignora, eu o indico EWD920 (1985). Permita-me citar mais um parágrafo:
  

  “Retomando a questão original: pode a ciência da computação salvar a indústria de computação? A minha resposta é “Se a indústria de computação pode ser salva, somente a ciência da computação pode fazê-la.”. Mas irá demorar muito até que a indústria de computadores – em particular, as empresas bem estabelecidas – compartilhem esta visão. Certamente irá demorar mais que o período limitado pela a qual eles planejam os seus futuros. No intervalo, o mundo acadêmico – que tradicionalmente planeja muito mais além – não tem escolha. Tem que refinar e ensinar usando o melhor das suas habilidades como a computação deve ser feita; no caso dela ceder a pressão de propagar a má-prática de hoje, é melhor que ela suma.”.

• Mas para reforçar sobre quanta paciência precisamos, permita-me mencionar outra velha citação (de 1988):
  

  “Poucas pessoas reconhecem que a alta tecnologia tão celebrada hoje é essencialmente uma tecnologia matemática.”

  (do segundo relatório David, batizado em referência ao seu presidente, Dr. E. E. David Jr.)

• Não, eu não tenho medo que a ciência da computação tenha sofrido com a popularidade da Internet. Ela atraiu uma crescente – para não dizer: inundante ! – massa de estudantes com bastante pouca inclinação acadêmica e na pesquisa ela apenas fortaleceu a prevalescente (e de certa forma vulgar) obcessão com velocidade e capacidade.
• Sim, eu concordo com a sua preocupação: Como programar bem – quando um assunto ensinável é dificilmente ensinado. A situação é similar aquela em matemática, aonde o currículo explícito é confinado a resultados matemáticos; como a matemática é algo que o estudante deve absorver por osmose, assim dizendo. Uma razão para preferir manipulação de símbolos, calcular argumentos é que o seu design é muito melhor ensinável que o design via um argumento verbal/pictorial. A introdução em larga escala de cursos em metodologia calculacional, entretando, iria encontrar problemas políticos intransponíveis.
• No negócio de software existem muitas empresas aonde não é claro que a ciência pode ajudá-la; se a ciência deve tentar ajudá-la também não é muito claro.

Edsger Wybe Dijskstra (11/05/1930 – 06/08/2002) foi um cientista da computação holandês. Ele recebeu em 1972 o prémio Alan M. Turing para contribuições fundamentais na área de linguagens de programação, e foi processor na Universidade de Texas em Austin de 1984 até a sua morte em 2002. O prémio anual da ACM foi renomeado como Prêmio ACM Edsger W. Dijkstra logo após a sua morte.

Dijkstra também era notado por ter tido apenas um único computador (já no final da vida), e raramente usá-lo, mantendo a sua convicção que a ciência da computação não deve ser mais abstrata que mera programação, explicada em um número de famosos dizeres como “A Ciência da Computação não é tanto sobre computadores do que a Astronomia é sobre Telescópios”.