CAFEBABE

«Nuestro objetivo es que la hora del programador cueste lo mismo que la del servicio de limpieza.»

Esto lo dijo un consultor de una gran empresa a un gerente de un proyecto en una empresa del IBEX35. Este mismo gerente me lo comentó durante una comida, mientras hablábamos de por qué no puede haber grandes diferencias entre los sueldos de los programadores.

Mi postura era que, si sabemos que existe un programador que saca el trabajo equivalente de tres personas adelante (y existen), lo normal es que cobrase el doble de sueldo (estaba siendo prudente, porque el sentido común dice que habría de cobrar el triple). Él lo rebatía con un caso muy simple: La hora del programador es fija. Esto es, un programador de una categoría determinada cuesta, pongamos, 35 € la hora y eso es independientemente de su rendimiento.

Existe un baremo inferior, que es básicamente que, si el programador no da la talla, se le sustituye, pero no existe un baremo superior. Así, para un mismo puesto, un programador pasable cuesta lo mismo que un programador excelente. Por lo tanto, es imposible pagarle el doble a nadie, ya que enseguida se entra en pérdidas. ¿Que saca el doble de trabajo adelante? No importa, lo que importa es el precio por hora.

Todo este pensamiento está basado en una falacia: los programadores son perfectamente intercambiables entre ellos. Solo se necesita alguien que les diga lo que tienen que hacer y ellos se dedicarán a mecanografiar el código. Por eso hay gente ilusionada con mano de obra barata de factorías de la India, con la que pretenden bajar más el precio por hora hasta el nivel del servicio de la limpieza. (Quisiera aclarar que no tengo nada contra el servicio de la limpieza. La comparación no es mía).

La realidad es que programar no es equivalente a mecanografiar. Un programa se puede hacer de muchas maneras distintas y hay algunos programadores que siempre tienden a hacerlo de la mejor manera posible. La diferencia entre hacerlo normal y bien pueden ser días de trabajo en proyectos normales y semanas en grandes proyectos. Imaginemos la diferencia entre hacerlo pasable y excelente. Además, los buenos programadores tienden a crear un código sin grandes errores y fácilmente mantenible, lo que repercute en el mantenimiento posterior.

Entrados en este vicio del precio por hora, hay programadores que se frustran al ver que sacan proyectos adelante y lo único que obtienen son problemas. ¿El proyecto no funciona? Pongamos a este que sabe. ¿La cosa va bien? Pongamos a este que no sabe tanto. Al final, muchos emigran a sitios donde el sueldo es mucho más elevado (léase Estados Unidos o Gran Bretaña), otros buscan clientes finales donde pueden romper el vicio del precio por hora y otros dejan la programación y se dedican a gestionar.

Y es que, amigos míos, gestionar tiene algo llamado primas, beneficios, comisiones o como se quiera llamar, que puede hacer que los sueldos se disparen. El porqué un programador que termina un programa en la mitad de tiempo lo único que puede esperar es que le pongan a hacer otro programa y no una prima es algo que se escapa a mi razonamiento.

Confieso que cuando me dicen que evalúe de 1 a 10 mis conocimientos de Java dudo bastante qué poner.

Poner un 10 me parece excesivo. Sí, tengo buenos conocimientos de Java, conozco sus instrucciones, tengo un razonable conocimiento de la JDK y de la JVM, y sé leer el bytecode de un programa compilado para ver qué hace. ¿Es eso un conocimiento de 10? Bueno, un 10 representa la perfección. Si me dijeran que programase directamente en bytecode, habría de documentarme primero. Además, no conozco todas y cada una de las cuatro mil y pico clases de la JDK; siempre encuentro alguna función nueva que desconocía. ¿Es eso un 7? ¿Un 8? Ni idea. Por otra parte, hay mucha gente que no duda en poner un 10 y, seamos sinceros, hay más personas que se autoevalúan con un 10 que con un 8. Si yo no pongo un 10, parecerá que no domino suficiente. ¿Qué hacer? Siempre dudo.

Por si fuera poco, hay gente que ya no tiene suficiente con un 10: existen los gurús, los ninjas, los jedis de nuestros tiempos. Sus conocimientos ya no se pueden evaluar de 0 a 10; al parecer, hay que inventar una nueva categoría. Y no solo eso, ¡cada vez hay más! Regocijaos, porque sin duda es una señal de que la llegada del Javatar está próxima. ¿Tendré yo un nivel gurú y no me habré dado cuenta? Lo dudo.

A lo largo del tiempo, he visto gente que se autoevaluaba con nivel 10 de Java, incluso con un nivel gurú o que decían ser un Java Ninja, y he tenido la oportunidad de hacerles algunas preguntas. La realidad es que ninguno me ha parecido que dominase Java. Si pregunto para qué sirve volatile, la respuesta no puede ser «Esto lo vi en la certificación, pero ya no me acuerdo». ¿No estaba hablando yo con un gurú? Si sus conocimientos son de 10 o más, habría de saber todas las instrucciones de Java, ¿no? ¿O será que soy demasiado estricto?

Para mí, el problema es que si alguien dice que es un Jedi, tiende a creer que sus opiniones son las más válidas y no se le piden explicaciones. Después de todo, estamos hablando de un Jedi, los mismos que destruyeron la estrella de la muerte y liberaron la galaxia. ¿Qué podría ir mal con uno de ellos al mando?

Bueno, permitidme una historia personal. Una vez, en un proyecto en el que estuve, se encontró con un error de Hibernate. Esto no es de por sí raro; es normal encontrarse errores en librerías de terceros. En este caso, el error estaba en la cola de acciones (ActionQueue) de Hibernate. No quiero aburriros con los detalles; la cuestión es que, bajo ciertas condiciones muy pero que muy concretas, al lanzar una consulta, Hibernate fallaba con un ArrayIndexOutOfBoundsException. La solución era añadirle un parámetro particular (quitar el flush) a esa consulta y ya está. Pero no todo podía ser tan fácil: ese proyecto tenía unas librerías de arquitectura que eran las encargadas de lanzar las consultas, y esas librerías estaban a cargo de otra empresa que tenía un gurú de Hibernate como arquitecto. Y lo más importante, todos los jefes (que no sabían nada de Hibernate) creían que era un gurú y su opinión era canon. Resumiendo una historia de meses, el error no se corrigió porque no nos dejaba poner ese parámetro. En cambio, impuso una solución que leyó en StackOverflow, que era modificar el flush en toda la aplicación en lugar del de solo esa consulta. Si alguien entiende de Hibernate, ya se puede imaginar el impacto de ese cambio. Ni que decir tiene que su solución no funcionó. No funcionó porque el arquitecto no comprendía lo que sucedía; no entendía por qué fallaba Hibernate porque no entendía cómo funcionaba la cola de acciones. Sí, esa consulta en concreto ya no daba error, pero había otras consultas que hasta entonces no daban problemas y dejaron de dar el resultado esperado. Las siguientes correcciones no arreglaron nada, sino que hicieron que nos pusiéramos en modo «huida hacia adelante». Había correcciones sobre correcciones, y ya nada tenía sentido. No recuerdo el nombre del arquitecto, pero sí el apodo que le pusieron: «El Jinete del Apocalipsis».

Y aquí es donde quería llegar. Un gurú de Hibernate (y digo Hibernate como podría ser Java, Spring o lo que sea) es aquel que lo conoce todo sobre Hibernate. Conoce cómo funciona internamente, conoce sus clases principales; si tienen algún error, sabe crear un parche que lo solucione y, llegado el caso, sería capaz de volverlo a programar desde cero. ¿Sabes hacer todo eso? Entonces tienes mi respeto. Pero si no es así, siento decirte que no eres un gurú, no eres un ninja, y tus posibilidades de convertirte en Jedi y derrotar a Darth Vader tienden a cero.

La programación siempre se ha movido por modas. Unas veces, un lenguaje o framework son el futuro y, al año siguiente, ya nadie habla de ellos. ¿O acaso alguien se acuerda de Backbone.js o de cuando Ruby on Rails iba a desbancar a PHP?

Hace unos años, se empezó a hablar del Big Data y, por ende, de las bases de datos NoSQL. Big Data estaba de moda y se notaba. Aparecía en cualquier noticia del telediario, los alcaldes hablaban de cómo el Big Data nos iba a cambiar la ciudad y hasta la tienda de la esquina decía que la utilizaba para analizar comportamientos de compra y así reponer productos con antelación. De repente, en todos los proyectos parecía necesario Redis o MongoDB. Vi arquitectos que no eran capaces de hacer una simple join convertirse en expertos en Big Data. Y no solo eso, te daban sabios consejos del tipo: si la base de datos tenía más de un millón de registros, no se podía utilizar SQL y se debía utilizar Big Data. Por supuesto, el problema era que, al no dominar SQL, cualquier consulta con un millón de registros era más lenta que un caracol. ¿Solución? ¡Big Data para todos!

Pero ahora, Big Data ya no es lo más en la programación. Una nueva tecnología ha ascendido y le ha arrebatado su popularidad. Ahora, la nueva estrella es la arquitectura Netflix. ¿Su anterior proyecto fracasó? Eso es porque no utilizó la arquitectura Netflix. ¿O quizás no fue por eso?

La arquitectura Netflix se llama así porque la desarrolló Netflix buscando una solución a un problema concreto: el suyo. Por ejemplo, ¿cuánta gente mira la televisión a las cinco de la mañana? Muy poca. ¿Y a las nueve y media de la noche? Muchísima más. ¿Cuántos servidores necesitaba Netflix? Tantos como para dar servicio al máximo pico de usuarios simultáneos. El problema, claro, es que después de unas horas los servidores reducen su carga y ya no son necesarios. Como Netflix alquilaba los servidores a Amazon, se les ocurrió que lo que tenían que hacer era poder encender o apagar los servidores automáticamente según el número de clientes conectados. ¿Hay pocos usuarios? Cierro servidores y de paso me ahorro dinero. ¿La gente se pone a ver la televisión después de la cena? Los servidores se van encendiendo según necesidad. Elegante y útil. Y esto es solo un problema al que dan solución; existen muchos más.

Ahora bien, nada de esto es gratis. Para que esto funcione, Netflix ha tenido que utilizar tecnologías (Microservicios, por ejemplo) que dificultan cierto tipo de programación. La integridad referencial en bases de datos es una de ellas, las transacciones es otra. Quizás puede parecer poca cosa, pero los que llevamos algo de tiempo en esto y hemos programado sin integridad referencial o sin transacciones les tenemos cierto cariño porque facilitan la vida mucho. Pero mucho, mucho. ¿Por qué hace esto Netflix? Porque, en su modelo de negocio, el video streaming, estas tecnologías no son críticas.

Ahora pensemos. ¿Es buena la arquitectura Netflix? Sin lugar a dudas. ¿Significa eso que en mi próximo proyecto debo utilizar la arquitectura Netflix? No. Como he dicho, la arquitectura Netflix se pensó para un problema concreto: el de Netflix. ¿Tiene tu modelo de negocios alguna similitud con el de Netflix? En la mayoría de los casos, la respuesta es no. ¿Entonces, qué te hace suponer que necesitas su arquitectura? He visto gente proponer arquitectura Netflix para proyectos de no más de cinco usuarios concurrentes. Menos de cinco y ponen una arquitectura para dar soporte a millones. En otros casos, la utilizan en proyectos donde las transacciones o la integridad referencial son críticas. Pero oye, si Netflix está de moda, será por algo.

¿Cuál es la siguiente moda? Solo hace falta ver LinkedIn para darse cuenta: Blockchain. Las criptomonedas están de moda, por lo tanto, Blockchain mola. Ya he visto propuestas de Blockchain para todo y se habla de ella como “la tecnología que cambiará los negocios”.

Así que ya sabes, cuando alguien te proponga utilizar una nueva tecnología como Netflix o Blockchain en tu próximo proyecto, pregúntate: ¿Realmente lo necesito? ¿Qué me aporta respecto a otras tecnologías? ¿Qué me quita? Y, basándote en esas respuestas, toma tu decisión. Pero, por favor, no lo hagas solo porque está de moda.

En 1993, Apple lanzó al mercado el Newton, un dispositivo de un tamaño sin precedentes que, entre otras funciones, era capaz de convertir la escritura manuscrita en texto digital.

El desarrollo del software del Newton estuvo marcado por un ambiente de trabajo extremadamente exigente, con jornadas interminables y sin descanso, ni siquiera durante los días festivos. Se estima que unos treinta desarrolladores programaron un millón de líneas de código. Entre ellos estaba Ko Isono. El 12 de diciembre de 1992, Isono regresó a su hogar, tomó una pistola y se suicidó disparándose en el corazón. Una semana más tarde, otro programador sufrió un ataque de nervios, agredió a su compañero de piso y fue encarcelado. Estos son solo algunos ejemplos de las severas crisis emocionales y de ansiedad que afectaron al equipo.

Ko Isono trabajaba en un proyecto crítico para Apple, no era un becario y, se presume, tenía un salario considerable. Para sorpresa de sus colegas, se había casado recientemente en un viaje a Japón y había traído a su esposa a vivir con él en Silicon Valley. Pronto, su esposa se sintió desolada: estaba en un país extranjero y prácticamente abandonada por su marido, que apenas pasaba tiempo en casa. Aunque el trabajo no fue la única causa, parece razonable considerar que contribuyó significativamente al suicidio de Isono.

¿Por qué el desarrollo del Newton resultó ser tan problemático? Intentaré detallar las tres principales causas que, en mi opinión, hicieron la vida insufrible para el equipo de desarrollo.

• Falsas expectativas: Se prometieron características revolucionarias para el Newton, incluido el reconocimiento de escritura manuscrita. Lo que ahora puede parecer trivial era, hace 25 años, un desafío monumental. De un concepto inicial se intentó pasar directamente a un producto de consumo sin dedicar el tiempo necesario a la investigación. Tras descartar cuatro años de trabajo, se empezó de nuevo desde cero. Sin embargo, esto no mejoró la situación. En una prueba, por ejemplo, al escribir a mano «¿Catching on?» (¿Entendiendo?), el Newton lo interpretó como «Egg freckles» (Pecas de huevo), lo cual se convirtió en una broma interna en Apple.
• Plazos de entrega irreales: Según el New York Times, John Sculley prometió demasiado en muy poco tiempo. Mientras Sculley anticipaba una nueva era en la informática, el desarrollo apenas estaba comenzando. Se fijó como objetivo abril de 1992 para finalizar el Newton, un plazo completamente irreal. Esto llevó a jornadas laborales de 18 horas sin vacaciones. Después del suicidio de Ko Isono, muchos programadores tomaron vacaciones en Navidad, aunque un pequeño grupo permaneció bajo las órdenes de Steven Capps en un «esfuerzo heroico». Finalmente, el Newton se lanzó en agosto de 1993.
• Falta de comunicación: Apple depositó todas sus esperanzas en el Newton, un producto tan adelantado a su tiempo que precedió al iPad por dos décadas. Con la alta dirección presionando para su lanzamiento, era difícil admitir lo que todos los desarrolladores ya sabían antes de comenzar: el Newton no estaría listo a tiempo. Alguien debería haber intervenido y gestionado las expectativas adecuadamente. La falta de comunicación o la negativa a escuchar llevó a una espiral de decisiones equivocadas en un intento desesperado por cumplir con los plazos y las expectativas.

A pesar de que el Newton finalmente se lanzó al mercado, John Sculley ya no estaba al frente de Apple. Aunque el dispositivo contó con un núcleo de seguidores leales, la nueva dirección de la compañía tenía otras prioridades y no promocionó suficientemente el producto. Poco después de regresar a Apple, Steve Jobs descontinuó el Newton, en lo que algunos interpretaron como una venganza contra Sculley, quien lo había despedido en 1985.

La importancia de esta historia

Conocí la historia de Ko Isono en una exposición de Doug Menuez en el Palacio de la Virreina, en Barcelona, y me impactó profundamente. La exposición sugería que Isono se suicidó el día que se decidió descartar todo el trabajo realizado hasta ese momento y empezar de nuevo desde cero, una decisión impactante. Aunque no he podido confirmar si ese fue exactamente el día de su suicidio, los motivos detrás de su trágica decisión siguen presentes. Meses antes de la exposición, presencié a una colega sufrir un ataque de nervios al salir del trabajo. Nos encontrábamos en un proyecto que, inicialmente previsto para tres meses, se extendió por tres años. Las constantes horas extra, el descarte y reprogramación del trabajo, y los plazos de entrega irreales generaron un ambiente de estrés, ataques de nervios, desmayos e insomnio. La irresponsabilidad de algunos tuvo graves repercusiones en la salud de muchos.

Esta situación no es única de aquel tiempo; proyectos actuales siguen enfrentando desafíos similares. Es responsabilidad de todos, desde los programadores hasta los jefes de proyecto y directores de operaciones, identificar y abordar estos problemas.