É muito comum que, após aprofundar-se nos conceitos primários da computação, muitas pessoas da área caiam em questões filosóficas. Muitas vezes realizar um trabalho que hoje é puramente prático é assumir como verdade uma série de definições e hipóteses. Essa semana eu cai em uma artigo do Fowler — muito bom, por sinal — que fazia a relação da comunicação entre os times com a forma como a arquitetura do software é feita. A analogia não era dele, mas sim de uma lei, chamada Lei de Conway. Sua forma direta expressa:
“Qualquer organização que desenha um sistema irá produzir um software cuja estrutura é uma copia da estrutura de comunicação organizacional.”
A lei vai adiante e define que a forma de integração entre os sistemas também é uma replica do que se vê na comunicação entre os diferentes times. Quando há uma organização separada em times, que se integram via qualquer tipo de interface, sua estrutura será similar há interação humana. Segundo o artigo, Conway observou que a melhor forma de garantir uma boa integração era via interação humana. Quando há uma interação saudável e amistosa entre os times, entender conceitos, forma de codificar e a lógica por trás se torna também uma experiência saudável e amistosa. Porém o inverso também é verdadeiro. Quando cada time se isola e cria seu próprio padrão de código, este será bem entendido entre seus integrantes, se bem atomizado, porém sem uma boa interação com o resto da organização não haverá design pattern que resolva.
Portanto, ao tomar decisões que envolvam a estrutura do código, a comunicação dos times também deve ser levada em conta. Segundo a Lei de Conway não adiantará ter um time espalhado pelo mundo, com os melhores programadores, se este time não estiver integrado ou suas atribuições não forem bem definidas e com escopo bem limitado afim de evitar falhas de integração. Isso porque, se por uma lado a integração não pode ser bem resolvida quando se fala de times espalhados pelo mundo, a sua correção pode ser vista do outro, atomizando cada vez mais as atividades e mantendo suas relações em controle absoluto. Um padrão “recente” favoreceu bastante essa tese: Micro-serviços. Ao invés de ter um grande projeto integrado, que favoreceria uma estrutura de comunicação informal e menor, separar esta grande estrutura em pedaços menores compartilhados entre times seria uma melhor abordagem quando se trata de equipes maiores. Cada equipe teria seu escopo, fechado e integrado entre si. E a comunicação com outros seriam minimizadas, apenas estabelecendo padrões e contratos bem definidos e compartilhados(idealmente) afim de garantir integrações suaves.
Porém o mais interessante disso tudo, na minha visão, é que a lógica observada aqui não foi puramente técnica. Não foi puramente algorítmica. Não foi puramente arquitetural. Durante nossos períodos iniciais de estágio e trabalhos, nós tendemos a aproximar muito do código e esquecer dos processos. De observar. De sermos filósofos da nossa profissão de programador. Na minha opinião, Conway precisou sair do mundo dos 0s e 1s para olhar o todo. Ele precisou observar que aquilo que replicavamos no código era, na verdade, um espelho do que fazíamos no mundo real. E nós raramente paramos para pensar sobre isso. Muitas vezes ficamos presos em otimizações, buscando melhorar desempenhos apenas “escovando bits” e às vezes não é nem disso que precisamos. Entender que uma solução não é puramente técnica é de difícil observação, mas acredito que no mundo da computação de hoje ela é cada vez mais necessária. Aqueles que o fizerem estarão não apenas aplicando a técnica, mas relacionando o saber as formas de pensar.
“Qualquer organização que desenha um sistema irá produzir um software cuja estrutura é uma copia da estrutura de comunicação organizacional.”
A lei vai adiante e define que a forma de integração entre os sistemas também é uma replica do que se vê na comunicação entre os diferentes times. Quando há uma organização separada em times, que se integram via qualquer tipo de interface, sua estrutura será similar há interação humana. Segundo o artigo, Conway observou que a melhor forma de garantir uma boa integração era via interação humana. Quando há uma interação saudável e amistosa entre os times, entender conceitos, forma de codificar e a lógica por trás se torna também uma experiência saudável e amistosa. Porém o inverso também é verdadeiro. Quando cada time se isola e cria seu próprio padrão de código, este será bem entendido entre seus integrantes, se bem atomizado, porém sem uma boa interação com o resto da organização não haverá design pattern que resolva.
Portanto, ao tomar decisões que envolvam a estrutura do código, a comunicação dos times também deve ser levada em conta. Segundo a Lei de Conway não adiantará ter um time espalhado pelo mundo, com os melhores programadores, se este time não estiver integrado ou suas atribuições não forem bem definidas e com escopo bem limitado afim de evitar falhas de integração. Isso porque, se por uma lado a integração não pode ser bem resolvida quando se fala de times espalhados pelo mundo, a sua correção pode ser vista do outro, atomizando cada vez mais as atividades e mantendo suas relações em controle absoluto. Um padrão “recente” favoreceu bastante essa tese: Micro-serviços. Ao invés de ter um grande projeto integrado, que favoreceria uma estrutura de comunicação informal e menor, separar esta grande estrutura em pedaços menores compartilhados entre times seria uma melhor abordagem quando se trata de equipes maiores. Cada equipe teria seu escopo, fechado e integrado entre si. E a comunicação com outros seriam minimizadas, apenas estabelecendo padrões e contratos bem definidos e compartilhados(idealmente) afim de garantir integrações suaves.
Porém o mais interessante disso tudo, na minha visão, é que a lógica observada aqui não foi puramente técnica. Não foi puramente algorítmica. Não foi puramente arquitetural. Durante nossos períodos iniciais de estágio e trabalhos, nós tendemos a aproximar muito do código e esquecer dos processos. De observar. De sermos filósofos da nossa profissão de programador. Na minha opinião, Conway precisou sair do mundo dos 0s e 1s para olhar o todo. Ele precisou observar que aquilo que replicavamos no código era, na verdade, um espelho do que fazíamos no mundo real. E nós raramente paramos para pensar sobre isso. Muitas vezes ficamos presos em otimizações, buscando melhorar desempenhos apenas “escovando bits” e às vezes não é nem disso que precisamos. Entender que uma solução não é puramente técnica é de difícil observação, mas acredito que no mundo da computação de hoje ela é cada vez mais necessária. Aqueles que o fizerem estarão não apenas aplicando a técnica, mas relacionando o saber as formas de pensar.