Sistemas de Informacin II

Disparar y avanzar
Por Joel Spolsky Hay veces en las que no me sale nada. Fijo. Llego a la oficina, doy un par de vueltas, veo si hay correo cada diez segundos, navego por la red y tal vez haga algunas tareas tontas como pagar la factura de la American Express. Pero lo de volver a escribir cdigo con fluidez no ocurre. Estas lagunas de improductividad por lo general duran uno o dos das, pero ha habido veces en mi carrera como desarrollador que me ha pasado semanas enteras sin ser capaz de hacer nada. Como se suele decir, no ests inspirado. No ests en lo que ests. No ests en ningn sitio. Todos tenemos cambios de estado de nimo. Para algunos, son suaves, pero en otras personas pueden ser ms pronunciados, incluso patolgicos. Y los periodos improductivos parecen estar relacionados con los estados de nimo ms abatidos. Esto me recuerda a los investigadores que afirman que, bsicamente, la gente no puede controlar lo que come, de manera que cualquier intento de hacer una dieta est condenado a ser efmero y siempre terminan rebotando hasta volver a su peso natural. Tal vez no puedo, como desarrollador de software, controlar cundo soy productivo: simplemente he de asumir las pocas espesas con las pocas de rpido avance y esperar que, en trmino medio, pueda escribir suficientes lneas de cdigo como para hacer que quieran contar con mis servicios. Lo que me inquieta es que desde mi primer trabajo me he dado cuenta de que, como desarrollador, en trmino medio slo puedo escribir cdigo productivamente durante dos o tres horas al da. Cuando tuve una beca de verano en Microsoft, un compaero becario me dijo que en realidad slo iba a trabajar de doce a cinco. Cinco horas (menos el almuerzo) y an as su equipo lo veneraba porque an se las apaaba para hacer mucho ms que la media de los dems. Y yo creo que as ha de ser. Me siento un poco culpable cuando veo cmo los dems trabajan tanto y yo slo tengo dos o tres horas de calidad al da y an as siempre he sido uno de los miembros ms productivos del equipo. Quiz por eso, cuando Peopleware y XP (Extreme Programming) insisten en eliminar las horas extras y las jornadas de 40 horas semanales lo hacen con la completa seguridad de que esto no implica una reduccin en el rendimiento del equipo. Pero los das que me preocupan no son en los que "slo" trabajo dos o tres horas. Son aquellos das en los que no puedo rendir nada. Le he dado muchas vueltas a esto. He tratado de recordar cul ha sido la vez en mi carrera que ms trabajo he sacado adelante. Probablemente fue cuando Microsoft me cambi a un nuevo y bonito despacho enmoquetado con grandes ventanas que dominaban un lindo patio empedrado, lleno de cerezos en flor. Todo lata. Durante meses trabaj sin parar, despachando la especificacin detallada de Excel Basic: una montaa de papeles que abarcaban un gigantesco modelo de objetos y todo un entorno de programacin. Literalmente: no poda parar. Cuando tuve que ir a Boston al MacWorld me llev un porttil y document las clases de Windows sentado en una agradable terraza en el HBS [Harvard Business School].

Sistemas de Informacin II

Una vez que te pones manos a la obra no es tan difcil seguir a buen ritmo. Muchos de mis das transcurren de esta manera: (1) ir al trabajo (2) leer el correo, navegar por la red, etc. (3) decidir qu voy a ir a almorzar antes de ponerme a trabajar (4) volver de la comida (5) leer el correo, navegar por la red, etc. (6) decidir por fin que debera empezar (7) leer el correo, navegar por la red, etc. (8) decidir otra vez que debera ponerme a trabajar (9) lanzar el maldito editor y (10) escribir cdigo casi sin parar hasta que no me doy ni cuenta de que ya son las 7 y media de la tarde. En alguna parte entre los pasos 8 y 9 parece haber un bug, porque no siempre puedo dar ese salto. Para m, ponerme manos a la obra es lo nico difcil: un objeto en reposo tender a permanecer en reposo. Hay en mi cerebro algo que pesa muchsimo y es difcil hacer que alcance la velocidad de crucero; pero una vez que la alcanza no cuesta ningn trabajo hacer que siga. Como una bicicleta preparada para atravesar un pas entero: cuando comienzas a pedalear en una bici con todo ese material es difcil de creer cunto cuesta arrancar, pero luego es tan sencillo como ir con una bicicleta sin carga alguna. Quiz sea esta la clave de la productividad: ponerse en marcha. Tal vez cuando la programacin por parejas funciona es porque cuando organizas una sesin de programacin en pareja con tu compaero, ambos os estis forzando a poneros en marcha. Cuando fui paracaidista en el ejrcito israel un general nos dio un pequeo discurso acerca de la estrategia. En las batallas de infantera, segn nos cont, slo hay una nica estrategia: Disparar y Avanzar. Uno se mueve hacia el enemigo mientras a la vez dispara sus armas. El fuego obliga al enemigo a agachar la cabeza de modo que no puede dispararte (eso es lo que quieren decir los soldados cuando gritan "cubridme!", que significa: "Disprale al enemigo de forma que se tenga que esconder y no pueda dispararme mientras cruzo la calle". Y funciona). El avance te permite capturar territorio y acercarte a tu enemigo, donde es ms probable que tus disparos den en el blanco. Si no avanzas, el enemigo decide lo que ocurre, lo cual no es bueno. Si no disparas el enemigo te disparar, teniendo un objetivo fcil. Record esto durante mucho tiempo. Me di cuenta de que casi todas las estrategias militares, desde los combates areos a las maniobras navales a gran escala, estn basadas en la idea de Disparar y Avanzar. Tard otros quince aos en darme cuenta de que el principio de Disparar y Avanzar es la forma en que se hacen las cosas en esta vida. Tienes que avanzar un poquito cada da. No importa si tu cdigo est mal escrito y tiene errores y nadie lo quiere. Si avanzas, escribiendo cdigo y arreglando los errores continuamente, el tiempo est de tu parte. Presta atencin cuando la competencia te dispara. No querrn mantenerte ocupado, reaccionando a sus boleas, de forma que no puedas avanzar? Recordemos la historia de las estrategias de acceso a bases de datos que han surgido de Microsoft. ODBC, RDO, DAO, ADO, OLEDB, y ahora ADO.NET Todas novsimas! Acaso todas son imperativos tecnolgicos? O son el resultado de un grupo de diseo incompetente que necesita reinventar el acceso a base de datos cada ao? (Es probable que, en realidad, sea esto ltimo) Pero el resultado final es que nicamente se trata de fuego de cobertura. La competencia no tiene otra opcin que perder todo su tiempo portando y mantenindose al da, tiempo que no pueden dedicar a desarrollar nuevas prestaciones. Examinemos de cerca el panorama del software. Las compaas que funcionan son las que dependen menos de compaas grandes y no tienen que perder todos sus ciclos de desarrollo ponindose al da, reimplementando y arreglando errores que slo se manifiestan bajo Windows XP. Las compaas que se tambalean son las que pasan demasiado tiempo leyendo hojas de t para vaticinar el prximo movimiento de Microsoft. La gente se preocupa por .NET y decide reescribir todo su cdigo porque creen que tienen que hacerlo. Microsoft te dispara, y slo es fuego de cobertura de forma que ellos puedan avanzar y t no, porque as es como se juega a este juego, chaval. Vas a aadir soporte para Hailstorm? SOAP? RDF? Lo vas a soportar porque tus clientes lo necesitan, o porque alguien te est disparando y te sientes obligado a responder? Los equipos comerciales de las grandes compaas, que

Sistemas de Informacin II

conocen lo que es el fuego de cobertura, van a sus clientes y les dicen: "Vale, no tienes que comprarnos a nosotros. Cmprale al mejor vendedor. Pero asegrate de que compras un producto que soporta (XML / SOAP / CDE /J2EE) porque si no estars atrapado en el software propietario" Luego, cuando las compaas pequeas intentan venderle algo a ese cliente, se encuentran con gerentes obedientes que repiten como cotorras: "Tienes J2EE?" Y lo nico que hacen es perder todo el tiempo desarrollando con J2EE incluso aunque eso no te d ms ventas, y no les da ninguna oportunidad para diferenciarse de los dems. Es una prestacin de catlogo; la implementas porque necesitas el recuadro que dice que lo tienes, pero nadie la va a usar ni la necesita. Y es fuego de cobertura. Para las compaas pequeas como la ma disparar y avanzar significa dos cosas. Tienes que tener el tiempo de tu parte y tienes que avanzar cada da. Tarde o temprano ganars. Lo nico que logr hacer ayer fue mejorar un poquitn el esquema de colores de FogBUGZ. Eso est bien. Est mejorando continuamente. Cada da nuestro software es mejor y mejor y tenemos ms y ms clientes, eso es todo lo que nos importa. Hasta que seamos una compaa tan grande como Oracle, no tenemos que pensar en grandes estrategias. nicamente hay que venir cada maana y, de algn modo, arrancar el editor.

Revisado por: M.C.C. Eric Chvez Ortiz 2009