Análise e programação eram artesanato (mesmo)

Photo by Dominik Scythe on Unsplash

Houve uma era pré-Eclipse, pré-Software-Case, pré-PC onde muito do trabalho de especificação e construção de sistemas era literalmente artesanal.

Por incrível que pareça para quem não viveu essa fase, lápis, borracha, réguas (diversas), papel, canetas coloridas, cola e tesoura eram ferramentas indispensáveis numa época em que não havia um terminal por pessoa e boa parte do trabalho tinha que ser adiantado “na mesa”.

Régua para Fluxograma

Esse é um clássico, e quase todo mundo da minha geração já usou. Uma das peças que compunham a especificação de um programa era exatamente um fluxograma funcional.

A régua também ajudava a desenhar uma visão de mais alto nível do programa, mostrando entradas, saídas e dependências.

Esses desenhos eram guardados em “pastas de documentação”, junto com outros formulários e documentos manuscritos relacionados ao programa. Normalmente havia uma pasta para cada programa, e elas eram realmente pastas suspensas que ficavam guardadas num arquivo.

Assim como hoje, as empresas eram muito enérgicas para exigir que toda a documentação fosse atualizada e que a metodologia de desenvolvimento e manutenção de sistemas fosse rigorosamente cumprida. Mas não me lembro de ninguém buscar uma dessas pastas para atualizar os desenhos quando o programa sofria alguma alteração.

Formulário de Codificação COBOL

Esse formulário surgiu por volta dos anos 1960, numa época em que existia um profissional para programar e outro para digitar.

O formulário era dividido em colunas iguais às áreas de uma linha de programa em COBOL – sequence area, indicator area, A-zone, B-zone e identifier area – para que a gente pudesse escrever no papel exatamente o que o digitador teria que teclar no terminal (ou na perfuradora de cartões, em tempos mais antigos).

Eu não cheguei a enviar programas para digitação, porque como bem me avisaram no dia da entrevista numa das primeiras empresas que trabalhei, “aqui o próprio programador digita seu programa”.

Pela solenidade com que o entrevistador me comunicou isso, essa deve ter sido uma mudança revolucionária para eles naquela época.

Daquelas que hoje chamaríamos de disruptiva.

Formulário para Definição de Relatório

Havia um formulário muito parecido com o anterior, mas que era usado especificamente para desenhar o layout de relatórios antes da codificação do programa.

Nele desenhávamos cabeçalhos, linhas de detalhe e rodapés exatamente como eles apareceriam no relatório gerado pelo programa. Algo como um “what-you-see-is-what-you-get“, só que feito a lápis.

O formulário era quadriculado e tinha a largura necessária para definir um layout de até 132 colunas. Quase todos os relatórios da época se restringiam a 80 ou 132 colunas, e inclusive havia formulários contínuos diferentes para os dois. Como todas as impressoras da época só imprimiam caracteres monospace, ficava fácil reproduzir o desenho do formulário no programa.

Gabarito de Espacejamento

Essa era outra régua comum, e muitas vezes vinha combinada com a régua de fluxograma. A parte de cima vinha graduada de acordo com a largura de caracteres mais comuns nas impressoras de impacto que existiam na época.

Essa régua era muito útil principalmente para calcular o deslocamento dos campos em formulários pré-impressos, como os que eram utilizados para contra-cheque e DIRF.

Listagem de programas

Esse foi um recurso (e um hábito) que acho que felizmente desapareceu.

Devido à escassez de terminais, e talvez à falta de recursos nos editores de programa, era muito comum imprimir todo o programa quando necessitávamos fazer algum ajuste.

A gente mandava imprimir, ia até a sala da impressora (ou ao CPD) pegar a listagem que o operador havia deixado num escaninho. Voltava para a mesa, fazia as alterações a lápis, rasgava a remalina para marcar os pontos de alteração e depois ia para o terminal fazer as modificações no fonte.

(Para quem chegou depois, remalina eram as fitas destacáveis de papel que ficavam nas bordas do formulário contínuo. Ela era furada para que o trator da impressora pudesse puxar as folhas enquanto imprimia).

As empresas ficavam loucas com o gasto de papel, que além de ser usado para quase tudo (boa parte da informação gerada pelo sistema era fornecida ao usuário através de relatórios), era consumido como farinha pelo pessoal de desenvolvimento.

Eu cheguei a trabalhar numa empresa que contava quantas folhas haviam sido impressas por cada analista/programador mês a mês, e os mais gastadores eram chamados para “uma conversa” com o gerente.

Conclusão

Apesar de todo esforço da indústria e da academia para criar metodologias e processos que aumentem a previsibilidade da construção de sistemas, ainda acho que o que a gente faz em análise e programação está muito mais próximo do artesanato do que da engenharia.

As “ferramentas” que comentei aqui mostram apenas que isso era mais evidente no passado do que no presente.

E você? Lembra de algum outro recurso desse tipo que a gente usava 30 ou 40 anos atrás? Se lembrar, compartilha comigo aí nos comentários.


Um comentário em “Análise e programação eram artesanato (mesmo)

  1. Hoje em dia tem professor que insiste em fazer “prova escrita” de programação. Entendo que já houve um passado não muito distante, que realmente era necessário toda essa parte escrita em texto mesmo, pois não havia tantos computadores e só se ia para a maquina quando o código estava pronto. Mas exigir isso em pleno seculo XXI em 2022, é o mesmo que exigir que a pessoa saiba conduzir uma carroça antes de tirar habilitação para conduzir veículos automotores, ou saber andar a cavalo para andar de moto.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *