En
la
gestión
empresarial,
especialmente
en
el
ámbito
del
desarrollo
de
software,
los
incentivos
están
diseñados
para
motivar
a
los
empleados
a
alcanzar
sus
metas
con
mayor
eficiencia
y
productividad.
Sin
embargo,
todo
incentivo
mal
formulado
tendrá
efectos
indeseados,
fomentando
un
comportamiento
no
buscado
en
los
miembros
de
la
plantilla.
El
economista
Gary
Becker
ganó
el
Premio
Nobel
de
su
disciplina
en
1992,
gracias
a
la
afirmación
de
que
las
personas
responden
a
incentivos
(bueno,
y
a
toda
la
investigación
que
hizo
en
torno
a
la
misma,
claro).
El
delito
no
se
explicaba,
según
Becker,
por
la
irracionalidad,
enfermedad
mental
o
mera
influencia
social:
los
delincuentes
eran
meros
actores
racionales
reaccionando
ante
los
incentivos
disponibles.
Este
fenómeno
ha
sido
recientemente
resumido
de
manera
concisa
y
humorística
en
un
tuit
viral
por
el
desarrollador
Santiago
L.
Valdarrama,
que
expone
por
qué
intentar
recompensar
el
trabajo
de
los
programadores
basándose
en
métricas
superficiales
suele
conducir
al
fracaso.
Valdarrama
expone
su
caso
a
modo
de
fábula
en
el
que
una
misma
empresa
va
pasando
por
todos
y
cada
uno
de
los
errores
posibles
en
este
campo.
Eso
no
suele
ocurrir,
claro,
pero
sí
es
fácil
encontrar
ejemplos
de
empresas
que
caen
en
uno
u
otro
de
ellos.
Imagen
con
la
que
Valdarrama
ilustraba
su
tuit.
carrera
de
programador
en
2017
y
en
el
futuro
(con
Javier
Santana)
Primer
error:
centrarse
en
los
bugs
Todo
comienza
con
una
medida
aparentemente
lógica:
«Paguemos
más
a
aquellos
que
solucionen
más
bugs».
Este
es
un
enfoque
directo,
que
parece
premiar
a
los
desarrolladores
más
diligentes.
Sin
embargo,
tal
como
señala
el
autor
del
tuit,
esta
estrategia
puede
volverse
rápidamente
en
contra
de
la
empresa…
…pues
al
premiar
sólo
la
cantidad
de
bugs
resueltos,
sin
tener
en
cuenta
el
origen
de
los
mismos,
algunos
desarrolladores
podrían
verse
tentados
a
introducir
fallos
intencionales
en
el
código,
con
la
expectativa
de
corregirlos
posteriormente
y
obtener
la
consiguiente
recompensa.
Así,
el
sistema,
en
lugar
de
mejorar
la
calidad
del
software,
incentiva
la
generación
deliberada
de
errores.
«Me
voy
a
escribirme
un
nuevo
monovolumen»,
así
retrataba
Scott
Adams
la
política
de ‘pago
por
bug
solventado’
en «Dilbert».
Un
caso
famoso
En
realidad,
la
tentación
de
que
el
desarrollador
genere
los
propios
bugs
que
luego
tendrá
que
solucionar
está
siempre
presente,
incluso
cuando
no
hay
de
por
medio
una
política
explícita
de
incentivos.
Hace
un
tiempo
os
hablamos
del
caso
de
David
A.
Tinley,
un
desarrollador
de
software
de
62
años
que
trabajaba
para
Siemens
en
Pensilvania…
y
que
programó
fallos
(mediante
el
uso
de ‘bombas
lógicas’)
en
el
sistema
de
hojas
de
cálculo
que
la
empresa
utilizaba
para
gestionar
pedidos
de
equipos
electrónicos,
asegurándose
de
ser
el
único
capaz
de «repararlos»
y
facturar
por
ello,
Cuando
surgían
los
problemas,
Siemens
recurría
a
Tinley
para
solucionarlos,
y
él
sencillamente
reiniciaba
un
contador
en
el
código,
garantizando
así
futuros
errores
y
su
propia
recontratación.
Este
fraude
le
permitió
mantenerse
en
su
puesto
entre
2014
y
2016,
hasta
que,
en
mayo
de
ese
año,
Siemens
exigió
su
contraseña
debido
a
una
emergencia
mientras
Tinley
estaba
fuera
de
vacaciones.
Al
acceder
al
código,
la
empresa
descubrió
el
engaño.
Y,
finalmente,
Tinley
fue
condenado
a
seis
meses
de
prisión
y
a
pagar
una
multa
de
7.500
dólares.
Segundo
error:
centrarse
en
las «nuevas
características»
La
siguiente
(mala)
idea
de
los
directivos
de
la
fábula
fue
la
siguiente:
«Pagaremos
más
a
aquellos
que
desarrollen
más
características
nuevas».
A
primera
vista,
esto
podría
sonar
como
un
incentivo
más
razonable
que
el
anterior:
al
fin
y
al
cabo,
nuevas
características
aportan
valor
al
producto.
No
obstante,
en
la
práctica,
sin
un
criterio
claro
sobre
qué
constituye
o
no
una «nueva
característica»,
algunos
desarrolladores
pueden
reinterpretar
tareas
menores
como
grandes
avances.
Así,
una
pequeña
modificación
de
interfaz
o
un
ajuste
trivial
podría
presentarse
como
una «innovación»,
mientras
que
los
proyectos
más
complejos
y
cruciales
—que
requieren
tiempo,
esfuerzo
y
planificación—
quedan
relegados.
El
ejemplo
de
Google
Aunque,
según
cómo
gestione
sus
proyectos
la
compañía,
esto
puede
tener
otro
efecto
diferente:
que
las
nuevas
funciones
sean,
efectivamente,
relevantes…
pero
que
nadie
solvente
tenga
ningún
interés
en
darles
mantenimiento.
Ya
os
hablamos
hace
un
tiempo
de
las
críticas
internas
que
ha
experimentado
Google
por
lo
que
sus
desarrolladores
llamaban
el
‘ciclo
LPA’
(de ‘Lanzamiento,
Promoción,
Abandono’),
que
provocan
que
la
progresión
profesional
en
Google
se
basa,
ante
todo,
en
la
participación
en
lanzamientos
(o,
a
lo
sumo,
en «revisiones
importantes»)…
pero
que «a
nadie
le
asciendan
por ‘mantener’
o ‘arreglar
algo
roto'».
«Todos
los
ingenieros
experimentados
y
ambiciosos
abandonan
el
proyecto
inmediatamente
después
del
lanzamiento
[…]
y
se
van
a
un
nuevo
proyecto
/
equipo
donde
pueden
obtener
más
créditos
para
la
promoción.
Las
personas
que
permanecen
son
aquellas
que
no
se
pueden
transferir
fácilmente
a
otros
equipos,
es
decir,
ingenieros
inexpertos
o
sencillamente
mediocres».
Tercer
error:
medir
por
número
de
líneas
de
código
Ante
la
frustración
de
que
se
estaban
incentivando
tareas
insignificantes,
surge
otra
solución
problemática:
«Pagaremos
más
a
quienes
escriban
más
código».
Aquí,
el
razonamiento
es
interpretar
que
a
mayor
cantidad
de
código,
mayor
trabajo
y
productividad.
Sin
embargo,
la
realidad
es
más
compleja.
Al
priorizar
la
cantidad
sobre
la
calidad,
los
desarrolladores
pueden
empezar
a
llenar
sus
proyectos
con
código
redundante,
líneas
en
blanco
o
comentarios
innecesarios.
El
código,
en
lugar
de
volverse
más
eficiente,
se
vuelve
más
voluminoso
y
difícil
de
mantener,
lo
que
a
largo
plazo
genera
una
sobrecarga
en
el
sistema
y
un
deterioro
de
la
calidad
del
producto.
Cuarto
error:
¿qué
mejor
métrica
que
el
número
de
commits?
Desesperados
por
encontrar
un
método
justo
de
compensación,
los
directivos
deciden
recompensar
a
los
desarrolladores
según
el
número
de ‘commits’
realizados
en
GitHub,
el
repositorio
de
código
más
utilizado
en
la
industria.
Aquí,
nuevamente,
el
problema
no
tarda
en
emerger.
Los
programadores
empiezan
a
fraccionar
su
trabajo
en
pequeñas
porciones,
realizando
commits
tras
cada
pequeña
acción:
«una
línea
de
código,
un
commit».
El
resultado
es
un
flujo
interminable
de
pequeños
cambios
que
no
reflejan
un
progreso
real,
pero
que
logran
inflar
las
estadísticas
de
productividad.
Quinto
y
último
error:
a
la
m*
las
métricas,
recurramos
a
las
reseñas
Finalmente,
después
de
una
serie
de
fracasos,
la
empresa
opta
por
una
solución
que
parece
más
difícil
de
corromper:
«Pagaremos
más
según
las
revisiones
de
pares»
(es
decir,
de
las
opiniones
de
los
colegas
del
empleado).
Esta
idea
busca
fomentar
un
ambiente
de
colaboración,
donde
los
compañeros
evalúan
el
desempeño
de
cada
desarrollador.
No
obstante,
en
muchas
empresas,
este
tipo
de
estrategias
abre
la
puerta
a
la
política
interna…
¡Imagínate
pensar
que
la
política
es
difícil
de
corromper!
Por
supuesto,
el
favoritismo
y
las
luchas
de
poder
dejan
rápidamente
a
un
lado
a
la
calidad
del
código,
mientras
que
la
habilidad
para
tejer
alianzas
estratégicas
y
evitar
críticas
se
convierte
en
el
verdadero
indicador
de
éxito.
La
base
del
problema
La
moraleja
de
la
historia
es
que
la
búsqueda
de
métricas
cuantificables
y
fáciles
de
aplicar
es
un
sueño
imposible,
porque
se
basa
normalmente
en
pasar
por
alto
la
complejidad
inherente
al
trabajo
de
los
desarrolladores
de
software:
el
código
no
es
una
simple
serie
de
tareas
que
se
pueden
medir
por
número
o
velocidad.
Imagen
|
Marcos
Merino
mediante
IA
