Gerenciando programadores com eficácia

Quando gerenciando uma equipe de programadores, uma das primeiras coisas que você deve
aprender a fazer direito é alocação de tarefas. Este termo é apenas uma maneira mais elegante para
dar coisas para as pessoas fazerem. Ele é conhecido coloquialmente em Hebreu como “empilhar
pastas” (porque você empilha pastas nas mesas das pessoas). E como você decide que pastas
colocar em que mesas é uma área onde você pode conseguir benefícios incríveis de produtividade
se você fizer corretamente. Se fizer errado você cria uma daquelas situações desconfortáveis onde
ninguém consegue fazer nada e todos reclamam que “nada fica pronto por aqui.”
Como este é um site para programadores, vamos aquecer os cérebros um pouco com um problema
de programação.
Suponha que você tenha duas tarefas para executar, tarefas A e B. Cada uma delas requer 10
segundos de CPU. Você tem disponível uma CPU que, para efeitos desse problema, não tem mais
nada em sua fila de execução.
Nessa CPU, multiprocessamento é opcional. Então você pode executar as tarefas uma após a outra...

Processamento Sequencial
Tarefa A Tarefa B
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

... ou, você pode executá-las concorrentemente. Quando usando multiprocessamento, essa CPU
executa cada tarefa durante 1 segundo, e não gasta tempo algum para trocar entre tarefas.

Multiprocessamento
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Qual forma você usaria para fazer esse processamento? A maior parte das pessoas intuitivamente
escolhe usar multiprocessamento. Em ambos os casos, é necessário esperar 20 segundos para obter
as duas respostas. Mas considere quanto tempo demora para conseguir o resultado de cada tarefa.
Em ambos os paradigmas, o resultado da tarefa B (mostrado em azul) é obtido após 20 segundos.
Mas observe a tarefa A. Com multiprocessamento, ela termina de executar após 19 segundos... mas
com processamento seqüencial ela está terminada em apenas 10 segundos.
Em outras palavras, nesse pequeno exemplo artificial, o tempo de execução médio é mais baixo (15
segundos invés de 19.5 segundos) quando o processamento é feito de forma seqüencial, e
multiprocessamento não é usado. (Na realidade, esse exemplo não é tão artificial assim – é baseado
em um problema real que o Jared precisou resolver no trabalho).

Método Tarefa A demora Tarefa B demora Média

Seqüencial 10 segundos 20 segundos 15
Multiprocessamento 19 segundos 20 segundos 19.5

Assumimos para esse exemplo que uma troca entre tarefas nessa CPU não gasta tempo algum. Na
realidade, em CPUs reais, uma troca entre tarefas demora um pouquinho... basicamente o tempo
necessário para salvar o estado atual da CPU e carregar o estado dela para a outra tarefa.
Realisticamente, esse tempo é o mais próximo de desprezível possível. Mas vamos tornar o
problema um pouco mais interessante e imaginar que cada troca de tarefas demora meio segundo.
Agora o quadro fica ainda pior:
Método Tarefa A demora Tarefa B demora Média
20 + 1 troca de tarefas =
Seqüencial 10 segundos 15.25
20.5 segundos
19 + 18 troca de tarefas = 20 + 19 troca de tarefas =
Multiprocessamento 28.75
28 segundos 29.5 segundos

Agora ... apenas por diversão, sei que isso é absurdo ... e se cada troca de tarefas demorasse um
minuto inteiro?

Método Tarefa A demora Tarefa B demora Média

45
20 + 1 troca de tarefas =
Seqüencial 10 segundos segundo
80 segundos
s
19 + 18 troca de tarefa = 20 + 19 troca de tarefas = quase 19
Multiprocessamento
1099 segundos 1160 segundos minutos!

Quanto mais longa a troca de tarefas, pior é a penalidade por se usar multiprocessamento.
Isso, por si só, não é tão abalador, é? Logo eu estarei recebendo emails irritados de imbecis me
acusando de ser “contra” multiprocessamento. “Você quer voltar para a época do DOS, quando era
necessário sair do WordPerfect para executar 1-2-3?” eles vão perguntar.
Mas esse não é o meu argumento aqui. Eu quero apenas que vocês concordem comigo no seguinte:
a) processamento seqüencial obtém resultados mais rápido em média, e
b) quanto maior o tempo para troca entre tarefas, maior a penalidade de se usar
multiprocessamento
Ok, de volta ao tópico mais interessante de gerenciamento de humanos, não CPUs. A sacada aqui é
que quando se gerencia programadores, especificamente, troca entre tarefas demora muito, muito,
muito tempo. Isso é devido ao fato de programação ser o tipo de tarefa onde é necessário que se
mantenha muitas coisas na cabeça simultaneamente. Quanto mais informação você lembra de uma
vez, mais eficaz você é em programar. Um programador escrevendo código a todo vapor está
mantendo zilhões de coisas na cabeça por vez: desde nomes de variáveis, estruturas de dados, APIs
importantes, nomes de funções utilitárias que ele escreveu e usa frequentemente, até mesmo o nome
do subdiretório onde ele guardou o código fonte. Se você mandar um programador passar férias em
Creta por três semanas, ele vai esquecer tudo isso. O cérebro humano aparentemente move essas
informações da RAM de curto prazo e coloca em uma fita de backup onde demora uma eternidade
para resgatar.
Quanto tempo? Bem, minha empresa de software recentemente largou o trabalho que estávamos
fazendo (desenvolvendo um produto de software cujo codinome era CityDesk) para ajudar um
cliente com uma situação urgente durante três semanas. Quando voltamos para o escritório, pareceu
demorar outras três semanas para voltarmos a velocidade total de desenvolvimento do CityDesk.
No nível individual – já reparou que você pode atribuir um serviço a uma pessoa, e ela vai fazer um
trabalho excepcional, mas se você atribuir dois serviços para a mesma pessoa, ela não vai conseguir
realmente terminar nada? Ela vai ou fazer um serviço direito e esquecer o outro, ou fazer os dois de
forma tão lenta que uma lesma parecerá ágil. Isto é porque tarefas de programação demoram tanto
tempo para serem trocadas. Eu sinto que quando eu tenho dois serviços envolvendo programação
simultaneamente, a troca de um para o outro demora cerca de 6 horas. Em um dia de trabalho de 8
horas, esse multiprocessamento diminui minha produtividade para 2 horas por dia. Bastante
desanimador.
Ao fim e ao cabo, se você der duas coisas para a mesma pessoa fazer, você deveria ficar feliz se ela
se focar completamente em uma das tarefas e esquecer a outra, porque dessa forma ela será mais
produtiva e em média vai terminar as tarefas mais rapidamente. De fato, a real lição a ser aprendida
disso tudo é que você não deveria nunca deixar pessoas trabalharem em mais de uma coisa por
vez. E tenha certeza de que elas saibam no que estão trabalhando. Um bom gerente vê suas
responsabilidades como remover obstáculos para que pessoas possam se focar em uma única coisa
e realmente cumpri-la. Quando uma emergência surgir, pense se você é capaz de resolvê-la sozinho
antes de delegá-la a um programador que está submergido profundamente em um projeto.

Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com

Sobre o Tradutor: Guilherme Otranto é engenheiro de computação formado pela USP, atualmente
trabalha na Olympya TI em desenvolvimento de games e suporte aos softwares da Fog Creek,
www.fogcreek.com.br que são comercializados com exclusividade no Brasil pela
http://olympya.com