¿Cómo funciona el proceso de innovación? O, en cristiano, ¿cómo se hacen cosas nuevas? Respuesta corta: explorando. Respuesta larga: no lo sé, pero tengo algunas ideas al respecto, fruto de muchos golpes de testuz, a lo largo de lo que ya empiezan a ser bastantes años. Véase el resto del artículo.

Hackers

Una entrada de Enrique Dans en su blog ha dado lugar a una interesante conversación sobre los hackers y su papel en el desarrollo de software. Un hacker, en el sentido que le dan los programadores, no es un niñato que se entretiene fisgoneando en ordenadores ajenos; eso es un cracker, un impresentable o un niño mal educado. Un hacker es una mezcla de manitas, manazas, mago, gran programador y chiflado. Es el ingeniero que no puede sufrir un problema mal resuelto, el que escribe su propio programa de gestión de fotos porque los disponibles no son exactamente lo que él cree que necesita.

El hacker es el que es capaz de hacer magia con un editor de textos, el que escribe en un fin de semana la librería que un equipo subcontratado no ha sido capaz de producir en seis meses. No exagero: un gran programador no es un 50% más eficiente que un programador mediocre, ni un 100%. Un gran programador puede ser entre diez y cien veces más eficiente. Esto es: puede resolver un problema en una menos de una décima parte del tiempo que le tomaría a un programador normal, a menudo con menos lineas de código de mejor calidad. Si el problema es suficientemente complejo el gran programador lo resolverá, y el otro no. En palabras de Steve Jobs:

The key observation is that, in most things in life, the dynamic range between average quality and the best quality is, at most, two-to-one. For example, if you were in New York and compared the best taxi to an average taxi, you might get there 20 percent faster. In terms of computers, the best PC is perhaps 30 percent better than the average PC. There is not that much difference in magnitude. Rarely you find a difference of two-to-one. Pick anything.

But, in the field that I was interested in – originally, hardware design – I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1. Given that, you're well advised to go after the cream of the cream. That's what we've done. You can then build a team that pursues the A+ players. A small team of A+ players can run circles around a giant team of B and C players. That's what I've tried to do.

Si el programador normal trabaja en un equipo la diferencia en horas-hombre será todavía mayor, porque el tiempo que tiene que dedicar a la comunicación con el equipo crece exponencialmente con el número de miembros de éste.

Entonces, ¿me compro un hacker?

Parece, con estas credenciales, que un pequeño equipo de hackers es una apuesta ganadora. Pero no todo el mundo está de acuerdo con Jobs, por buenos motivos. Los hackers tienden a ser tipos muy particulares, con los que puede no ser fácil trabajar, difíciles de encajar en la estructura de un equipo de desarrollo reglado. /Managing hackers is like herding cats/.

Si un hacker es un elemento disruptivo en un equipo estructurado, ¿cómo se puede trabajar con ellos? Mi tesis es que no se puede trabajar sin ellos. Dicho de forma un poco más mesurada: si en la estructura de tu proceso de desarrollo no hay lugar para un hacker, seguramente no vas a producir nada nuevo. No estás innovando.

Cuando digo lugar para un hacker me refiero a un hacker ejerciendo de tal: el mundo está lleno de hackers que se pasan el día programando en Java con las orejas gachas, implementando clases que algún analista ha definido y que saben que no servirán de nada. Por la noche hacen drivers para Linux.

Las cosas nuevas se hacen explorando

He aquí el secreto a voces. Por muy listo que seas, por muy listo que sea tu analista, si tu problema es medianamente complejo no sabes cómo vas a acabar solucionándolo. El diagrama de flujo que habéis dibujado puede ayudar a centrar ideas; el UML puede ser una excusa para pensar; la jerarquía de clases puede ayudarte a entender mejor el problema. Pero no vas a escribir unas especificaciones que los programadores se limitarán a implementar. El mundo no funciona así, por eso no hay que preocuparse por Wipro.

El desarrollo está jalonado de imprevistos. En cuanto los programadores empiecen a implementar tus clases se darán cuenta de que tal cosa falla, y éste necesita saber el estado de aquél, y empezarán a hacer trampa, y a guardarse variables que no les tocan, y a acceder a sitios prohibidos, y acabarás con un fantástico montón de espagueti que tal vez funcione. La única especificación que vale para un programa es el código fuente. Si no compila y no funciona no es más que wishful thinking.

No entiendes un programa hasta que has hecho un par de prototipos. No sabes con qué problemas te vas a encontrar hasta que empiezas a tirar del hilo. No sabes si tu programa hace lo que tiene que hacer hasta que tus usuarios lo prueban. Programar es como esculpir cerámica: quitas de allí para poner acá, pules, cortas, miras como queda, y sólo sabes si ha quedado bien cuando ya casi está.

La vida de un programa

La primera fase en la vida de un programa que funciona es la SBS, o Sería Bonito Si. Es la primera planificación, cuando se detecta una necesidad y alguien decide que valdría la pena probarlo. En el mejor de los casos, ese alguien es un hacker, o tal vez un par, que maduran el problema, hacen pruebas, y en dos semanas tiene un primer prototipo, crudo pero funcional. Es el primer apunte, que permite entender el problema y acotar las posibles soluciones.

Cuando los hackers enseñan el prototipo a posibles usuarios empieza la fase NSP, ¿No Se Podría? Cuanto antes empiece la fase NSP más probable que el programa acabe haciendo algo que alguien necesite. Hay que aprovechar la boquita de pedir de los usuarios.

La tercera fase, KPP o Qué Pasada de Programa, empieza cuando los hackers entregan la primera versión funcional a los usuarios. Esta primera versión suele ser la segunda o tercera reescritura del programa, y se parece muy poco al primer prototipo. Si los hackers han usado un lenguaje muy dúctil, como Common Lisp o Python, habrán aprovechado mucho código de aquellos primeros apuntes. Si han usado algo rígido como C++ lo habrán tirado todo un par de veces. Pero el programa funcionará, y hará lo que los usuarios querían.

La cuarta fase es la más difícil, y a menudo no llega. Es la fase LCP, o ¿Lo Cualo Programa? El programa ha pasado a ser parte del entorno de los usuarios, que no se dan cuenta de que lo usan. Para mucha gente Google no es un programa, Google es la web. Lo que me hace pensar que las aplicaciones online hacen más fácil que nunca llegar a la fase NSP rápida e impunemente. Hay que descubrir cuanto antes si alguien lo va a querer.

Obviamente, no todos los programas se hacen así. De hecho, la descripción anterior sólo se puede aplicar con una cierta garantía al desarrollo de una startup (aunque también lo he vivido dentro de una gran empresa). No es casual; es en las startups donde se centra la innovación.

¿Qué hago con mi hacker?

Ponlo a liderar el equipo, organízate a su alrededor, déjale hacer y ten paciencia. Si es realmente bueno los otros programadores lo aceptarán de forma natural. No tengas expectativas poco realistas: en particular, no esperes que sepa lo que le va a costar ni cuánto va a tardar hasta que lo haya hecho. Es un hacker, no un profeta. Para profecías quédate con el analista. Tampoco se te ocurra intentar medir la productividad contando líneas de código, o alguna otra métrica igualmente burda; los días más productivos (y felices) de tu hacker serán cuando consiga eliminar líneas de código.

Págale bien, pero sobre todo asegúrate de que tenga un problema a mano. Lo que realmente motiva a un hacker es un problema sin resolver.

[Organizar el equipo alrededor de una estrella es uno de los consejos de Fred Brooks en su clásico /Mythical Man Month/. El estima el factor de productividad entre programadores buenos y mediocres en 5 o 10. No nos pelearemos por eso.]

[Un par de ensayos interesantes al respecto: How to Become a Hacker, de Eric S. Raymond, y Teach Yourself Programming in Ten Years, de Peter Norvig.]