É possível conseguir (2003)

• Durante a reformulação do sistema de arquivos do Multics na Honeywell Cambridge, André Bensoussan ficou responsável pelo subsistema central, o VTOC manager, conduzindo tudo do projeto aos testes
• Esse módulo precisava mover informações descritivas de arquivos entre disco e memória, além de gerenciar o buffer pool e até o espaço em disco, sendo na prática mais próximo de um pequeno gerenciador de memória virtual
• André não codificava diretamente no terminal; ele refinava diagramas e código a lápis, buscando criar um projeto simétrico que também armazenasse informações de estado
• Depois de digitar a versão final, os únicos problemas na primeira compilação foram 3 erros de digitação, e a execução após o binding no sistema também deu certo na primeira tentativa
• O único bug encontrado depois surgiu porque Tom Van Vleck informou incorretamente a ordem de chamada do procedimento de tratamento de erros, o que mostra o altíssimo nível de completude do programa

---

Trabalho no VTOC manager do Multics

• André Bensoussan trabalhou com Tom Van Vleck na Honeywell Cambridge no sistema operacional Multics
• Uma grande mudança no sistema de arquivos exigia um subsistema chamado VTOC manager
  • mover informações descritivas de arquivos entre disco e memória
  • gerenciar o buffer pool de memória compartilhada
  • gerenciar o espaço em disco para informações de arquivos
• Por causa desse papel, o VTOC manager precisava funcionar como um pequeno gerenciador de memória virtual
• André ficou encarregado do projeto, da implementação e dos testes desse módulo

Um programa concluído a lápis

• André primeiro se sentava à mesa e desenhava muitos diagramas
  • ele queria uma forma bonita e simétrica que ao mesmo tempo contivesse todas as informações de estado
  • a ponto de as pessoas ao redor se preocuparem com o atraso na escrita do código por causa do cronograma
• Ele também programava com lápis, não no terminal
  • recusou ajuda para digitação
  • reescreveu partes, copiou, apagou e corrigiu até produzir a versão final
• Depois de inserir toda a versão final escrita a lápis no terminal, a primeira compilação falhou, mas teve sucesso após corrigir 3 erros de digitação
• Após fazer o binding no sistema e executar, funcionou na primeira tentativa, e depois o VTOC manager continuou funcionando perfeitamente
• O único bug encontrado aconteceu porque Tom Van Vleck, sem confirmar, respondeu por suposição sobre a ordem de chamada do procedimento de tratamento de erros perguntada por André
  • quando esse caminho de erro foi percorrido pela primeira vez, ocorreu um crash
  • fora isso, não houve problemas no programa

[GN⁺]

Opiniões no Hacker News

• Acho que a principal razão de ele ter conseguido fazer isso foi que os requisitos estavam muito claramente definidos
  Hoje em dia, uma grande razão de os softwares serem cheios de bugs e lentos é que ninguém sabe de fato o que está construindo, ou, mesmo sabendo, isso continua mudando por causa do “agile”
  Se você der ao desenvolvedor uma API clara e critérios bem definidos, a maioria vai escrever código que funciona muito bem

  • A realidade desagradável é que isso só foi possível porque ele próprio era especialista no domínio
    Requisitos não são uma questão de espalhar listas e tickets num quadro kanban, mas de realmente aprender o domínio daquilo que vai ser construído
    Até dá para construir algo numa área que você não entende, mas o resultado tende a virar lixo, e tudo bem se você encarar esse processo de escrever lixo como um rascunho para aprender o problema do domínio e as soluções possíveis
    Não existe atalho para qualidade
    Se você é uma parte interessada, precisa ter acesso às pessoas que estão construindo a aplicação e verificar se elas entendem o domínio. Dá para fazer isso sem ficar importunando o tempo todo
    É preciso tomar cuidado com fanfarrões que ficam despejando palavras da moda
    Se você é designer ou programador, precisa verificar se as partes interessadas e os especialistas do domínio estão ativamente envolvidos e comprometidos. Caso contrário, arrancar requisitos e entendimento deles vira algo tão difícil quanto arrancar um dente
    Algumas partes interessadas podem nem querer resolver o problema, podem ter desejado uma direção completamente diferente ou estar ressentidas por razões políticas. Quase nada afunda um projeto tanto quanto partes interessadas preguiçosas ou desinteressadas
  • Concordo completamente. O problema em geral é que o planejamento do projeto é péssimo
    As partes interessadas não sabem o que querem e, ainda assim, pedem funcionalidades extras ou grandes mudanças quase ao acaso
    Isso acaba exigindo um monte de tratamentos de exceção para forçar coisas que essa ferramenta nem deveria fazer
    Designers frequentemente criam propostas que entram em conflito com as funções necessárias, o funcionamento do sistema existente e as exigências das partes interessadas, enquanto as equipes que desenvolvem cada parte do sistema trabalham em silos, sem se comunicar direito
    Processos “agile” mal desenhados tentam enfiar tudo dentro de um certo prazo com base em estimativas duvidosas de pontuação
    No fim, esses problemas fazem o sistema não funcionar como deveria ou o transformam num amontoado de bugs
    Se você criar um ambiente em que os requisitos sejam claros, não mudem, as pessoas do projeto se comuniquem bem e o processo possa ser totalmente controlado, as coisas dão certo. O caso do texto original parece ter sido assim
  • Além disso, entram milhares de casos especiais que muitas vezes praticamente não fazem sentido implementar em código, mas ainda assim precisam ser feitos
    Trabalho principalmente em grandes empresas, e 90~99% do que chega corresponde a casos médios
    Mas há incontáveis casos especiais tipo unicórnio que acontecem uma vez a cada três anos, quando eclipse solar e lunar ocorrem ao mesmo tempo e bruxas recitam encantamentos na floresta
    Como esses casos precisam ser implementados em código em vez de tratados manualmente, surgem bugs e aumenta muito a quantidade de código a revisar e manter
    Nem vamos começar a falar de manutenção. É um ponto dolorido
  • Se você acha que os requisitos mudam por causa do “agile”, nem sei o que dizer
    Os requisitos sempre mudam. Isso é como uma força da natureza, e não existe um mundo em que todo mundo já sabe desde o início o que vai construir, recebe uma API completamente especificada, entra numa caverna e só implementa
    A realidade nunca funciona assim, e, se você precisa dessas condições, então engenharia de software talvez não seja a profissão certa para você
  • Estou fazendo um software desktop comum e entediante, e a maior parte dos bugs, se não todos, vem de casos excepcionais em que o usuário faz alguma coisa “idiota”, ou seja, age de um jeito totalmente inesperado
    Se não houvesse usuários, meu software seria perfeito ;)

• Já trabalhei com alguém que havia desertado da União Soviética. Ele dizia que os programadores soviéticos eram excelentes porque o acesso a computadores era muito limitado
  Se você precisa programar com lápis e papel, quer fazer com que funcione já na primeira execução
  Por coincidência, nós estávamos trabalhando na Honeywell

  • Também dá para interpretar de outro jeito. Talvez só as pessoas realmente comprometidas o bastante para suportar um ambiente de trabalho em papel e com acesso limitado a computadores tenham continuado na área depois
    Nesse caso, isso era um bom método de ensino, ou apenas um bom filtro para eliminar os menos motivados?
  • Posso confirmar isso. Enquanto um professor da universidade passava um exercício de programação e explicava como resolvê-lo, ele começou a esboçar a solução no papel
    Como na escola não podíamos usar computadores durante a aula, ficamos acostumados a programar e até depurar no papel
    Cheguei em casa, digitei e executei, e fiquei curioso para ver se conseguiria reproduzir a anedota do Multics que eu havia lido antes
    A primeira compilação falhou, mas depois de corrigir um nome de variável funcionou perfeitamente
  • Aprendi em computadores cujo sistema de entrada e saída eram cartões e listagens impressas
    Por alguns anos, lembro que a saída em listagem impressa era muito melhor do que um terminal no ciclo editar→compilar→imprimir, porque era difícil ver, navegar e modificar o código com eficiência
    Isso acabou melhorando com editores visuais melhores, terminais maiores e compilação e execução mais rápidas
    Fazendo uma analogia, era como as primeiras armas de fogo. A transição a partir do arco longo foi ineficiente por causa de pólvora molhada, ignição instável por pederneira e a necessidade de enfiar tudo no cano
  • Quando aprendi COBOL no ensino médio, quase tudo era feito com caneta e papel. Não havia PCs suficientes no laboratório da escola para cada aluno, então 3 ou 4 pessoas tinham que compartilhar um computador
  • Então ele devia ser um dos privilegiados que tinham acesso a lápis e papel

• Há um bom comentário da conta jrd259, que trabalhou com André, na thread anterior do HN sobre este texto: https://news.ycombinator.com/item?id=18415231
  É sobre como uma mesa grande e um espaço de trabalho privado sem notificações são importantes

• Lembro de duas vezes em que programei no papel na minha vida
  A primeira foi quando eu tinha uns 10 a 12 anos. Fui visitar a casa dos meus avós, onde não havia computador nem smartphone, mas havia uma máquina de escrever mecânica que permitia digitar em preto e vermelho com um seletor
  Na época, meu principal hobby era Turbo Pascal, então escrevi na máquina um programa em Pascal para depois digitar no PC em casa e executar
  Como fiquei uma semana na casa dos meus avós, tive tempo de sobra para pensar, depurar à mão e redigitar as partes que estavam erradas
  A segunda foi com Ziim(https://esolangs.org/wiki/Ziim), uma linguagem de programação esotérica que criei, e com a função de soma binária daquela página
  A função era enorme, complexa e tinha um bug. Eu sabia disso porque já a tinha executado no interpretador, mas não sabia onde estava o problema nem como corrigir
  Por coincidência, precisei fazer uma viagem longa de ônibus, de umas 6 horas, e era a oportunidade perfeita para depurar
  Copiei a função de soma em Ziim a lápis para um papel quadriculado e fui executando passo a passo à mão no ônibus. Consegui encontrar e corrigir o bug, e tive de reorganizar completamente a disposição da função
  A lição, talvez, seja que limitar de propósito a capacidade de fazer do jeito fácil às vezes leva a um código mais bem pensado
  Mesmo assim, não faço isso normalmente. Também parto logo para escrever um snippet mais ou menos, iterar em cima dele ou executar linha por linha no depurador. Talvez eu devesse repensar isso

  • Em geral, faço a maior parte do raciocínio na cabeça, então, quando às vezes paro para pensar profundamente com papel e caneta, surge uma disciplina e cautela de anotar só o que é importante e manter o resto mentalmente
    Mas, se você fizer tudo no papel, no fim isso não fica tão diferente de fazer diretamente no computador. Você acaba anotando tudo e perde essa abstração e esse cuidado

• Quando comecei, já era o final da era dos “grandes computadores”
  Antigamente, “programador” costumava ser algo mais próximo de um operador de entrada de dados, e muitas vezes eram mulheres
  As pessoas que escreviam software ficavam em escritórios cheios de fumaça de cigarro, escrevendo programas no papel
  Tempo de computação era caro e escasso. Se surgisse um bug durante a execução, não havia chance de corrigir até conseguir novamente um horário para entrada de dados e outro para tempo de CPU
  Isso incentivava uma abordagem de medir duas vezes e cortar uma vez
  A maior parte do software da época também era bem modesta em comparação com o que hoje tomamos como garantido, então era mais fácil trabalhar assim. Além disso, as entradas e saídas do software eram extremamente limitadas, nem existia a expressão UI, e conectar periféricos era algo importante
  Hoje em dia, ao escrever software, muitas vezes se trabalha no estilo “jogar na parede para ver o que gruda”. É mais fácil escrever um código pela metade e depurá-lo na IDE
  Meu desenvolvimento de software tende a ser iterativo, e já escrevi sobre isso aqui: https://littlegreenviper.com/miscellany/evolutionary-design-...

  • É exatamente isso. Sinto falta daquela época em que era preciso pensar muito no software antes de escrever o código, mas, na verdade, um programador como o de hoje talvez tivesse feito o mesmo programa em metade do tempo com desenvolvimento iterativo
    Lembro de ter que escrever um kernel simples de sistema operacional em um trabalho da faculdade
    Eu mal conhecia C e não sabia, além da teoria, o que um kernel fazia, mas tinha que escrever algumas centenas de linhas de código em C para gerenciar tarefas
    Achei que, se esse programa não funcionasse, seria quase impossível depurá-lo por ser código concorrente, e que os bugs apareceriam como condições de corrida indecifráveis
    Raciocinei sobre o sistema inteiro e passei dias escrevendo muitas funções pequenas e independentes, pensando muito em cada uma delas
    Depois compilei e executei e, após corrigir o inevitável erro de compilação de “falta de ponto e vírgula”, funcionou já na primeira execução

• Sempre que aparece alguma realização impressionante, os comentários em geral passam a apontar defeitos. Queria que isso parasse

  • Os desenvolvedores modernos estão frustrados. Já não fazem mais nada importante nem significativo
    Em vez de projetar um gerenciador de memória virtual para um novo sistema operacional, são apenas engrenagens numa máquina que converte consultas SQL em HTML para mostrar anúncios a crianças e idosos
    É inevitável ficar cínico e amargurado
  • Toda vez que alguém posta uma contestação, as pessoas também passam a apontar defeitos nela. Então vamos pedir que isso pare?
    Na verdade, não deveríamos. É exatamente para isso que serve uma discussão
    Até certo ponto isso é verdade, mas uma pergunta melhor, que direciona a conversa de forma mais positiva, seria: como podemos chegar a uma situação em que feitos semelhantes sejam possíveis hoje no ambiente corporativo?
  • Entendo essa atitude, mas, quando voltei 5 horas depois de publicar este texto, os comentários no topo eram todos bastante positivos e não tinham esse tom de caça a defeitos
    Em geral é assim sempre que vejo esse tipo de reação. É que o filtro da moderação pelos usuários só leva um tempinho para empurrar os melhores comentários para cima
  • Mas eu realmente não entendo. Certa vez precisei trocar chart.js 3 por chart.js 4, e a documentação não cobria todas as mudanças
    Se essa pessoa tivesse enfrentado o desafio que eu enfrentei, teria simplesmente desistido na hora

• Naquela época, o software era muito menor
  Hoje em dia, a maioria dos projetos já fica na faixa dos megabytes assim que passa um pouco do tamanho de um programa de brinquedo, e é impossível simplesmente “ir escrevendo” tudo em um único arquivo

  • Vale a pena conferir o código diretamente: https://multicians.org/vtoc_man.html
    Isso é maior e mais complexo do que a maior parte do que se faz hoje. Muito do trabalho atual se parece mais com um código de cola inflado para juntar coisas como CRUD/REST
    Pode ser menor em linhas de código do que um projeto inteiro, mas é maior do que a unidade com que as pessoas costumam lidar. Além disso, isso também é só uma parte do código de um sistema operacional inteiro
    Este é o “gerenciador que administra informações descritivas de arquivos” completo. Ele precisava mover informações de arquivos entre disco e memória, gerenciar um pool de buffers em memória compartilhada e também administrar o espaço em disco para essas informações
    E se você pedisse para a maioria dos programadores de hoje escrever algo com os mesmos requisitos e a mesma semântica, na linguagem que quisessem, hoje mesmo?
    A maioria se perderia já na fase de imaginar a coisa. Quanto mais colocar no papel, digitar e fazer funcionar
  • Em compensação, quase não havia exemplos de referência. Nas aulas introdutórias de sistemas operacionais deles não existia aula sobre memória virtual. Essas pessoas foram pioneiras no projeto de sistemas operacionais
  • Desculpe, mas o software corporativo com que a maioria de nós trabalha não é mais impressionante do que escrever do zero um componente principal de um sistema de arquivos
  • Fiquei surpreso ao perceber que, no último mês, minhas anotações em linguagem natural num caderno de eletrônica já somavam 0,25 megabyte, cerca de 37.000 palavras em Markdown
    Uma pequena parte disso são URLs de componentes eletrônicos, mas quase 90% é apenas texto em inglês. Outros 10% são citações de textos de outras pessoas, páginas da web, application notes de fabricantes, livros etc.
    É um único arquivo, e provavelmente continuará sendo um único arquivo pelo resto deste ano e além. Nesse ritmo, vai chegar a 12 megabytes. Não é nada impossível
    Se tiver interesse, é só fazer git clone http://canonical.org/~kragen/sw/leatherdrink.git
    No momento ele tem quase 200 megabytes porque inclui um commit do toolchain avr, além de fotos, vídeos, esquemas e coisas do tipo
    Numa linguagem de programação, o aumento mensal em bytes seria menor, mas talvez a diferença fosse de umas cinco vezes

• O código escrito por André Bensoussan está aqui: https://multicians.org/vtoc_man.html

  • A resposta para “como ele fez isso?” é óbvia. Porque, pelos padrões modernos, não era um trabalho tão complexo
  • Não vi muito de PL/1, mas, tirando o fluxo de controle, a sintaxe parece surpreendentemente limpa

• Sentei à mesa para começar a trabalhar e terminar algo que eu estava evitando, e, como era de se esperar, minha atenção se desviou e eu quis checar as notícias no reddit ou no HN
  Abri o HN e o primeiro título era este
  “Você consegue”
  Isso me motivou
  PS: claro que eu também li o texto :)

• “Como André fez isso sem nenhuma ferramenta além de um lápis?”
  Quando fui para o ensino médio aos 14 anos, eu escrevia a maior parte do código no papel nas aulas de programação
  Eu era uma criança pobre de um país pobre, e não só não tinha PC em casa, como também os poucos “computadores” do laboratório da escola eram clones de ZX Spectrum que não conseguiam rodar a linguagem de programação que usávamos na época, Turbo Pascal