Coding é mais sobre times do que você imagina. Entenda o porquê.

Você prefere “codar” sozinho ou discutir suas soluções em grupo?

"Ideias não nascem prontas. Os debates são essenciais para aprimorá-las, estimulando criatividade e inovação."

Assim como uma ideia, um código dificilmente nasce em sua melhor versão. Um desenvolvedor sozinho tende a se contentar com a primeira solução ou a adicionar complexidade desnecessária. 

Sozinho você será capaz de escrever um código que funcione, mas poderá “ignorar” boas práticas de desenvolvimento, aumentando custos com manutenção e chances de erros, principalmente em sistemas de maior complexidade. Sozinho, faltam referências e estímulos para otimizar o que foi escrito. 

Coding é um processo interativo. Código bom precisa estar em constante processo de melhoria, sua otimização ocorre de forma incremental. O processo de otimização terá melhores resultados se feito em grupo, sendo estimulado a partir de discussões, com testes, experimentações e refactoring. 

Construir software sozinho é subestimar nossa capacidade de criar algo realmente grande e aumentar o risco de falharmos. Por trás de milhares de linhas de código ou do design de uma arquitetura altamente escalável, temos a ânsia de criar algo realmente de impacto. Então, por que não aumentar a chance de sucesso compartilhando este processo? 

As vantagens do Collective Code Ownership 

Desenvolver e manter software sozinho são tarefas que envolvem uma série de riscos.

O Collective code ownership é um conceito apresentado pelo Extreme Programming, um dos processos de desenvolvimento ágil mais conhecidos e antigos do mercado. Consiste no fato de que todos do time se sentem responsáveis pelo código e sua qualidade. Qualquer membro pode alterar, evoluir, corrigir falhas e realizar refactoring. Ninguém é dono exclusivo de uma parte ou de todo o código.   

Entre as grandes vantagens deste modelo, está o aumento do “Bus factor e a redução das chances de projetos naufragarem.

"Bus Factor é o número de pessoas que precisariam ser atropeladas por um ônibus (ou qualquer veículo, ou sair de férias, ou mudar de empresa, etc) para que o projeto falhe. Para garantir o sucesso de um projeto, é importante manter este número sempre acima de 1. "

Além do Bus factor, outras vantagens que podemos citar são:

• Comunicação fluída, todos sabem o que está acontecendo;
• Conhecimento compartilhado, estimulado pela rotatividade dos desenvolvedores;
• Menor tempo de resposta aos erros, qualquer um pode fazer um bugfix e corrigir o problema;
• Menos bloqueios e maior produtividade, não é preciso autorização para modificar parte do código;
• Tomada de decisões mais rápidas, todos conhecem toda ou grande parte da base de código, o que gera discussões produtivas;

Lembre-se que desenvolvendo sozinho corremos o risco de percorrer longos caminhos no sentido errado e mesmo que estejamos certo, vai levar muito mais tempo para alcançar os resultados. 

Disciplina e boas práticas

A disciplina do time, o uso de boas práticas e ferramentas na rotina de desenvolvimento são essenciais para o sucesso deste modelo. Entre algumas destas práticas podemos citar:

Code Review: fazer a revisão de todo o código incluído ou modificado é uma excelente forma de compartilhar o conhecimento, seja negocial ou de boas práticas de programação, como clean code. Pode promover a redução de riscos de "quebra" de serviços e promover o feedback rápido para os mais novatos a respeito da qualidade das suas implementações.

Talks/Meetups: possibilitam reforçar os aprendizados dos desenvolvedores e desafios pelos quais passaram. Estimular que elaborem pequenas palestras, pode reduzir o risco de que outros tentem “reinventar a roda” ou cometer os mesmos erros. 

Pair Programming: colocar lado a lado desenvolvedores com perfis, visões e experiências diferentes, pode parecer perda de tempo, mas sem dúvidas, que participa tende a sair melhor e com novos aprendizados. A diversidade de opiniões e pontos de vista, irão criar inúmeras possibilidades de resolução de problemas, além de maiores chances de acerto e ganhos de qualidade.

Daily Meetings: checks diários permitem a resolução rápida de bloqueios do time através do estímulo à colaboração entre os membros. Melhor do que todos com atividades "em andamento", é termos atividades "concluídas". Ponto importante é que a daily deve trabalhar para o time e não como um status report. Deve servir para que todos saibam o que está sendo feito e como podem colaborar para um resultado melhor. 

Responsabilidade de todos != responsabilidade de ninguém

"Cão com muitos donos morre de fome"

A linha é tênue entre todos são responsáveis e ninguém é responsável. O que diferencia é o resultado do time diante de suas responsabilidades, e consequentemente, a confiança e autonomia conquistadas.  

Da mesma forma, ownership coletivo não implica na ausência de liderança. Todo time deve ter um líder, quem remova nossos bloqueios e nos mostre a direção correta. Ter um líder não significa que as decisões devam que ser tomadas de forma unilateral, sendo impostas, mas que podem sim ser tomadas a partir de discussões.

Algumas ações e boas práticas que podem contribuir para a construção da confiança:

• Prevenção de falhas através de um bom nível de cobertura de testes e automação de rotinas de build e deploy;
• Monitoramento do desempenho e disponibilidade das aplicações e serviços;
• Indicadores de desempenho do time;
• Resposta rápida a bugs;

Conclusão

Não limite sua capacidade de desenvolver soluções de impacto. Não aumente o seu risco de falhar. Exponha e discuta seu código. 

Através do coding coletivo e boas práticas de desenvolvimento, podemos gerar um ambiente onde times têm maior confiança e produtividade, soluções são discutidas, modificadas e otimizadas constantemente.

Esqueça aquela história de herói, hacker ou gênio. Grandes produtos e empresas não atingiram sucesso com uma pessoa apenas, mas sim com poderosos times. Afie suas habilidades de comunicação e estimule o comportamento colaborativo no seu time.