Do DOS à Web: mudou tudo, menos o problema que o software precisa resolver

“A tecnologia envelhece. O problema do negócio permanece.” — Roberto Brandini, programador desde 1991.

TL;DR

• A regra de negócio que você aprendeu em 1991 ainda vale em 2026 — o que muda é só a tecnologia que implementa.
• Migrar do DOS/Clipper para Windows e depois para a Web me ensinou que o risco não é trocar tecnologia — é trocar sem entender o problema.
• No Posseidom, a mesma regra de comissão de vendedor sobreviveu a quatro eras (Clipper, VB, Web Forms, Angular/.NET) porque o problema do lojista continua o mesmo.
• O perigo real é o desenvolvedor que entra empolgado com o framework novo e refatora uma regra de negócio antes de perguntar o que ela resolve.
• Eu uso IA hoje pra acelerar, não pra decidir — quem decide o que é problema de negócio ainda é o engenheiro que entende o cliente.

~ 14 min de leitura · 2435 palavras

Já faz mais de três décadas que eu sento na frente de um computador pra ganhar a vida programando. Eu comecei a escrever software comercial em 1991, com dezoito anos, em um terminal burro 386 de uma loja de materiais de construção. O sistema era Clipper. O programa rodava em DOS. Eu não tinha Internet, não tinha Stack Overflow, não tinha IA. O que eu tinha era o dono da loja na minha frente dizendo: *”Roberto, hoje não dá pra dar baixa naquele lote de cimento porque a nota não fechou.”*

Era um problema de negócio, não de tecnologia. E a tecnologia, naquela época, era Clipper compilado rodando em DOS com um disquete de 360KB.

Mais de trinta anos depois, eu continuo resolvendo a mesma coisa. Só que agora o “não dá pra dar baixa” virou uma transação ACID num banco PostgreSQL rodando em container no Azure, com um frontend Angular 17 conversando com uma API em .NET 10. O problema continua sendo: *”o lote de cimento precisa dar baixa.”*

A tecnologia virou cinco vezes. O problema do cliente não virou nenhuma.

A tecnologia era uma resposta, não um objetivo

Nos anos 90, quando eu estava no Clipper, a gente tinha limitações reais. Processador 386. 4MB de RAM — quando muito. Tela monocromática. Sem rede. Cada byte economizado no `.EXE` era vitória. Mas o problema do cliente era o mesmo de hoje:

• Emissão de nota fiscal com regras de ICMS por estado.
• Controle de estoque com saldos por depósito, lote, validade.
• Fluxo de caixa que precisava fechar no dia.
• Folha de pagamento que tinha que sair no quinto dia útil.

A diferença entre 1991 e 2026 é que, em 1991, eu codificava isso em Clipper Summer ’87 com `BROWSE()` e `APPEND BLANK`. Em 2026, eu codifico isso em C# com `Entity Framework Core`, `Npgsql`, `Angular Reactive Forms`, e deploy via GitHub Actions.

Mas a regra de cálculo do ICMS sobre uma venda com substituição tributária em São Paulo — essa é a mesma. Está escrita em legislação estadual, e legislação não muda porque o framework mudou.

💡 Ponto-chave: O software empresarial existe pra encapsular e operacionalizar regras de negócio. Linguagens, frameworks e plataformas são veículos. Regras de negócio são o destino.

Eu vejo muita gente começando projeto escolhendo o framework antes de entender a regra. Isso é como escolher o tipo de pneu antes de saber pra onde o carro vai. Pode até andar — mas se o destino for uma trilha, pneu de asfalto não resolve.

1991–1998: DOS, Clipper e a era do código que tinha que caber na memória

Quando eu comecei, a gente não tinha “stack”. Tinha:

• Clipper 5.2 (depois `xBase`) pra camada de dados e regra.
• Arquivos `.DBF` como banco (sem servidor, arquivo local).
• DOS como sistema operacional.
• Impressora matricial com formulários contínuos pra emitir NF.
• Modem de 2400 baud pra alguma coisa mais ousada (raro).

O “frontend” era uma tela cheia de caracteres `█░▒▓` desenhando uma “interface”. Sem mouse, sem cor — ou, no máximo, 16 cores com adaptador VGA. O mouse só virou padrão de varejo por volta de 1994.

Eu me lembro de um sistema que eu fiz pra uma rede de farmácias em 1996. O controle de validade de medicamentos era uma rotina Clipper que lia o `.DBF` de estoque, comparava com data atual e gerava um relatório em impressora matricial. Aquela rotina foi portada pra VB6, depois pra ASP clássico, depois pra Web Forms, depois pra Angular. A regra — “não vende medicamento vencido” — nunca mudou. A rotina que verifica mudou cinco vezes.

E a regra continua certa. Continua valendo dinheiro. Continua sendo auditada pela vigilância sanitária. Isso é o que importa.

1998–2010: Windows, VB, Web Forms e a ilusão do “agora é moderno”

Quando o Windows 95/98 virou padrão e o mercado começou a falar em “interface gráfica”, muita gente achou que a tecnologia virou o objetivo. Lembro de reuniões em que o cliente perguntava: *”Vai ser em Windows?”* — como se o Windows fosse um fim em si mesmo.

A gente migrava de Clipper pra VB6, depois pra ASP, depois pra Web Forms (que era `WebForm1.aspx` + `WebForm1.aspx.cs` com `code-behind`). A Microsoft vendeu a ideia de que bastava arrastar um `DataGrid` e o sistema estava pronto. Eu vi sistema de nota fiscal com `DataGrid`绑定 que travava com 200 itens.

Mas o problema do cliente continuava sendo o mesmo: emitir NF, controlar estoque, fechar caixa. Só que agora a tela tinha fundo azul e botões redondos.

Foi nessa época que eu aprendi uma lição que carrego até hoje:

“A interface nova sem regra de negócio clara é só uma foto. Bonita, mas não funciona.”

Eu migrei sistemas de varejo inteiros de Clipper pra Web Forms entre 2003 e 2009. A maioria dos projetos que eu vi falhar nessa época não falhou por causa do Web Forms. Falhou porque o time não entendia o que o sistema antigo fazia. Ele copiava a tela sem copiar a regra. O resultado era um sistema novo, brilhante, que não fechava o caixa no fim do dia.

⚠️ Cuidado: Modernizar a interface sem mapear as regras que ela executa é trocar uma Ferrari quebrada por um Fusca novo. Você ganha estética, perde funcionalidade.

2010–2020: Web moderna, cloud e a redescoberta do problema de negócio

Quando .NET Core apareceu em 2016 e o Angular virou padrão de mercado em 2017, eu já tinha 25 anos de código nas costas. Foi aí que eu vi uma coisa curiosa: muita gente da nova geração achava que o problema do software era arquitetura.

Eram discussões infinitas sobre microsserviço vs monolito, REST vs GraphQL, Kafka vs RabbitMQ. Tudo válido — mas nada disso é o objetivo. O objetivo continua sendo: *”o lote de cimento precisa dar baixa.”*

A cloud mudou muita coisa. Eu uso Azure desde 2014. Serverless, container, Kubernetes, GitHub Actions — tudo isso mudou a forma como eu operacionalizo a regra de negócio. Mas a regra de negócio continua sendo a mesma que eu codificava em Clipper em 1996.

Um caso real do meu trabalho no Posseidom: o controle de comissão de vendedor por faixa de venda + bonificação por meta. Essa regra existia no Clipper em 1998, sobreviveu no VB6 em 2004, foi portada pra Web Forms em 2008, depois pra .NET Core em 2017, depois pra .NET 10 em 2025. Seis plataformas, uma regra. E a regra continua apitando auditoria interna todos os meses.

Quando eu migrei o Posseidom pra .NET 10 com Angular 17 em 2025, a primeira coisa que eu fiz foi listar todas as regras de negócio críticas. Tinha 73. Dessas, 71 já existiam em 1998. As duas novas vieram de mudanças regulatórias (NFC-e e Reforma Tributária). A tecnologia mudou. A regra do cliente continuou a mesma por 28 anos.

💡 Ponto-chave: Se você está começando um projeto novo, faça a lista das regras de negócio antes de escolher o framework. Se você está modernizando um legado, mapeie as regras antes de tocar numa linha de código. A tecnologia é o último item da decisão, não o primeiro.

2020–2026: IA e a repetição do mesmo erro

Agora, em 2026, eu vejo o mesmo padrão se repetir com Inteligência Artificial.

Time novo começa projeto: *”Vamos usar agente IA com RAG pra automatizar o atendimento ao cliente.”* Legal. Mas qual é o problema do cliente? O que ele está tentando resolver? Qual a regra de negócio por trás daquele atendimento? Se você não sabe, o agente IA vai ser um ChatGPT genérico respondendo “posso ajudar em mais alguma coisa?” enquanto o cliente fica no aguardo há três dias.

A IA é uma ferramenta poderosa. Eu uso IA no meu trabalho de verdade — desde pair programming até análise de logs, geração de boilerplate, validação de migrações. Mas a IA não substitui o entendimento do problema do cliente. Pelo contrário: ela amplifica o que você já sabe. Se você sabe o problema, a IA te ajuda a chegar lá 10x mais rápido. Se você não sabe, a IA te ajuda a chegar errado 10x mais rápido.

Eu uso IA pra:

• Pair programming com Copilot no VS Code — ganho de produtividade de uns 30-40% em código boilerplate.
• Análise de logs de produção com agente local consumindo stacktrace e base de conhecimento.
• Geração de testes a partir de regras de negócio descritas em texto.
• Migração de código entre plataformas (ex: VB.NET → C#, JavaScript → TypeScript).

Mas em todos esses casos, eu já sabia o que queria que o código fizesse. A IA foi o acelerador, não o inventor.

O risco que eu vejo hoje é o mesmo risco dos anos 2000: gente achando que a tecnologia da moda é o objetivo. Nos 2000, era Web Forms. Nos 2010, era cloud. Nos 2020, é IA. Em todas as décadas, o caminho pra falhar foi o mesmo: pular a etapa de entender o problema.

A pergunta provocativa que eu sempre faço

Se a tecnologia mudou tanto nos últimos 35 anos — DOS, Clipper, VB6, ASP, Web Forms, .NET Core, Angular, cloud, microsserviço, IA, agentes, RAG — por que tantos projetos ainda fracassam por não entender o problema do cliente?

Resposta curta: porque entender o problema do cliente dá trabalho. Não é sexy. Não vira tutorial no YouTube. Não é a parte que aparece no LinkedIn.

Entender o problema do cliente é:

• Sentar com o dono da padaria e perguntar como ele fecha o caixa.
• Acompanhar o vendedor no roteiro de visita por uma semana.
• Abrir a nota fiscal rejeitada e descobrir qual regra de ICMS bateu.
• Conversar com o fiscal sobre o que vai mudar na Reforma Tributária em 2027.
• Entender por que o sistema antigo faz aquela `IF` estranha no meio da rotina — e descobrir que ela existe porque alguém perdeu dinheiro em 2003 por causa daquela `IF` não existir.

Isso não é tecnologia. Isso é trabalho de chão. E é onde mora o valor de verdade.

O risco de modernizar a interface sem compreender o funcionamento da empresa

Eu vou ser direto aqui, porque isso é onde eu vejo mais projeto morrendo:

Modernizar a interface sem compreender o funcionamento da empresa é o erro mais caro que uma empresa de software pode cometer.

O que acontece:

1. A empresa contrata um time jovem cheio de Stack Overflow e café. 2. O time olha o sistema legado e pensa: *”Isso é feio. Vamos reescrever.”* 3. Reescreve a tela — bonita, responsiva, com animações suaves. 4. Não pergunta como o sistema antigo calculava comissão, desconto, ICMS. 5. Lança em produção. 6. O vendedor percebe que a comissão dele veio errada. 7. O fiscal percebe que a NF foi emitida com CFOP errado. 8. O cliente percebe que o boleto foi gerado com juros a mais. 9. O sistema novo é bloqueado. O sistema velho, que ninguém queria usar, volta. 10. O time jovem é demitido. O legado fica por mais 10 anos.

Eu já vi isso acontecer cinco vezes. Cinco vezes em cinco décadas diferentes. A tecnologia mudou. O padrão de falha não.

A lição é: antes de modernizar a interface, mapeie as regras que ela executa. Eu mantenho no Posseidom um documento chamado *”Mapa de Regras de Negócio”* — 73 regras escritas em português claro, cada uma com: descrição, motivação histórica, exceções, legislação aplicável, casos de teste. Esse documento é mais valioso que qualquer arquitetura de software. Porque é nele que mora o problema do cliente.

O que eu recomendaria pra quem está começando agora

Se você está entrando no mercado de software empresarial agora, com 22, 25, 30 anos, e está seduzido por React, Vue, Angular, .NET 10, IA, agentes, RAG — tudo válido, tudo útil — eu te dou um conselho de quem está nesse jogo desde 1991:

Não comece pelo framework. Comece pelo problema do negócio.

1. Escolha um cliente pequeno — uma padaria, uma farmácia, uma loja de material de construção. 2. Sente com o dono por uma semana. Entenda como ele ganha dinheiro. Onde ele perde dinheiro. O que ele faz todo dia que dá errado. 3. Liste as 10 regras mais críticas do negócio dele. Escreva em português. Cada regra vira uma frase: *”Se o cliente é A, então aplica-se X; senão, aplica-se Y.”* 4. Só depois escolha a tecnologia. Escolha a tecnologia que te deixa operacionalizar essas 10 regras da forma mais simples possível. 5. Quando o cliente te disser “esse sistema não faz isso que eu precisava”, não mexa no framework. Volte na regra e pergunte: *”O que eu não entendi do seu negócio?”*

Essa sequência — problema → regra → tecnologia — é a mesma desde 1991. Ela é atemporal. Funcionava em Clipper, funciona em Angular, vai funcionar em qualquer coisa que vier depois de IA.

💡 Ponto-chave: O framework da moda te dá empregabilidade. O entendimento do problema do cliente te dá carreira.

O problema do negócio permanece

Eu vou fechar este post do mesmo jeito que comecei: com a frase que resume 35 anos de profissão.

A tecnologia envelhece. O problema do negócio permanece.

Eu migrei o Posseidom de Clipper pra Web Forms em 2008. Em 2025, migrei de Web Forms pra .NET 10 + Angular 17. Em ambos os casos, a pergunta de cabeça antes de começar era a mesma:

*”Quais regras de negócio esse sistema precisa preservar?”*

Se eu tivesse começado pela tecnologia — *”Vou usar Angular porque é o que está no mercado”* — eu teria dois sistemas bonitos e quebrados. Em vez disso, eu tenho um sistema moderno que respeita 28 anos de regra de negócio acumulada.

Quando a próxima revolução vier — IA agêntica, computação quântica, neurointerfaces, o que for — o passo zero vai ser o mesmo:

Entender o problema do cliente antes de escolher a tecnologia.

Se você fizer isso, você sobrevive a qualquer virada de plataforma.

Se você não fizer, você vai estar lá em 2050 reescrevendo o mesmo sistema em mais uma linguagem nova, se perguntando por que ele ainda não funciona.

### TL;DR

• Tecnologia é veículo. Regra de negócio é destino.
• Dos 35 anos que eu programo, a regra mudou duas vezes (NFC-e e Reforma Tributária). A tecnologia mudou cinco.
• Antes de modernizar, mapeie as regras de negócio. Modernizar a interface sem regra clara é trocar foto bonita por sistema quebrado.
• IA, cloud, microsserviço — tudo isso é meio. Não é fim.
• Se você não entende o problema do cliente, a melhor ferramenta do mundo vai te ajudar a chegar errado mais rápido.

Leitura relacionada

Se você chegou até aqui, estes outros posts do blog continuam a conversa:

• Web Forms 4.8 ou .NET 10: quando a migração deixa de ser opção? — onde eu mostro os sinais de que a modernização do legado virou inevitável.
• O risco de não migrar do Web Forms para .NET 10 — o reverso da moeda: ficar parado também é decisão.
• Stack pessoal com Hermes: por que parei de delegar tudo — quando IA entra no fluxo de trabalho de quem programa há 35 anos.
• Hermes vs ChatGPT, Claude, Gemini: próprio ou comercial? — a próxima revolução da moda em IA, pelos olhos de quem já viu cinco revoluções virarem rotina.
• O que melhora ao migrar do Web Forms para .NET 10 e Angular? — quando a modernização dá certo, o que muda de verdade (e o que não muda).

*Roberto Brandini é desenvolvedor de software empresarial há 35 anos. Fundador da DP Sistemas e criador do Posseidom, ERP que atende varejo, atacado, distribuidoras e indústrias no Brasil. Este post faz parte da série “Tecnologia ontem versus hoje”, que compara o que mudou e o que permaneceu no desenvolvimento de software ao longo das décadas.*