Alcanzando las notas altas

From The Joel on Software Translation Project

Jump to: navigation, search

Por Joel Spolsky
Lunes 25 de Julio de 2005

Artículo original: High Notes
Traducido originalmente por: Leonardo Herrera
Revisado por: Matias Bellone


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 popular 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 una fortuna. Llamaremos a esto la creencia del "construir una mejor ratonera". Pero el verdadero objetivo de una compañía de software debería ser 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:


Las Mejores Condiciones de Trabajo Los Mejores Programadores El Mejor Software ¡Ganancias!


Es una formula bastante conveniente, especialmente dado que nuestro objetivo 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 del mundo quisieran trabajar") llevaría hacia las ganancias tan naturalmente como el chocolate lleva a la gordura, o el sexo entre personajes de 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 programadores. Incluso usó una metáfora bíblica: se necesita sólo un Rey David y un ejército de soldados sólo capaces de llevar a cabo órdenes. La valorización en la bolsa de su compañía cayó rápidamente de 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 confían en 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 preguntarle a Quark como le está llendo 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 del producto 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 aún no he probado nada. ¿Qué significa ser "el mejor programador"? ¿Hay realmente tanta variación en la calidad del software producido por diferentes programadores?

Comencemos con la vieja y conocida productividad. Básicamente, es 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 no es común que a dos programadores se les encargue la misma tarea.

Los datos en los cuales me respaldo vienen del profesor Stanley Eisenstat, de Yale. Cada año imparte un curso de programación intensiva: CS 323, donde una gran proporción del trabajo consiste en aproximadamente cinco tareas de programación con una duración estimada de dos semanas cada una. Estas tareas son bastante serias para una clase de universidad: implementar una interfaz de línea de comando (shell) de Unix, implementar un compresor de archivos ZLW, etc.

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

Pasé algo de tiempo digiriendo 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 destinadas a cada una de las doce tareas. Los resultados:

Proyecto       Prom. (Hs.)    Min. (Hs.)      Max. (Hs.)    Desv. Est. (Hs.)
CMDLINE99      14.84          4.67            29.25         5.82
COMPRESS00     33.83          11.58           77.00         14.51
COMPRESS01     25.78          10.00           48.00         9.96
COMPRESS99     27.47          6.67            69.50         13.62
LEXHIST01      17.39          5.50            39.25         7.39
MAKE01         22.03          8.25            51.50         8.91
MAKE99         22.12          6.77            52.75         10.72
SHELL00        22.98          10.00           38.68         7.17
SHELL01        17.95          6.00            45.00         7.66
SHELL99        20.38          4.50            41.77         7.03
TAR00          12.39          4.00            69.00         10.57
TEX00          21.22          6.00            75.00         12.11
TOTAL          21.44          4.00            77.00         11.16

Aquello que salta a simple 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 filtré 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 las estadísticas del profesor Eisenstat son completamente objetivas: son calculadas por una fórmula, basada en la cantidad de tests automáticos que son pasados exitosamente por el código y nada más. No se quitan puntos por demora en la entrega (si bien la calficación que se devuelve al estudiante sí es afectada) o falta de consistencia en el estilo del código (en caso de tenerlo).

De todas formas, éstos son los resultados para el cuartil superior:

Proyecto       Prom. (Hs.)    Min. (Hs.)      Max. (Hs.)    Desv. Est. (Hs.)
CMDLINE99      13.89          8.68            29.25         6.55
COMPRESS00     37.40          23.25           77.00         16.14
COMPRESS01     23.76          15.00           48.00         11.14
COMPRESS99     20.95          6.67            39.17         9.70
LEXHIST01      14.32          7.75            22.00         4.39
MAKE01         22.02          14.50           36.00         6.87
MAKE99         22.54          8.00            50.75         14.80
SHELL00        23.13          18.00           30.50         4.27
SHELL01        16.20          6.00            34.00         8.67
SHELL99        20.98          13.15           32.00         5.77
TAR00          11.96          6.35            18.00         4.09
TEX00          16.58          6.92            30.50         7.32
TOTAL          20.49          6.00            77.00         10.93

¡No hay mucha diferencia! La desviación estándar es casi la misma para el cuartil superior. De hecho, si miras 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 de dispersión 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.

HrsVsScore.png

Básicamente, no hay nada que ver aquí, y ese es el punto. La calidad del trabajo y el tiempo usado simplemente no tienen 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 significativas, 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, probablemente haya algo de trampa. Algunos estudiantes podrían estar reportando más horas de las que realmente se tomaron en los trabajos, con la esperanza de obtener algo de compasión y tareas más sencillas como 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 cuenta. Aún así no creo que sea 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 aún más". Un excelente programador solitario trabajando en una sola tarea no tiene la sobrecarga de la comunicación o la coordinación. Cinco programadores trabajando en la misma tarea deben coordinarse y comunicarse. Eso toma mucho 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 lugar de un par de buenos programadores es que, sin importar 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, jamás 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 rasguñarán 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 nunca alcanza las escalas 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 interpretar esa obra.

¿Tiene el software algo que ver con escalas? "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, software empaquetado, donde el éxito o fracaso de una compañía es un resultado directo de la calidad de su código.

Y hemos visto una gran variedad de ejemplos de gran software, las grandes escalas de 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 increíble!
  • ¡Nuevas funcionalidades espectaculares!
  • ¡Casi todo funciona!

Es la última parte: "¡Casi todo funciona!" la que los hace reir a todos. Y entonces están felices, y se entusiasman con 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!". ¿Cuán buena onda es eso?

Si agregas varios programadores extra al equipo de Windows media Player, ¿alcanzarían esa escala 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 entre ellos a uno de esos gruñones que pensaría que es inmaduro y poco profesional escribir "Casi todo funciona" en el sitio web.

Todo esto sin mencionar el comentario, "Winamp 3: ¡Casi tan nuevo como Winamp 2!"

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

Para el tiempo en que los corporativos cabeza de alcornoque de AOL Time Warner pusieron sus manos en el sitio web, todo lo divertido fue eliminado. Uno casi puede verlos, maldiciendo, iracundos y hechando humo como Salieri en la película Amadeus, tratando de eliminar todos los signos de creatividad que asustarían a una abuela en Minnesota, al costo de eliminar cualquier cosa que indujera el gusto por el producto a la gente.

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 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 suave y perfecta cubierta de su hermoso, sexy iPod con una 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. Es hermosa, se siente bien... como un baño de inmersión. Un compartimiento para batería y todo ese efecto se hubiese perdido.

Apple tomó una decisión basada en el '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 se encuentran Jonathan Ive en cada esquina.

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 esos sonidos viniesen desde la ruedita. Podrían haber economizado dinero, centavos... ¡centavos! haciendo sonar los clic por los audífonos, pero la rueda te hace sentir que tienes el 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 electrónicos 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? ¿Cuándo 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 millonarios a todos en tu compañía para que todos conduzcan hermosos y felices y atrayentes vehículos como el Ferrari Spider F-1 y que aún 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 escalas que hacen 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 la farándula; nadie contrata a Dolly Parton para cantar en una boda. Ésta 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 esa 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 "suficientemente bueno". Tiene que ser especialmente bueno, y con esto quiero decir tan bueno que la gente lo sienta especial. El regalo extra que obtienes de los programadores realmente buenos es tu única esperanza de ser especial. Está todo en el plan:


Las Mejores Condiciones de Trabajo Los Mejores Programadores El Mejor Software ¡Ganancias!

The Joel on Software Translation Project - Español

Personal tools