Quais são as possíveis desvantagens da programação em pares? [fechadas]

A programação em pares é bastante famosa hoje em dia.

Tem várias vantagens como:

1. Programas com menos erros.
2. O custo de manutenção pós-produção é muito menor.
3. As práticas estabelecidas são desafiadas, resultando no surgimento de novas idéias.
4. Os programadores aprendem um com o outro.
5. Programadores desenvolvem habilidades sociais.

Mas quais são as desvantagens da programação em pares?

Embora a programação em pares tenha ganhado uma reputação considerável, ela também apresenta várias armadilhas.

Alguns deles são os seguintes:

1. Na programação em pares, você não pode relaxar e auto-avaliar seu próprio código.
2. Um dos pares pode deixar de estar ativamente envolvido.
3. O driver precisa "programar em voz alta". A programação silenciosa reduz o benefício.
4. Custa mais horas de trabalho para produzir os mesmos recursos. O equilíbrio deve ser mantido entre a qualidade do código e o aumento do custo de codificação.
5. Um fenômeno "vigie o mestre" pode surgir quando um programador experiente e um novato se une. O membro iniciante pode se tornar o observador, com o membro experiente completando a maior parte da codificação.
6. Quando dois usuários experientes se unem, um fenômeno de "ego do desenvolvedor" pode surgir, com cada membro tentando forçar suas próprias idéias.

Eu tentei programar em pares várias vezes, inclusive em uma organização que (brevemente) considerou lançá-la como um processo obrigatório para todos os engenheiros (você pode adivinhar o quão bem essa ideia se desenvolveu). Pessoalmente, eu odiava.

As razões listadas abaixo são apenas minhas experiências subjetivas e não posso "medir" o impacto delas em termos concretos. Mas aqui estão todos iguais:

1 - Ter um 'navegador' e um 'motorista' só ajuda se o primeiro for vocal e o último ouvir.

Todos nós conhecemos desenvolvedores que são teimosos, zelosos com alguma preocupação teórica ou patologicamente incapazes - psicologicamente - de "jogar fora" o trabalho antigo quando alguém sugere um problema com ele. E todos conhecemos indivíduos muito tímidos ou indiferentes para levantar preocupações ou sugerir casos extremos.

Quando esses tipos de desenvolvedores são emparelhados, o navegador assume rapidamente uma função passiva, e o que você acaba fazendo é a programação exclusiva com uma revisão automática de código. Este é um monumental desperdício de recursos.

2 - O emparelhamento impede a criatividade.

Ao contrário do que se pensava anteriormente sobre o valor do 'brainstorming de grupo', o consenso hoje em dia é que o trabalho criativo do conhecimento requer independência e autonomia . Quando você está trabalhando sozinho, pode criar rapidamente uma ideia maluca para ver se é realmente viável. Você pode montar um protótipo estranho sem palavras e, se falhar, não importa, porque ninguém sabe .

Compare isso ao emparelhamento: quando eu quiser experimentar um novo conceito, tenho que convencer meu parceiro, conversar com eles sobre a implementação, passo a passo, e esperar que eles não me julguem se falhar. Esse tipo de ambiente é tóxico para a criação de novas idéias.

3 - Menor designador de denominador comum.

Quando um par não pode criar novas idéias, como acima, ou quando os indivíduos não conseguem concordar com algum princípio fundamental de como um recurso deve ser projetado, o que sai é um design confuso que tenta comprometer e satisfazer ninguém.

Se você associar um desenvolvedor que cria abstrações de programação funcionais maravilhosas, eloqüentes e em direção ao céu com uma aberração de desempenho rápida e suja, o código que eles produzirão juntos normalmente não será terrivelmente elegante nem particularmente rápido.

4 - Falta de autonomia e transparência violenta.

Transparência violenta é uma frase que deduzi de uma polêmica moderadamente famosa (e bastante controversa) contra a metodologia Scrum. Ele descreve a maneira como algumas organizações infantilizam os desenvolvedores e os tratam com a suspeita normalmente reservada para trabalhadores não profissionais.

O que quer que você pense sobre os 'danos' de tornar o trabalho dos desenvolvedores totalmente transparente (e você pode não concordar que é realmente um mal), muitas pessoas valorizam sua autonomia e sua capacidade de trabalhar sozinhas, confiáveis ​​para fazer a coisa certa. É uma necessidade psicológica importante, e forçar os desenvolvedores a parear (como já vi acontecer em pelo menos uma loja) deixará os funcionários consternados, chateados e alienados.

5 - Alguns desenvolvedores simplesmente não jogam bem em pares.

Algumas pessoas não podem ou não podem se comportar adequadamente em um ambiente pareado. Eles podem ter má higiene, maus hábitos de trabalho, uma personalidade abrasiva, uma maneira "barulhenta" e "intensa", ou uma série de outros atributos que os tornam bons trabalhadores individuais, mas pobres programadores.

Você pode resolver isso? Na verdade não. Mudar o comportamento pessoal é difícil. Uma loja de programação em pares precisa ter muito cuidado ao contratar e investir muito tempo para ver como alguém trabalha e se será capaz de trabalhar bem com seus colegas. Discriminar mais a personalidade, no entanto, significa que a contratação levará mais tempo, a menos que você afrouxe seus padrões em habilidades e conhecimentos.

Depende da sua situação ou perspectiva.

A programação em pares é boa para a organização. Mas isso é bom para o indivíduo?

Afinal, é um método de economia de custos (feedback antecipado) e produtividade; Não é sobre você, mas sobre o projeto, produto, empresa ($$).

Embora você possa ter benefícios pessoais, eles não são o motivo ou o fim de qualquer metodologia de desenvolvimento. A programação de pares (em tempo integral), por exemplo, também impede que você relaxe, navegue etc., você precisa justificar suas pausas para o seu parceiro.

O seu parceiro (rotativo) será a melhor câmera de vigilância: a intensidade do trabalho aumenta.

Ou, distribuindo conhecimento, o indivíduo se torna menos arriscado para a empresa (por exemplo, não pode deixar a empresa com conhecimento essencial) e tem menos "fichas de barganha".

Tenho certeza de que você encontrará mais pontos lendo artigos afirmativos de forma mais crítica da SUA situação / ponto de vista real na empresa, e não da perspectiva do seu gerente.

Quase todas as metodologias são escritas da perspectiva do gerente.

1. De repente, agora você tem que dizer a alguém quando você quer ir ao banheiro ou tomar um café. Pelo menos não há necessidade de pedir permissão.

2. Você precisa lidar com os padrões de higiene da outra pessoa.

Além de outras respostas:

1. Muitas empresas nas quais trabalhei para distribuir seus programadores com laptops (com base no local do cliente - é mais fácil manter o equipamento seguro se levado para casa depois do trabalho, sendo capaz de fazer o trabalho estranho de casa na VPN em uma pitada, etc.) atrás, eu já tinha problemas para ver na tela do laptop de outra pessoa (o "driver") do ponto de vista da navegação nos ombros - a idade não melhorará isso (e algumas telas ficam difíceis de ler fora do ângulo de visão ideal em qualquer caso).

   Portanto, os programadores em pares precisarão de telas suficientemente grandes, o que aumentará o custo do hardware e limitará a adaptabilidade ao local. Pode não ser um problema para alguns; em outros casos, será um problema.

2. Também descobri que as diferenças nas preferências de higiene pessoal (incluindo fumar, comer e beber), bem como os conflitos de personalidade, tendem a prejudicar a produtividade. É fácil dizer a dois programadores que "sugam e se dão bem", geralmente isso resulta em pessoas que ficam caladas e sabotam silenciosamente umas às outras por meio de ações passivas-agressivas para desabafar seus ressentimentos.
3. Barulho. Eu, por exemplo, gosto de um ambiente de trabalho silencioso. Não consigo imaginar a conversa constante de alguns grupos de programadores em pares (como você precisa conversar para se comunicar). Até a música vocal nos meus fones de ouvido tende a interferir na minha concentração (instrumentais leves para ouvir no escritório ...). Eu acho que isso pode ser atenuado ao sair do onipresente escritório de plano aberto para salas dedicadas para 2 pessoas, mas isso aumentará o custo novamente.

Anedotas para sua diversão:

• Um empregador anterior já contratou um empreiteiro de outro país (tudo para permanecer anônimo para proteger os culpados). O empregador forneceu alojamento, mas não transporte. Desde que o contratante morou ao longo do meu percurso para o trabalho, fui voluntário para buscá-lo e entregá-lo novamente. Digamos que a higiene pessoal dele não estivesse no mesmo padrão que eu estou acostumado, e ele também fumava muito ("o mais forte!") Enquanto eu não. Em nossa viagem de 15 minutos para o escritório, mantive minha janela abaixada - mesmo no inverno - o que não impediu que meu carro cheirasse como uma sala de fumantes após a passagem de três meses do colega (não, ele não fumava no carro , mas ele fez enquanto esperava por mim).
• Também não fizemos programação em pares, mas nos sentamos um ao lado do outro em uma mesa de conferência (por um tempo). Após cerca de um mês, havia um belo anel marrom na madeira falsa da mesa em torno da posição da mão do mouse do colega. Nesse ponto, consegui uma mesa aberta ao lado da área de plano aberto da central de atendimento, que eu preferia (com a ajuda de meus fones de ouvido).
• Depois, há a onipresente bebida de escritório: café. Embora eu beba, posso me dar bem e não bebo com a mesma frequência de outros colegas de trabalho. Respirar a curta distância pode ser bastante desagradável - semelhante ao cheiro de caneca vazia e esquecida. Vamos chamar a fragrância de "abafado" ...

Acho que a programação de pares falha por razões sociais e práticas. Essencialmente, você está pedindo que uma pessoa trabalhe sob vigilância constante e a outra faça nada além de abrir buracos.

O que inevitavelmente acontece depois de um tempo é que o par se separa para 'checar e-mails' ou 'você faz checagem dessa questão ao vivo' etc.

Em vez de melhorar a saída do código, o volume diminui. Tanto por motivos práticos, 'Eu preciso ir almoçar / me encontrar fora de sincronia com você' quanto social ', vou esperar Bob terminar o que ele está fazendo antes de perguntar sobre se juntar novamente, não quero ser visto como incomodando ele'

Quanto às vantagens vangloriadas, existem muitas práticas comuns que as alcançam de maneiras mais simples e eficazes

Dizer a dois desenvolvedores seniores que façam uma "programação dolorosa" se estiverem confiantes de que é possível fazer o trabalho é a maior desvantagem.