http://spanish.joelonsoftware.com/Articles/HighNotes.html
Alcanzando las notas altas
Por Joel Spolsky
Traducido por Leonardo Herrera
25 . 7 . 2005
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:
| Las Mejores Condiciones de Trabajo | → | Los Mejores Programadores | → | El Mejor Software | → | ¡Ganancias! |
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:
| Proyecto | Prom Hrs | Min Hrs | Max Hrs | DesvEst Hrs |
|---|---|---|---|---|
| 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 |
| TODOS | 21.44 | 4.00 | 77.00 | 11.16 |
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.
| Proyecto | Prom Hrs | Min Hrs | Max Hrs | DesvEst Hrs |
|---|---|---|---|---|
| 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 |
| TODOS | 20.49 | 6.00 | 77.00 | 10.93 |
¡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:
| Las Mejores Condiciones de Trabajo | → | Los Mejores Programadores | → | El Mejor Software | → | ¡Ganancias! |
Esté articulo apareció originalmente en Inglés con el nombre Hitting the High Notes
Cinco Mundos
Por Joel Spolsky
Traducido por Darío Vasconcelos
Editado por José Luis Sánchez Navarro
Mayo 6, 2002
En la literatura de programación y desarrollo de software algo importante casi nunca es mencionado, y como resultado a veces no nos entendemos entre nosotros.
Tú eres un desarrollador de software. Yo también. Pero puede que no tengamos los mismos objetivos y requerimientos. De hecho, hay varios mundos distintos en el desarrollo de software, y a distintos mundos aplican distintas reglas.
Lees un libro sobre modelado con UML, y en ningún lado dice que no tiene sentido para programar manejadores de dispositivos. O lees un artículo que dice que "el runtime (tamaño en memoria del programa en ejecución) de 20MB [requerido para .NET] es un problema INEXISTENTE" y no menciona lo obvio: si estás escribiendo código para la ROM de 32 KB de un localizador ¡entonces es un problema!
Creo que aquí hay cinco mundos, que algunas veces se interseccionan, a menudo no. Los cinco son:
- Paquetes
- Interno
- Embebido
- Juegos
- Desechable
Cuando lees el último libro sobre Programación Extrema, o alguno de los excelentes libros de Steve McConnel, o Joel on Software, o la revista Software Development, puedes ver una cantidad de afirmaciones sobre cómo desarrollar software, pero difícilmente ves alguna mención sobre qué tipo de desarrollo están hablando, lo que es poco afortunado, porque algunas veces se necesita hacer las cosas de distinta manera en los distintos mundos.
Repasemos las categorías brevemente
El Paquete es software que necesita ser utilizado "en la intemperie" por un gran número de personas. Este software puede estar empaquetado en celofán y vendido en CompUSA, o puede ser descargado de Internet. Puede ser comercial, o "shareware" o código abierto GNU o lo que sea -- el asunto principal aquí es software que será instalado y utilizado por miles o millones de personas.
Los paquetes tienen problemas especiales que derivan de dos propiedades especiales:
- Como tienen tantos usuarios quienes a menudo tienen otras alternativas, la interfaz de usuario necesita ser más sencilla de lo normal para tener éxito.
- Como corren en tantos ordenadores, el código debe ser inusualmente resistente a variaciones entre ordenadores. La semana pasada alguien me envió un mail sobre un bug en CityDesk que sólo aparece en Windows en Polaco, por la forma en que ese sistema operativo usa la tecla "Alt" derecha para introducir caracteres especiales. Probamos Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, Win 2000 y Win XP. Probamos con IE 5.01, 5.5, o 6.0 instalados. Probamos Inglés, Español, Francés, Hebreo, y Windows en Chino. Pero no habíamos probado todavía Polaco.
Hay tres grandes variaciones del paquete. El Código Abierto comúnmente se desarrolla sin que se le pague a nadie para hacerlo, lo cual cambia bastante la dinámica. Por ejemplo, las cosas que no son consideradas "divertidas" no son realizadas en un equipo de puros voluntarios, y, como Matthew Thomas precisa elocuentemente, esto puede dañar la usabilidad. Es mucho más probable que el desarrollo esté disperso geográficamente, lo que resulta en una calidad radicalmente diferente en la comunicación del equipo. Es raro en el mundo del código abierto que haya una conversación cara a cara alrededor de un pizarrón dibujando cajas y flechas, de manera que el tipo de decisiones de diseño que se benefician de dibujar cajas y flechas son por lo general pobremente consideradas. Como resultado, los equipos geográficamente dispersos han tenido mucho más exito clonando software existente donde se requiere poco o nada de diseño.
"Software de consultoría" - N. del T.: consultingware en el original - es una variante del paquete que requiere tanta personalización e instalación que se necesita un ejército de consultores para instalarlo, con un costo indignante. Los paquetes de CRM y CMS generalmente caen en esta categoría. Uno adquiere la sensación de que en realidad no hacen nada, sólo son una excusa para obtener un ejército de consultores en tu puerta facturando a US$300 la hora. A pesar de que el software de consultoría es disfrazado como paquete, el alto costo de su implementación significa que es en realidad más como el software interno.
El Software comercial basado en web como por ejemplo el de Salesforce e incluso variedades más tropicales como eBay también necesitan ser sencillos de usar y correr en varios navegadores. A pesar de que los desarrolladores tienen el lujo de (por lo menos) controlar el entorno de instalación -- las máquinas en el centro de cómputo --, tienen que lidiar con un amplia gama de navegadores de internet y un gran número de usuarios de manera que considero que es básicamente una variación del paquete.
El Software Interno sólo necesita funcionar en una situación en las máquinas de una compañía. Esto lo hace mucho más sencillo de desarrollar. Se pueden asumir un montón de cosas sobre el entorno bajo el que va a correr. Puede requerirse una versión particular del Internet Explorer, o Microsoft Office, o Windows. Si necesitas un gráfico, deja que Excel lo construya por ti; todos en el área tienen Excel (pero intenta esto con un paquete y eliminas a la mitad de tus clientes potenciales).
Aquí la usabilidad es una prioridad más baja, debido al número limitado de personas que necesitan utilizar el software, y que no tienen otra alternativa, y que simplemente tienen que lidiar con ello. La velocidad de desarrollo es más importante. Debido a que el esfuerzo de desarrollo se asume por sólo una compañía, la cantidad de recursos de desarrollo que pueden ser justificados es significantemente menor. Microsoft puede permitirse gastar US$500,000,000 desarrollando un sistema operativo que cuesta sólo US$80 para la persona común. Pero cuando la compañía Edison de Detroit desarrolla una plataforma para negociación de productos derivados de la energía, ese desarrollo debe tener sentido para una compañía individual. Para obtener un ROI (Retorno de la Inversión) razonable no se puede gastar tanto como se haría en los paquetes. De modo que desgraciadamente una buena cantidad de software interno es bastante malo.
El Software Embebido tiene la singular propiedad de
que va dentro de una pieza de hardware y casi en ningún caso puede ser
actualizado. Este es un mundo completamente diferente. Los
requerimientos de calidad son mucho más severos, porque no hay segundas
oportunidades. Puede que estés lidiando con un procesador que corre
dramáticamente más lento que el procesador típico de escritorio, de
manera que puedes ocupar mucho tiempo optimizando. El código rápido es
mucho más importante que el código elegante. Los dispositivos de
entrada y salida disponibles pueden ser limitados en número.
El
sistema GPS (Sistema de Posicionamiento Global) que tenía el coche que
alquilé la semana pasada tenía un sistema de entrada/salida tan
patético que la usabilidad era deprimente. ¿Alguna vez has tratado de
introducir una dirección en una de estas cosas? Se desplegaba un
"teclado" en la pantalla y tenías que usar las flechas de dirección
para escoger letras entre cinco pequeñas matrices de 9 letras cada una.
(Sigue el enlace para ver más ilustraciones de esta interfaz. El GPS en
mi auto tiene una pantalla táctil que hace que la interfaz sea
dramáticamente mejor. Pero estoy divagando).
Los Juegos son únicos por dos razones. Primera, la economía del desarrollo de juegos está orientada al éxito. Algunos juegos tienen éxito, muchos más juegos son fracasos, y si quieres hacer algo de dinero con software de juegos debes reconocer esto y asegurarte de tener un portafolio de juegos de forma que el éxito demoledor compense por las pérdidas en los fracasos. Esto es más parecido al cine que al software.
La principal característica en el desarrollo de juegos es que sólo hay una versión. Una vez que tus usuarios han jugado Duke Nukem 3D, no van a actualizar a Duke Nukem 3.1D sólo para obtener algunos errores corregidos y armas nuevas. Con algunas excepciones, una vez que alguien ha jugado el juego hasta el final, es aburrido jugarlo otra vez. De manera que los juegos tienen los mismos requerimientos que el software embebido y una imperativa financiera increíble de hacerlo correctamente la primera vez. Los desarrolladores de paquetes tienen el lujo de saber que si la versión 1.0 no satisface las necesidades de la gente y no se vende, quizás la versión 2.0 sí lo haga.
Finalmente, el código Desechable es el que se crea temporalmente con el único propósito de obtener algo más, y que puede que nunca se necesite utilizar de nuevo para obtener ese algo. Por ejemplo, puede ser que escribas un pequeño shell script que trate un archivo de entrada para convertirlo al formato en el que lo necesitas para algún otro propósito, y esta es una operación de una sola vez.
Probablemente hay otros tipos de desarrollo de software que estoy olvidando.
He aquí una cuestión que es importante saber. Cuando leas uno de esos libros sobre metodologías de programación escrito por un gurú/consultor de desarrollo de software de tiempo completo, puedes estar seguro de que están hablando sobre el desarrollo interno, corporativo de software. Ni de paquetes, ni embebido, y ciertamente tampoco de juegos. ¿Por qué? Porque las corporaciones son la gente que contrata a estos gurús. Están pagando la cuenta (Confía en mí, ID Software no está por contratar a Ed Yourdon para hablar acerca de análisis estructurado).
La semana pasada Kent Beck declaró que uno realmente no necesita bases de datos de seguimiento de errores cuando se utiliza Programación Extrema, porque la combinación de programación por pares (con revisión persistente de código) y desarrollo basado en pruebas (garantizando la cobertura del 100% del código por las pruebas) significa que casi nunca ocurrirán errores. No me pareció una afirmación adecuada. Me fijé en nuestra propia base de datos de seguimiento de errores aquí en Fog Creek para ver qué clase de errores nos mantenían ocupados.
Quién lo creería, descubrí que muy pocos de los errores ahí habrían sido descubiertos con programación por pares o desarrollo basado en pruebas. Muchos de nuestros "errores" son en realidad lo que XP (Programación eXtrema) llama historias -- básicamente, requerimientos de características. Nosotros utilizamos nuestro sistema de seguimiento de errores como un método para recordar, priorizar, y administrar todas las pequeñas mejoras y grandes características que queremos implementar.
Muchos otros de los errores fueron descubiertos sólo después de un uso intensivo del programa. La cosa con el teclado en Polaco. No hay forma en la que la programación en pares pueda descubrir eso. Y errores de lógica que nunca se nos ocurrieron por la forma en la que los distintos módulos trabajan en conjunto. Mientras más grande y complejo sea un programa, hay más interacciones entre sus módulos sobre las que no has pensado. Una particular e improbable secuencia de caracteres ({${?, si debes saberlo) que confunde al analizador léxico. Algunos servidores de ftp producen un error cuando se borra un archivo que no existe (nuestro servidor de ftp no se queja de modo que esto nunca nos ocurrió a nosotros).
Estudié cada error cuidadosamente. De 106 que corregimos para el "paquete de servicio" (service pack) de CityDesk, exactamente 5 de ellos podrían haber sido prevenidos a través de la programación por pares o el diseño basado en pruebas. De hecho teníamos más errores que conocíamos y pensábamos que no eran importantes (¡sólo para posteriormente ser corregidos por nuestros clientes!) que errores que podrían haber sido detectados por métodos de la XP
Pero Kent tiene razón, para otros tipos de desarrollo. Para la mayoría de las aplicaciones desarrolladas en empresas, ninguna de estas cosas habría sido considerada un error. ¿El programa se cae con una entrada inválida? Ejecútalo de nuevo, y esta vez ¡vigila tus {${?'s! Y sólo tenemos Un Tipo de servidor de FTP y nadie en toda la compañía usa Windows en Polaco.
La mayoría de las situaciones en el desarrollo de software son iguales sin importar en qué tipo de proyecto estés, pero no todas. Cuando alguien te hable sobre metodología, piensa en cómo aplica al trabajo que tú estás realizando. Piensa sobre la persona de la que viene. Steve McConnell, Steve Maguire y yo venimos de una esquina muy estrecha: el mundo de las hojas de cálculo de paquetes para un mercado masivo hechas en Redmond, Washington. Como tales, tenemos barras más altas en la facilidad de uso y barras más pequeñas para los errores. La mayoría de los otros gurús se ganan la vida dando consultoría para desarrollo corporativo interno, y eso es de lo que están hablando. En cualquier caso, todos deberíamos poder aprender algo de cada uno.
PD. Existe un gran área gris entre los paquetes, el software de consultoría y el desarrollo interno - los tres mundos son a menudo un continuo. A veces el producto se inicia como producto interno, en eso la gente del negocio tiene la brillante idea de venderlo a otras compañías, pero es tan frágil y asume tantas cosas sobre el entorno que toma semanas instalarlo en los sitios de otros clientes, y es la manera en la que nace el software de consultoría (por ejemplo, Vignette StoryServer que inició como el sistema interno de administración de contenido de c|net y ahora cuesta millones para echar a andar). Teóricamente el software debería entonces migrar hacia paquete a medida que la base de clientes crece, pero estas compañías crean tal adicción a sus ganancias de consultoría que no ven ningún beneficio en hacerlo más sencillo de usar recién desempaquetado. Y muchos desarrolladores internos no tienen experiencia en hacer que el software corra "en la intemperie", de modo que no lo hace.
Esté articulo apareció originalmente en Inglés con el nombre Five Worlds
Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.