O Protocolo é a Verdade

No desenvolvimento de software moderno, vivemos num mundo de abstrações convenientes. Quando precisamos integrar um novo hardware, a nossa primeira ação é procurar o SDK (Software Development Kit) oficial ou o driver fornecido pelo fabricante. Se o fabricante diz que "o driver é obrigatório" ou que "certo tipo de acesso não é possível", nós geralmente aceitamos. A ferramenta é a nossa ponte para a funcionalidade, e raramente questionamos a sua construção.

Mas o que acontece quando a ponte que todos usam não te leva onde precisas ir? O que fazes quando tua compreensão dos fundamentos, diz que há um caminho mais direto, mesmo quando os "especialistas" dizem que esse caminho não existe? Em 1995, aprendi que a recusa em aceitar um "não" e a confiança no conhecimento fundamental podem ser as ferramentas de inovação mais poderosas que existem.

O cenário era a minha empresa, a CompCet. Tínhamos acabado de fechar um projeto para um cliente importante na área agropecuária, e nos deparamos com uma nova obrigação legal que estava valendo: o uso obrigatório de impressoras fiscais. No Rio Grande do Sul, o mercado tinha uma solução padrão: todo o desenvolvimento de software para estas impressoras era feito em São Paulo. As software houses locais, como a minha, não comunicavam diretamente com o equipamento, nós simplesmente usávamos os drivers que vinham de SP. Eram "caixas-pretas" que faziam o trabalho, e ninguém questionava isso.

Mas eu questionei. A minha inconformidade não era por arrogância, mas por lógica. A minha principal ferramenta na época era o S.O. QNX, um sistema operacional robusto, desenhado para automação e controle industrial, com um domínio profundo sobre comunicação de baixo nível (leia também o artigo "Anatomia de um Sistema Operacional de Tempo Real – Os Segredos do QNX"). Eu passei anos a trabalhar com comunicação serial RS-232, soldando os meus próprios cabos e enviando comandos bit a bit. O meu pensamento foi direto: "O QNX é um sistema para automação. Eu conheço bem a comunicação serial. Eu não preciso de um driver intermediário que não sei como funciona, eu preciso do protocolo".

Esta hipótese simples desafiava todo o status quo do mercado gaúcho. A minha decisão foi ir direto à fonte. Naquela época, não havia Slack ou e-mail instantâneo. Peguei no telefone fixo, conseguir uma linha de celular era uma disputa imensa e um luxo para poucos, e passei horas falando com os técnicos que fabricavam a impressora, uma Sigtron, em São Paulo. Eu não pedi o driver, queria era o padrão de comunicação, o manual com os comandos que eu precisava de enviar pela porta serial para fazer a impressora imprimir um cupom fiscal.

A resposta do outro lado da linha foi um balde de água fria de ceticismo. Lembro-me claramente do tom de quem estava falando com um amador teimoso. Disseram-me, categoricamente, que a minha abordagem "jamais funcionaria". Insistiram que eu precisaria "obrigatoriamente" do driver deles para conseguir a comunicação. Para eles, a ideia de um programador no sul, a usar um sistema operacional de nicho como o QNX, tentar comunicar de forma nativa com o hardware deles era impensável.

Eu desliguei o telefone com duas coisas: o manual de comandos que eu tanto queria e o aviso de que o meu esforço seria inútil. Ignorei o aviso.

Fechado no meu escritório, com o manual em mãos, usei o QNX e a linguagem C 86 para fazer exatamente o que os especialistas disseram ser impossível. Comecei a enviar os comandos diretamente para a porta RS-232, byte por byte, seguindo o protocolo.

E funcionou. Perfeitamente.

Conseguimos a comunicação direta, sem qualquer driver intermediário, sem nenhuma "caixa-preta". Tenho a convicção absoluta de que fomos os primeiros desenvolvedores no Rio Grande do Sul a comunicar diretamente com uma impressora fiscal, de forma nativa.

Hoje, quando olho para trás, vejo que a lição daquela impressora é mais relevante do que nunca. Os drivers, SDKs e frameworks são ferramentas de produtividade fantásticas, mas também são camadas de abstração que nos distanciam do funcionamento real da máquina. A verdadeira engenharia não está apenas em saber usar a ferramenta, mas em entender os princípios por baixo dela. Confiar no conhecimento fundamental, seja ele um protocolo de comunicação, um algoritmo de ordenação ou a arquitetura de uma base de dados, nos permite construir soluções que outros, incluindo os próprios criadores do sistema, podem não ver.

Às vezes, a inovação mais disruptiva não é criar algo novo, mas ter a coragem de ignorar o "jamais funcionará" e provar que, se conhece o protocolo, tu pode fazes as regras.

Este artigo é baseado numa história de "Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código", as memórias do autor.
Leia a história completa aqui.