No princípio, era o “mainframe”, o enorme computador tipicamente fabricado pela IBM ou outras empresas que fabricavam PCMs (Plug Compatible Machines), como a Fujitsu, Hitachi, Amdahl, que rodavam especialmente o Assembler/370 ou o Cobol. No lado Unix da vida, as máquinas da DEC (Digital Equipment Corporation) dominavam. Esses computadores ficavam em salas geladas, em cima de um piso falso onde passavam cabos de energia e conexão de dados. Para entrar nessa sala, o “técnico” usava um jaleco branco ou azul e ele tinha que ter sido devidamente treinado pelos fornecedores do equipamento. Ele programava a máquina, mas também era o responsável por ligar seus cabos todos, entender o que os usuários queriam e, até mesmo, usar seu ferro de solda e outras ferramentas para aplicar, em campo, as mudanças de engenharia.

Um belo dia, porém, alguém achou que o “programador” do mainframe deveria concentrar-se na lógica do negócio e não mais com o armazenamento de dados. Criaram-se então as unidades controladoras de armazenamento e, com elas, a linguagem SQL, que ficaria não mais a cargo do programador, mas sim de um analista de base de dados: o DBA! Assim começou a grande excrescência da segregação de funções, com especialistas em comunicação, em aplicações clientes (que no mundo web traduziu-se em equipes de back-end e front-end, UX, UI) e a necessidade de se criar múltiplas instâncias de qualidade (já que os programadores, DBAs e outros não conversavam mais entre si e só jogavam a culpa um no outro) e de uma figura funesta capaz de entender e explicar os sistemas aos usuários e todos os demais envolvidos: o arquiteto de sistemas que, claro, ganhou sua própria linguagem, a UML.

Finalmente, há pouco mais de dez anos, em grande parte como fruto do manifesto ágil e seu mantra “Pessoas e suas interações estão acima de processos e ferramentas”, surge a filosofia DevOps que busca fazer com que todas as pessoas conversem e pratiquem a polinização cruzada de seus conhecimentos. Ainda assim, o forte DNA da segregação em TI ainda grita muito forte, separando mais uma vez equipes de funcionalidades. Quando vamos aprender a não mais repetir os erros do passado? É isso que essa palestra busca instigar, de forma anedótica e muito baseada na vida profissional do palestrante.