Joel on Software   La Opinión de Joel sobre qué es Software

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

En Marzo de 2000 lancé este sitio con el tembloroso argumento que la mayoría de la gente está equivocada al pensar que se necesita una idea para crear una compañía de software exitosa.

La creencia común es que cuando se está creando una compañía de software, el objetivo es encontrar una buena idea que solucione un problema que no haya sido solucionado antes, implementarla y hacer fortuna. Llamaremos a esto la creencia del "construir una mejor ratonera". Pero el verdadero objetivo de una compañía de software es convertir capital en software que funcione.

Durante los pasados cinco años he estado probando esta teoría en el mundo real. La fórmula para la compañía que fundé con Michael Pryor en Septiembre de 2000 puede resumirse en cuatro pasos:

Es una formula bastante conveniente, especialmente dado que nuestra meta real al comenzar Fog Creek era crear una compañía de software donde nosotros quisiéramos trabajar. En esos días afirmé que buenas condiciones de trabajo (o, puesto de una manera bastante torpe, "construyendo una compañía donde los mejores desarrolladores de software en el mundo quisieran trabajar") llevaría hacia las ganancias tan naturalmente como el chocolate lleva a la gordura, o el sexo entre caricaturas en los juegos de video lleva al aumento de las balaceras estilo gángster.

Por ahora, en todo caso, quiero responder a una sola pregunta, pues si esta parte no es verdadera, toda la teoría se cae en pedazos. Esta pregunta es: ¿tiene siquiera sentido hablar sobre tener los "mejores programadores"? ¿Hay, realmente, tanta variación entre los programadores como para que esto tenga alguna importancia?

Quizás es obvio para nosotros, pero para muchos esta afirmación aun necesita ser probada.

Varios años atrás, una compañía más grande estaba considerando comprar Fog Creek. Inmediatamente supe que esto no sucedería cuando escuché al CEO de esa compañía decir que no concordaba con mi teoría de contratar los mejores. Incluso usó una metáfora bíblica: se necesita sólo un Rey David, y un ejército de soldados quienes deben sólo ser capaces de llevar a cabo las órdenes. La valorización en la bolsa de su compañía prontamente cayó desde 20 a 5, así que fue afortunado que no aceptásemos la oferta, pero es difícil de achacar este hecho a su fetiche con el Rey David.

Y, en realidad, la sabiduría convencional en el mundo de los periodistas de negocios (quienes sólo se copian unos a los otros) y de las grandes compañías que dejan que consultores sobrepagados piensen por ellos, mastiquen su alimento, etc., parece ser que lo más importante es reducir el costo de los programadores.

En otras industrias, barato es más importante que bueno. Wal*Mart llegó a ser la corporación más grande de la Tierra vendiendo productos baratos, no productos buenos. Si Wal*Mart tratase de vender bienes de alta calidad, sus costos se dispararían y toda su ventaja comparativa de precios bajos se perdería. Por ejemplo, si tratasen de vender un calcetín que pueda aguantar los raros rigores de, digamos, ser lavados en una máquina lavadora, tendrían que usar toda clase de componentes costosos, como por ejemplo, algodón, y el costo de cada uno de esos calcetines subiría.

Así, ¿porqué no hay espacio en la industria del software para un proveedor de bajo costo, alguien que use los programadores más baratos disponibles? (Recuérdenme de preguntarle a Quark como le fue con su plan "despidamos a todos y contratemos reemplazos de bajo costo").

La respuesta es esta: producir unidades en el software tiene costo cero. Esto significa que el costo de los programadores se reparte entre todas las copias del software que vendes. En el software, puedes mejorar la calidad sin incrementar el costo de cada unidad vendida.

Esencialmente, el diseño añade valor más rápido de lo que agrega costo.

O, dicho de manera simple, si tratas de economizar en programadores, tu software será mediocre, y ni siquiera habrás economizado tanto dinero.

Lo mismo aplica en la industria del entretenimiento. Vale la pena contratar a Brad Pitt para tu última película taquillera, incluso cuando pide un salario estratosférico, pues ese salario se puede dividir entre las millones de personas que irán a ver la película por el simple hecho de que Brad Pitt está increíblemente bueno.

O, puesto de otra manera, vale la pena contratar a Angelina Jolie para tu última película taquillera, incluso cuando pide un salario estratosférico, pues ese salario se puede dividir entre las millones de personas que irán a ver la película por el simple hecho de que Angelina Jolie está increíblemente buena.

Pero aun no he probado nada. ¿Qué significa ser "el mejor programador"? ¿Hay realmente tanta variación en la calidad del software producida por diferentes programadores?

Comencemos con la vieja y conocida productividad. Es básicamente difícil el medir la productividad de un programador; casi toda las métricas que puedas intentar (líneas de código depurado, puntos de función, número de argumentos en la línea de comandos) es simple de engañar, y es difícil el obtener datos concretos en proyectos grandes pues es muy difícil que a dos programadores se les encargue la misma labor.

Los datos en los cuales me respaldo vienen del profesor Stanley Eisenstat, de Yale. Cada año imparte un curso, CS 323, que es muy intensivo en programación, y donde una gran proporción del trabajo consiste en aproximadamente diez tareas. Estas tareas son bastante serias para una clase de universidad: implementar una interfaz de línea de comando de Unix, implementar un compresor de archivos ZLW ^[1], etc.

Esta clase generó tanto malestar entre los alumnos (por la cantidad de trabajo que requería) que el profesor Eisenstat comenzó a preguntarles a los estudiantes cuanto tiempo pasaban en cada tarea. Esta información ha sido recolectada cuidadosamente a lo largo de varios años.

Pasé algo de tiempo procesando esta información; es el único conjunto de datos que conozco donde hay varias docenas de estudiantes trabajando en tareas idénticas, usando la misma tecnología y al mismo tiempo. Es muy controlado, como debe ser un experimento.

Lo primero que hice con estos datos fue calcular la mínima, máxima, promedio y desviación estándar de horas usadas en cada una de las veinte tareas. Los resultados:

El hecho más obvio que salta a la vista son las altas variaciones. Los estudiantes más rápidos finalizaron tres o cuatro veces más rápido que los estudiantes promedio, y a veces llegaron a ser diez veces más rápido que los estudiantes más lentos. La desviación estándar es grosera. Mi pensamiento inicial fue "Hmmm, quizás algunos de estos estudiantes están haciendo un trabajo terrible". No quería incluir a estudiantes que pasasen 4 horas trabajando en la tarea sin producir un programa funcional. Así que limpié los datos y sólo incluí los datos de los estudiantes cuyas notas estuviesen en el cuartil superior... el 25% superior, en términos de la calidad del código. Debo mencionar que las calificaciones en la clase del profesor Eisenstat son casi completamente objetivas: son calculadas por una fórmula, basado en cuantos tests automáticos son pasados exitosamente por el código, y unos pocos puntos por estilo, dados por cosas como sangrías adecuadas y comentarios.

De todas formas, estos son los resultados para el cuartil superior.

¡No hay mucha diferencia! La desviación estándar es casi exactamente la misma para el cuartil superior. De hecho, cuando se miran cuidadosamente los datos es bastante claro que no hay una relación clara entre el tiempo usado y la calificación. Acá hay un gráfico disperso típico de uno de los trabajos. Escogí la tarea COMPRESS01, una implementación de la compresión Ziv-Lempel-Welch dada a los estudiantes en el año 2001, porque la desviación estándar fue muy cercana a la desviación estándar total.

Básicamente, no hay nada que ver aquí, y ese es el punto. La calidad del trabajo y el tiempo usado no tienen, simplemente, ninguna relación.

Le pregunté al profesor Einsenstat acerca de esto, y me indicó una cosa más: debido a que las tareas deben ser entregadas en una fecha límite (usualmente a medianoche) y las penalizaciones por llegar tarde son draconianas, un gran número de estudiantes terminan de trabajar antes de que el proyecto haya sido finalizado. En otras palabras, el tiempo máximo gastado en estos trabajos parcial, pues sencillamente no hay tiempo suficiente para terminar el trabajo. Si los estudiantes tuviesen tiempo ilimitado para trabajar en los proyectos (que sería un poco más correspondiente con el mundo real) la dispersión sería mayor.

Estos datos no son completamente científicos, y probablemente haya algo de trampa. Algunos estudiantes podrían estar reportando más horas que las realmente usadas en los trabajos, con la esperanza de obtener algo de compasión y que les sea dado más tiempo para el próximo trabajo (¡buena suerte! Los trabajos en CS 323 son los mismos hoy que cuando tomé el curso en los '80). Otros estudiantes pueden haber reportado menos horas, sólo por haber perdido la noción del tiempo. Aun así no creo que es una exageración decir que estos datos muestran diferencias en productividad de 5 a 1 o incluso 10 a 1 entre los programadores.

¡Pero esperen, hay más!

 Si la única diferencia entre los programadores fuese la productividad, uno podría pensar que es posible sustituir cinco programadores mediocres por un programador excelente; esto, obviamente, no funciona. La explicación es la Ley de Brooks: "agregar fuerza de trabajo a un proyecto de software atrasado lo atrasa aun más". Un excelente programador solitario trabajando en una sola tarea no tiene la sobrecarga de la comunicación o coordinación. Cinco programadores trabajando en la misma tarea deben coordinarse y comunicarse, y esto toma un montón de tiempo. Hay varios beneficios al usar el equipo lo más pequeño posible; el hombre-mes es realmente mítico.

¡Pero esperen, hay más aun!

El problema real con usar muchos programadores mediocres en vez de un par de buenos programadores es que no importa cuanto trabajen, nunca producirán nada tan bueno como lo que los buenos programadores pueden producir.

Cinco Antonio Salieri no producirán un Réquiem de Mozart. Nunca. Ni siquiera trabajando por 100 años.

Cinco Jim Davis -el autor de ese gato de caricaturas sin gracia, donde el 20% de las bromas son acerca de como los Lunes apestan y el resto sobre como le gusta la lasaña (¡y esa es la parte graciosa!)... cinco Jim Davis podrían pasarse el resto de sus vidas escribiendo comedia y nunca, nunca producir ese famoso capítulo de Seinfeld sobre el Nazi de la Sopa.

El equipo a cargo del Zen de Creative podría pasarse años refinando sus feas copias del iPod y nunca producirían algo tan bello, satisfactorio y elegante como el iPod de Apple. Y no harán mella en la participación de mercado de Apple, porque el talento mágico en el diseño sencillamente no está ahí. Ellos no tienen "eso".

El talento mediocre simplemente no puede alcanzar las notas altas que el talento superior alcanza todo el tiempo. El número de divas que pueden alcanzar el Fa agudo de La Reina de la Noche de Mozart es cada vez menor; y sin ese famoso Fa agudo, simplemente no podrías tener La Flauta Mágica.

¿Tiene el software algo que ver con notas altas? "Quizás algunas cosas", dirás, "pero yo trabajo en sistemas de contabilidad para la industria de desperdicios médicos". Correcto. Esta es una conversación sobre compañías que producen software empaquetado, donde el éxito o fracaso de una compañía es el resultado directo de la calidad de su código.

Y hemos tenido una plétora de ejemplos de gran software, las notas realmente altas en los últimos años: cosas que los desarrolladores de software mediocres simplemente no podrían haber creado.

En el 2003, Nullsoft lanzó una nueva versión de Winamp, con la siguiente nota en su sitio web:

• ¡Nuevo look de pelos!
• ¡Nuevas funcionalidades espectaculares!
• ¡Casi todo funciona!

Es la última parte, "¡Casi todo funciona!", la que hace a todos reír. Y entonces están felices, y por lo tanto logran entusiasmarse acerca de Winamp, y lo usan y luego le dicen a todos sus amigos, y todos piensan que Winamp es increíble, todo debido a que escribieron en su sitio web "¡Casi todo funciona!". Cool, ¿cierto?

Si agregas varios programadores extra al equipo de Windows media Player, ¿alcanzarían esa nota alta alguna vez? Nunca, ni en un millón de años, debido a que mientras más gente agregues a ese equipo, lo más probable es que tengan uno de esos gruñones que piensan que es inmaduro y "poco profesional" escribir "Casi todo funciona" en tu sitio web.

Sin mencionar el comentario, "Winamp 3: ¡Casi tan nuevo como Winamp 2!"

Ese tipo de cosas son las que nos hacen querer Winamp.

Para el tiempo en que los cabeza de alcornoque corporativos de AOL Time Warner pusieron sus manos en el, todo lo divertido de su página web fue eliminado. Uno casi puede verlos, maldiciendo, enojados, como Salieri en la película Amadeus, tratando de eliminar todos los signos de creatividad que podrían asustar a una abuela en Minnesota, al costo de eliminar cualquier cosa que habría hecho a la gente gustar de ese producto.

O démosle una mirada al iPod. No puedes cambiar la batería. Así que cuando la batería se agote, que pena. Compra un nuevo iPod. En realidad, Apple la cambiará si se lo envías de vuelta a la fábrica, pero eso cuesta $65.95. Ouch.

¿Por qué no puedes cambiar la batería?

 Mi teoría es que es debido a que Apple no quiso echar a perder la cubierta suave y perfecta de su hermoso, sexy iPod con uno de esas horrendas cubiertas de batería que uno puede ver en esas porquerías de consumo baratas, con todas esos pequeñas compuertas que siempre se quiebran y los bajorrelieves que se llenan de pelusas de tu bolsillo y todas esas asquerosidades en general. El iPod es la más perfecta pieza de electrónica de consumo que alguna vez haya visto; un compartimiento para batería y todo ese efecto de "piedra de río" se habría perdido.

Apple tomó una decisión basada en estilo. De hecho, el iPod está lleno de decisiones que están basadas en estilo. Y estilo no es algo que 100 programadores en Microsoft o 200 diseñadores industriales en la incorrectamente llamada Creative vayan a lograr, pues no tienen a Jonathan Ive entre sus filas, y no hay muchos Jonathan Ive por aquí.

Lo siento, sencillamente no puedo evitar hablar del iPod. Ese hermosa rueda con sus pequeños sonidos de clic... Apple gastó dinero extra poniendo un parlante dentro del iPod para que los sonidos del selector viniesen desde la ruedita. Podrían haber economizado dinero haciendo sonar los clic por los audífonos, pero la rueda te hace sentir en control. A las personas les gusta sentirse en control. Sentirse en control hace a la gente feliz. El hecho de que la rueda responda de manera suave, fluente, y audible a tus órdenes te hace feliz. No como los otros 6.000 aparatos de bolsillo que se demoran tanto tiempo en inicializarse que cuando presionas el botón de encendido debes esperar un minuto para ver si algo pasó. ¿Estás en control? ¿Quién sabe? ¿Cuando fue la última vez que tuviste un teléfono celular que se prendiese inmediatamente cuando presionas el botón de encendido?

Estilo.

Felicidad.

Atractivo emocional.

 Estos son los elementos que hacen el gran impacto en los productos de software, en las películas, y en los productos electrónicos de consumo. Y si no logras incorporar de manera exitosa estos elementos en tu producto, quizás tu producto logre su objetivo, pero no lograrás ser número 1 y no podrás hacer a todos en tu compañía millonarios y que todos conduzcan hermosos y felices vehículos como el Ferrari Spider F-1 y que aun les quede dinero para construir un templo hindú en su patio trasero.

No es asunto de ser "10 veces más productivo"; es que el desarrollador que produce "el promedio" nunca alcanzará las notas altas que hacen el gran software.

Lamentablemente, esto no aplica en el desarrollo de software donde no se escriben productos. El software interno raramente importa tanto que justifique contratar estrellas de rock; nadie contrata a Dolly Parton para cantar en una boda. Esta es la causa de que las carreras más satisfactorias que un programador puede obtener son en compañías de desarrollo de software, no realizando IT en algún banco.

El mercado del software, en estos días, es más o menos un sistema "el ganador toma todo". Nadie más que Apple está ganando dinero con los MP3. Nadie más que Microsoft gana dinero en planillas de cálculo y procesadores de texto, y ya sé que Microsoft hizo algunas cosas anticompetitivas para llegar a esta posición, pero eso no cambia el hecho de que es un sistema funciona de esta forma.

No puedes darte el lujo de ser el número dos, o tener un producto "adecuado". Tiene que ser especialmente bueno, y con esto quiero decir, tan bueno que la gente sienta que es especial. El regalo extra que obtienes de los programadores realmente buenos es tu única esperanza de ser especial. Está todo en el plan:

^[1]: A pesar de que el algoritmo es comúnmente llamado "LZW", el paper original daba crédito a Ziv primero, así que pienso que es más apropiado llamar el algoritmo Ziv-Lempel-Welch o ZLW.