Estamos no iTunes, Spotify e no Deezer.

As implicações da lei de Conway vão muito além da forma como estruturamos as equipes e o reflexo dessa estruturação nos componentes de um software. Como bem observado por Mark Seeman, elas aparecem, também, como consequência do time trabalhar 1) compartilhando um mesmo ambiente físico; 2) de forma remota em horários combinados ou, ainda, 3) de forma remota de forma não sincronizada.

Retomando a lei:

Qualquer empresa que projeta um sistema, inevitavelmente, produz um projeto cuja a estrutura é uma cópia da estrutura de comunicação da organização. (Mel Conway)

Time compartilhando um mesmo ambiente físico

Quando um time trabalha todo em um mesmo ambiente físico, dúvidas são respondidas mais rapidamente. Entretanto, toda vez que alguém precisa esclarecer algum ponto, faz isso as custas de uma interrupção no trabalho de outras pessoas. Ou seja, [tweet]trabalhando em um mesmo ambiente físico, alguém consegue respostas mais rápidas – o que favorece sua produtividade – mas, em compensação, interrompe um ou mais colegas, impactando a concentração e prejudicando a produtividade destes.[/tweet]

[tweet]Quando as pessoas trabalham em um mesmo ambiente físico, por terem acesso mais fácil a informação, geralmente, produzem menos documentação, tomam menos cuidado com o código e deixam as definições arquiteturais mais frouxas.[/tweet] Afinal, é relativamente fácil consultar, diretamente, o “especialista” sempre que dúvidas surgem.

A consequência deste “afrouxamento” é o aumento na frequência das reuniões. Muitas delas, são recursos extremamente custosos para disseminar o conhecimento que poderia estar explícito em outros meios. Entretanto, são os meios mais óbvios e rotineiramente aceito de pagar a ineficiência.

Quando as pessoas trabalham juntas, é natural, e até desejável que todo desenvolvedor, ao iniciar uma tarefa, a encerre. Isso, geralmente é possível pois não ocorrem grandes pausas (espera).

Finalmente, o trabalho de times que compartilham o mesmo ambiente físico facilita o acoplamento, tanto no desenvolvimento, quanto no deploy.

Time trabalhando de forma remota em horários combinados

Em geral, times acostumados a trabalhar compartilhando um mesmo local físico, quando precisam trabalhar remotamente de uma hora para outra (como agora, com o Coronavírus), acabam adotando meios que replicam as práticas do modo antigo. Não é raro que se imponha que as pessoas trabalhem todas nos mesmos horários. Muitas vezes, inclusive, não é incomum que se indique as pessoas “deixar um canal de vídeo aberto” todo o tempo.

Eventualmente, VPNs dão lugar a repositórios de artefatos na nuvem. Entretanto, a dinâmica de interrupções costuma ser preservada. As reuniões dão lugar as “calls” de alinhamento e, com frequência, são ampliadas as práticas de code review e emergem mais documentos (quase sempre resultantes da falta de confiança e não para garantir alinhamento).

O ruído na comunicação acaba forçando a elaboração de designs menos acoplados mas, não raro, os prazos ficam mais elásticos.

Time trabalhando de forma remota de maneira assíncrona

O trabalho remoto, não sincronizado, não permite que dúvidas sejam resolvidas rapidamente. Se alguém tem uma dúvida, precisa utilizar meios de comunicação assíncronos – enviando emails, abrindo tickets de atendimento, etc – e precisa esperar horas ou até dias até obter uma resposta.

[tweet]Quando o time trabalha de forma remota, de maneira assíncrona, precisa criar formas de reduzir a dependência entre seus membros, escrevendo documentações mais amplas, código limpo e arquitetura assertiva.[/tweet]

Eventualmente, desenvolvedores trabalhando em times distribuídos, de maneira assíncrona, vão precisar interagir com os colegas para continuar o trabalho e, por isso, vão experimentar pausas mais longas. Por causa disso, para não sacrificar demais a produtividade, vão precisar abrir outros branches no código e iniciar mais de uma atividade, contrariando práticas indicadas por metodologias ágeis. A necessidade, entretanto, de precisar trabalhar em atividades paralelas implica que a estrutura dos sistemas sejam mais coesas e com acoplamento mais baixo.

[tweet]Times distribuídos, trabalhando de maneira assíncrona, são os mais preparados para desenvolver sistemas distribuídos, como microsserviços.[/tweet]

Concluindo

[tweet]Quanto mais acoplada for a estrutura de comunicação do time, mais acoplados tendem a ser os componentes do software.[/tweet]

Se toda documentação só é útil se for utilizada, é natural que ela seja melhor e mais útil na proporção em que é mais difícil “perguntar ao colega”. De forma análoga, a qualidade do código tende a melhorar quando o custo para entender aumenta e o projeto da arquitetura fica mais relevante quando for mais difícil comunicar mudanças importantes para todos.

Código escrito por um time que compartilha espaço físico costuma ficar “pronto” em menos tempo, com custo de desenvolvimento menor. Já o código escrito por um time distribuído e assíncrono, costuma ser mais “difícil” de fazer mas muito mais barato de manter.

[tweet]Talvez o Coronavírus nos obrigue a aprender formas diferentes de organizar nossos times e isso pode ter impacto muito positivo nos códigos que produzimos.[/tweet]