En este post Mike Hadlow cuenta cómo en uno de sus primeros trabajos estaba bajo la supervisión de un programador que hacía su trabajo bien. La persona había escrito un código prácticamente el solo y Mike tenía que ayudarle a mantenerlo. Al principio a Mike le llamó la atención que el código estaba dividido en un montón de archivos independientes pequeños, en vez de ser un gran procedimiento que lo hacía todo. Poco a poco Mike gracias a las explicaciones de su jefe, y a algunos libros que su jefe le recomendó, fue comprendiendo el código y se dio cuenta que se trataba de un buen diseño que seguía patrones software y que hacía el software fácil de modificar cuando era necesario.
Mike y su jefe no tenían que quedarse horas extra en el trabajo, ni en los fines de semana. Eran capaces de hacer su trabajo dentro del horario de oficina. Pero en la misma empresa había otro equipo que tenía una responsabilidad similar a la de ellos, y que mantenían otro proyecto. Sin embargo ellos siempre estaban quedándose por las tardes, y tenían que ir a veces a trabajar los fines de semana porque su proyecto siempre tenía incidencias y era difícil hacer cambios en el.
En un determinado momento el jefe de la empresa decidió subir sueldos a los empleados, pero decidió que sólo le iba a subir los sueldos al equipo que mantenía la base de código problemática porque "ellos trabajaban más duro que Mike y su jefe".
Mike y su jefe probablemente vivían más tranquilos por haber hecho su trabajo bien, y no tenían que hacer horas extra. Pero se quedaron sin subida de sueldo. Y es que una profesión como la nuestra, en la que es extremadamente complicado saber si alguien está o no trabajando duro o bien, no está claro que siempre sea lo mejor hacer bien las cosas.
Por ejemplo, si uno hace un proyecto bien y después este proyecto no tiene bugs ni incidencias, probablemente el cliente para el que hemos hecho el proyecto no nos necesitepara mantenerlo. Y la realidad es que probablemente te van a pagar lo mismo por haber hecho bien el proyecto, o por no haberlo hecho también.
Hace bastantes años una persona que trabajaba para una empresa de consultoría española me comentó una experiencia en esta línea bastante sorprendente. Esta persona, bastante júnior en aquel momento, estaba en un equipo de dos personas encargadas de hacer una serie de queries sobre unas bases de datos para componer unos informes para ejecutivos de Vodafone. Éste era el único trabajo que realizaban las dos personas.
Esta persona se dio cuenta que la mayor parte de las consultas que hacían seguía unos patrones determinados. Y en el trabajo a ratos libres escribió un script al cual se le pasaba un par de parámetros, y era capaz de generar automáticamente la mayor parte de las consultas que ellos creaban manualmente. No las generaba todas, pero sí la mayor parte. Empleando el script una persona a media jornada podría hacer el mismo trabajo que estaba haciendo ahora dos personas a jornada completa.
Emocionado y orgulloso por su trabajo, el autor del script se lo enseñó a su jefe (no de Vodafone, sino de la consultora). El jefe le dijo que enterrase ese script y que nunca le dijese a nadie que había hecho eso. Que ahora mismo el proyecto en el que estaba él le daba de comer a él y a su compañero, y que como se enterasen los de Vodafone que se podía hacer el mismo trabajo con media persona, pues sobraban un empleado y medio en la empresa.
¿Os habéis encontrado vosotros en situaciones en las que no merece la pena hacer bien el trabajo sino que es más beneficioso hacerlo mal? ¿Conocéis alguna anécdota más del estilo de la de Mike o la mía?