É muito interessante notar a reação das pessoas quando tentamos introduzir a idéia da programação em par. A primeira reação, normalmente é:
Porque devo colocar duas pessoas para fazer o trabalho de uma?
Este argumento, em primeira vista válido, não passa de uma avaliação superficial do que realmente ocorre em um processo de desenvolvimento. A maioria das pessoas acredita que o processo de desenvolvimento seja, em sua essência, escrever código. Mas, não é. Na verdade, escrever código é a menor parcela neste processo. A maior atividade neste processo é pensar.
Quem já tem alguma vivência no mundo do desenvolvimento, sabe que quando colocamos a mão no código, já temos algo em mente que precisa ser implementado. Não estou me referindo a UML, análise antes de implementar ou waterfall. Antes de escrever qualquer linha de código você deve (ou deveria) saber porque está escrevendo aquilo, isto é, quais são seus objetivos. Antes de escrever essa primeira linha, você já tem uma idéia da lógica que será usada.
Nesse ponto, é possível provar a importância da programção em par, pois é onde temos o maior risco de decisões ruins e inserir erros. Estes erros irão custar tempo de desenvolvimento no futuro. E tempo é dinheiro.
O grande valor da programação em par está na possibilidade de pequenas correções de curso, e eliminação de erros logo assim que eles aparecem. Esses erros podem ser sutis e um overlook do par pode impedir que sigam adiante possibilitando, dessa forma, a correção prematura, permitindo a empresa economizar muito dinheiro com esforço em manutenções futuras.
O quanto é esse muito?
Quando estamos lidando com dinheiro, precisamos quantificar com precisão o que está envolvido. E, Dave Nicolette, fez isso de forma brilhante neste artigo, baseado em sua experiência. No artigo, ele mostra com números, a realidade de uma empresa que adota a programação em pares no seu dia-a-dia.
Sites relacionados:
InfoQ
