Logrando resultados cuando se es un pen Por Joel Spolsky Traducido por Leonardo Herrera Editado por Luis Lara

25.12.2001 Este sitio se supone que trata acerca de de la Administracion y Gerencia en el desarrollo de Software. Pero a veces uno no tiene el poder para generar cambios en una organizacin mediante el mandato ejecutivo. Obviamente, si uno es slo un programador al pie del palo ttem, no puede largarse a dar rdenes a los dems para que comiencen a crear planificaciones o bases de datos de errores. Es ms, incluso siendo gerente, es probable que descubra que manejar desarrolladores es muy similar a pastorear gatos, slo que no tan divertido. El mero hecho de decir "hganlo" no garantiza que se hara. Puede ser frustrante cuando uno trabaja en una organizacin que obtiene bajo puntaje en El Test de Joel. No importa que tan bueno pueda ser el cdigo que uno genere, nuestros pares escribirn cdigo tan malo que hace vergonzoso ser asociado con el proyecto. O la gerencia hace malas decisiones acerca de qu cdigo escribir, y uno est forzado a malgastar su talento depurando la versin para AS/400 de un juego para nios sobre planes de jubilacin . Uno podra sencillamente renunciar, supongo. Pero presumiblemente hay alguna otra razn por la cual uno est atrapado aqu. Las opciones de compra de acciones an no se materializan, no existe un mejor lugar para trabajar en Podunk, o quizs nuestro jefe ha raptado a alguien que amamos. En cualquier caso, intentar convivir con un mal equipo puede ser desesperante. Pero existen estrategias para mejorar un equipo desde abajo, y me gustara compartir algunas de ellas. Estrategia 1 Simplemente, hazlo. Mucho puede ser hecho para mejorar un proyecto solamente con una persona. No se tiene un servidor con un build diario? Hagamos uno. Configuremos nuestra propia mquina con una tarea programada para construir la aplicacin durante la noche y enviar por correo electrnico los resultados. Toma demasiados pasos el construir la aplicacin? Escribamos el Makefile. Nadie realiza pruebas de usabilidad? Hagamos nuestras propias pruebas de pasillo con los muchachos encargados del correo, usando un pedazo de papel o un prototipo hecho con Visual Basic. Estrategia 2 Explota el Poder del marketing Viral Muchas de las estrategias de El Test de Joel pueden ser implementadas por una sola persona, an en un equipo indiferente. Algunas de ellas, si son hechas apropiadamente, se esparcirn al resto.

Por ejemplo, supongamos que nadie en nuestro equipo pueda ser persuadido de usar una base de datos de errores. No dejemos que eso nos moleste; slo mantengamos una propia e ingresaremos los errores que encontramos en nuestro propio cdigo. Si encontramos un error que alguien ms debe solucionar, le asignaremos el error en la base de datos; si poseemos un buen programa de seguimiento de errores, ste le enviara un correo electrnico, y ahora podemos seguir envindole correos si no corrige el error. Eventualmente, vern el valor del seguimiento de errores y comenzarn a usar el sistema como es debido. Si el equipo de Control de Calidad se niega a ingresar los reportes de error en la base de datos, simplemente rechacemos los reportes que provengan de cualquier otro medio. Cerca de la trigsima vez que uno diga "escuche, me gustara arreglar eso, pero es seguro que lo olvidar. Podra ingresarlo al sistema de reporte de errores?", ellos comenzarn a usar la base de datos. Nadie en nuestro equipo quiere usar control de versiones? Crearemos nuestro propio repositorio CVS, en nuestro propio disco duro si es necesario. Incluso sin cooperacin, uno puede chequear su cdigo independientemente de el resto. Entonces, cuando se encuentren con problemas que el control de versiones puede solucionar (alguien accidentalmente ingres rm * ~ en vez de rm *~), vendrn por ayuda. Eventualmente se darn cuenta de que ellos tambin pueden realizar llevar su propio registro en el sistema de control de versiones. Estrategia 3 Crea un Repertorio de Excelencia El equipo no disea planificaciones? O no escriben documentos de especificaciones? Escribamos el nuestro. Nadie reclamar si uno se toma un da o dos para escribir un documento de especificaciones mnimo y planifica el trabajo que est por hacer. Logremos reclutar mejores personas para el equipo. Involucrmonos en las contrataciones y en las entrevistas de trabajo, y reclutemos buenos candidatos para incorporarlos al equipo. Encontremos la gente que desean mejorar y son capaces de ello, y pongmoslos de nuestro lado. Incluso en equipos mediocres, es probable encontrar alguien listo que simplemente no tiene la experiencia para crear buen cdigo. Ayudmoslos; influyamos en ellos para que estn dispuestos a aprender. Leamos sus contribuciones al cdigo. Si hacen algo estpido, no les enviaremos un molesto correo explicndoles acerca de sus fallas, pues esto solamente lograr enojarles y ponerles a la defensiva. En vez, inocentemente reportaremos el error que sabemos est siendo causado por su cdigo. Es mejor dejarles y que encuentren por sus medios qu est causando ese error. Cuando encuentren la causa por s solos, habrn aprendido una leccin. Estrategia 4 Neutraliza a los tarados Incluso los mejores equipos pueden tener un tarado o dos. La parte frustrante de tener malos programadores en un equipo es cuando su cdigo defectuoso malogra nuestro trabajo, o cuando buenos programadores deben perder tiempo limpiando los desastres dejados por los malos programadores. Siendo solo un pen, nuestra meta es minimizar los daos, estrategia conocida como contencin. En determinado momento, uno de estos genios tardar dos semanas escribiendo un pedazo de cdigo que resulta ser tan increblemente malo que nunca podr funcionar. Uno es tentado a gastar los quince minutos que tomara rescribir eso mismo desde cero; pero debemos resistir la tentacin, pues es la oportunidad perfecta

para neutralizar a ese idiota por varios meses. Si nos limitamos a reportar errores contra su cdigo, no tendr ms alternativa que mantenerse sudando tinta por meses hasta que no hayan errores. Durante esos meses no podr daar ninguna otra cosa. Estrategia 5 Huye de las Interrupciones Todos los ambientes de desarrollo felices son iguales (oficinas privadas, condiciones tranquilas para trabajar, excelentes herramientas, poqusimas interrupciones e incluso menos reuniones extensas). Todos los ambientes de trabajo tristes son infelices en su forma particular. Las malas noticias son que cambiar el entorno de trabajo es casi imposible en virtualmente toda compaa. Arriendos a largo plazo a veces significan que ni siquiera el CEO puede hacer algo. Eso explica el porqu tan pocos desarrolladores de software obtienen oficinas privadas. Esto daa a sus compaas en al menos dos maneras: primero, hace ms difcil el reclutar desarrolladores de primera lnea, que preferirn a la firma que les entregue mejores condiciones de trabajo (siendo lo todo lo dems igual), y segundo, el nivel de interrupciones puede reducir la productividad de los desarrolladores de forma crtica, quienes encontrarn imposible "alcanzar la zona" y permanecer en ella por cualquier lapso de tiempo. Busca maneras para salir de este ambiente. Llevar un laptop a la cafetera de la compaa, donde hay muchas mesas y estn vacas la mayor parte del da (y donde nadie lo puede encontrar a uno). Reservar una sala de conferencias para todo el da y escribir cdigo ah, y dejar en claro a travs de mucho cdigo registrado en el repositorio CVS que cuando uno est en una habitacin privada se es ms productivo. La prxima vez que un gerente le pregunte a uno que necesita que este Listo Para Maana , sabremos que responder. Ellos encontraran una oficina para facilitarnos durante el da. Y pronto comenzarn a preguntarse qu pueden hacer para mantenerle a uno productivo durante todo el ao. Llegar al trabajo tarde e irse tarde. Esas horas despus de que el resto de la compaa se va a casa pueden ser las ms productivas. O, si uno se encuentra en un equipo donde el resto del equipo usualmente llega tarde, llegaremos a trabajar a las 9 AM. Uno puede realizar ms trabajo en las dos horas antes de que otra gente llegue y comience a molestar que lo que uno hara en el resto del da. No mantener el correo electrnico o la mensajera instantnea corriendo. Se puede chequear el correo cada hora, si se desea, pero no lo mantendremos activo. Estrategia 6 Vuelvete Invaluable Ninguna de estas estrategias funciona si uno realmente no es un gran contribuyente. Si uno no escribe buen cdigo, y mucho, ser mal visto por andar por ah jugando con bases de datos de errores cuando deberas estar escribiendo cdigo. No hay nada ms peligroso para la carrera de uno que tener la reputacin de vivir tan preocupado de los procesos que nunca logra nada. Una vez, cuando comenc un nuevo trabajo como un pen programador en una nueva compaa, descubr que la compaa deba estar en un nivel cercano al 2 cuando se le examinaba con El Test de Joel, y estuve determinado en arreglarlo. Pero tambin saba que entregar una buena primera impresin era crucial. As que reserv las primeras siete horas del da en escribir cdigo, como era de esperarse. No hay nada como una mirada de adiciones al cdigo para verse bien ante los ojos del resto de la

compaa. Pero reserv otra hora cada tarde antes de irme a casa con el fin de mejorar el proceso. Us ese tiempo para arreglar cosas que hacan a nuestro producto difcil de depurar. Configur un build diario y una base de datos de errores. Arregl todas las molestias que haban durado demasiado tiempo y que hacan el desarrollo difcil. Escrib las especificaciones para el trabajo que estaba haciendo durante el da. Escrib un documento explicando paso por paso cmo crear una mquina de desarrollo desde cero. Cuidadosamente document un importante lenguaje interno que estaba indocumentado. Lentamente, el proceso mejor. Nadie ms que yo (y mi equipo, cuando fui puesto a cargo de uno) hizo jams planificaciones de tareas o documentos de especificaciones, pero aparte de eso, logrbamos cerca del 10 en el Test de Joel. Uno puede hacer mejorar las cosas, incluso cuando no se est a cargo, pero uno debe lograr ser como la esposa del Csar: fuera de toda sospecha. De otra forma, se har de enemigos a medida que se avanza.

Joel Spolsky es el fundador de Fog Creek Software, una pequea empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.