Programadores de computadores

2005-09-14T14:02:00.000-07:00

Cinco Mundos
Por Joel Spolsky

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:
1. Paquetes
2. Interno
3. Embebido
4. Juegos
5. 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 cnet 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.

2005-09-13T08:47:00.000-07:00

Alcanzando las notas altas

Por Joel Spolsky

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. Algun
os 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!

[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.

APRENDA A PROGRAMAR EN DIEZ AÑOS

2005-09-12T12:57:00.000-07:00

¿Por qué todos tienen tanto afán?

Entra a cualquier librería y encontrarás Aprende Java en 7 Días y demás variaciones interminables ofreciendo enseñar Visual Basic, Windows, Internet, etc., en unos pocos días u horas. Yo hice la siguiente búsqueda avanzada (power search) en Amazon.com :

pubdate: after 1992 and title: days and (title: learn or title: teach yourself)

y obtuve 248 ítems de resultado. Los primeros 78 fueron libros de computación (el número 79 era Aprende Bengali en 30 días -- Learn Bengali in 30 days ). Remplacé "days" (días) por "hours" (horas) y obtuve, sorprendentemente, resultados similares: 253 libros más, con 77 libros de computación seguidos de Aprende Gramática y Estilo en 24 horas (Teach Yourself Grammar and Style in 24 Hours) en el número 78. Del total de los primeros 200, 96% fueron libros de computación.

La conclusión es que, o bien la gente tiene un gran afán por saber de computadoras, o bien las computadoras son algo fabulosamente más fácil de aprender que cualquiera otra cosa. No hay libros sobre cómo aprender Beethoven, o Física Cuántica, o incluso Estética Perruna en pocos días.
Analicemos lo que podría significar un título como Aprende Pascal en Tres Días (Learn Pascal in Three Days):

Aprende: En 3 días no tendrás tiempo de escribir varios programas significativos, y de aprender de tus éxitos y errores con ellos. No tendrás tiempo de trabajar con un programador experimentado y entender lo que es vivir en ese ambiente. En resumen, no tendrás tiempo de aprender mucho. Así que esos libros sólo podrán lograr una familiaridad superficial, no un entendimiento profundo. Como dijo Alexander Pope, poco aprendizaje es asunto peligroso.
Pascal: En 3 días puedes aprender la sintaxis de Pascal (si ya conoces un lenguaje similar), pero no podrás aprender mucho cómo usarla. En síntesis, si fueras, digamos, un programador Basic, podrías aprender a escribir programas en el estilo de Basic usando la sintaxis de Pascal, pero no aprenderías realmente para lo que Pascal es bueno (o malo). Entonces ¿cuál es el objetivo?

Alan Perlis dijo alguna vez: "Un lenguaje que no afecte tu manera de pensar acerca de la programación, no merece conocerse". Un objetivo posible es que tienes que aprender un poco de Pascal (o más probablemente, algo como Visual Basic o JavaScript) porque necesitas tener una interface con una herramienta existente para realizar una cierta tarea. Pero entonces no estás aprendiendo cómo programar; estás aprendiendo cómo realizar esa tarea.

en Tres Días: Desafortunadamente, no son suficientes, como se describe en la siguiente sección.

Aprende a programar en diez años

Algunos investigadores (Hayes , Bloom) han mostrado que toma aproximadamente diez años desarrollar habilidades en cualquiera de una amplia variedad de áreas, incluyendo el juego de ajedrez, la composición musical, la pintura, el piano, la natación, el tenis, y la investigación en neurosicología y topología. Parece no haber atajos: incluso Mozart, prodigio musical a los 4 años, se tomó 13 más antes de empezar a producir música de calidad mundial. En otro género, parece que los Beatles llegan a escena apareciendo en el espectáculo de Ed Sullivan en 1964. Pero ellos habían estado tocando desde 1957, y aunque tenían una masa de seguidores desde antes, su primer gran éxito, Sgt. Peppers , apareció en 1967. Samuel Johnson pensaba que se requieren más de diez años: "La excelencia en cualquier área puede lograrse sólo mediante el trabajo de toda una vida; no es algo que pueda adquirirse a un menor precio." Y Chaucer se quejaba "the lyf so short, the craft so long to lerne."
Aquí está mi receta para el éxito en programación:

Interésate en la programación, y haz programación porque es divertida. Asegúrate que se mantiene tan divertida que estarás en disposición de invertir diez años.
Habla con otros programadores. Lee otros programas. Esto es más importante que cualquier libro o curso.
Programa. El mejor tipo de aprendizaje es aprender haciendo (

learning by doing) . Para decirlo más técnicamente, "El máximo nivel de desempeño de los individuos en un dominio dado, no se logra automáticamente como función de experiencia extendida, sino que el nivel de desempeño puede incrementarse incluso en individuos altamente experimentados como resultado de esfuerzos deliberados por mejorar." (p. 366) y "el aprendizaje más efectivo requiere una tarea bien definida con un apropiado nivel de dificultad acorde con el individuo, retroalimentación informativa, y oportunidades de repetición y corrección de errores." (p. 20-21) El libro Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life es una interesante referencia sobre este punto de vista.

Si quieres, dedica cuatro o cinco años en una universidad (o más en una escuela de graduados). Esto te dará acceso a algunos posiciones que requieren credenciales, y te dará un entendimiento más profundo del campo, pero si no disfrutas la escuela, puedes (con algo de dedicación) obtener una experiencia similar trabajando. Como sea, la lectura de libros por sí sola no será suficiente. "La educación en computación no puede hacer a nadie un expero programador más que el estudio de pinceles y pigmentos puede hacer a alguien un pintor experto" dice Eric Raymond, autor de The New Hacker's Dictionary. Unos de los mejores programadores que yo haya contratado alguna vez tenía sólamente un grado de bachiller (High School); pero ha producido una gran cantidad de excelentes programas , tiene su propio grupo de noticias (news group) , y sin duda es mucho más rico de lo que yo llegue a ser.

Trabaja en proyectos con otros programadores. Sé el mejor programador en algunos proyectos; sé el peor en otros. Cuando eres el mejor, tienes que poner a prueba tus habilidades para liderar un proyecto y para inspirar a otros con tu visión. Cuando eres el peor, aprendes lo que los maestros hacen, y aprendes lo que a ellos no les gusta hacer (pues te ponen a hacerlo por ellos).

Trabaja en proyectos después que otros programadores. Proponte entender un programa escrito por otra persona. Mira cuánto toma entenderlo y hazle correcciones cuando los programadores originales no están allí. Piensa en cómo diseñar tus programas para facilitarles el trabajo a aquellos que le harán mantenimiento después de tí.

Aprende por lo menos una media docena de lenguajes de programación. Incluye uno con soporte para abstracciones de clases (como Java o C++), uno que dé soporte a la abstracción functional (como Lisp o ML), uno que dé soporte a la abstracción sintáctica (como Lisp), uno que dé soporte a especificationes declarativas (como Prolog o plantillas C++), uno que dé soporte a corutinas (como Icon o Scheme), y uno que dé soporte al paralelismo (como Sisal).

Recuerda que hay "computadoras" en la "ciencia de la computación". Conoce cuánto le toma a tu computadora ejecutar una instrucción, alcanzar una palabra de la memoria (con y sin cache), leer palabras consecutivas de disco, y ubicar una nueva localización en disco. (Respuestas aquí.)

Involúcrate en un plan de estandarización de algún lenguaje. Podría ser en el mismo comité ANSI C++, o podría ser simplemente decidir si tu estilo de codificación tendrá niveles de identación de 2 ó 4 espacios. Como sea, averigua lo que les gusta a otras personas en un lenguaje, cómo lo perciben, y quizá incluso un poco de por qué lo perciben como lo hacen.

Ten el buen juicio para lanzar el plan de estandarización del lenguaje tan pronto como sea posible.

Con todo lo anterior en mente, es cuestionable qué tan lejos puedes llegar sólo leyendo libros. Antes de que naciera mi primer hijo, leí todos los libros Aprende a (How To), y sin embargo me sentía como un tonto principiante. 30 meses después, cuando nació mi segundo hijo, ¿acaso regresé a los libros? No. Al contrario, me apoyé en mi experiencia personal, que me resultó mucho más útil y confiable que las miles de páginas escritas por los expertos.

Fred Brooks, en su ensayo No Silver Bullets, identificó un plan de tres partes para encontrar grandes diseñadores de programas:

Sistemáticamente identificar a los diseñadores líderes lo más pronto posible.
Asignar un tutor de carrera para que sea responsable del desarrollo del prospecto y mantenga cuidadosamente un registro de seguimiento.
Ofrecer oportunidades a los diseñadores en crecimiento para que interactúen y se motiven mutuamente.

Esto asume que algunas personas ya tienen las cualidades necesarias para ser grandes diseñadores; la tarea es persuadirlos apropiadamente. Alan Perlis lo dice de manera más sucinta: "A cualquiera se le puede enseñar a esculpir: A Miguel Angel habría que habérsele enseñado cómo no hacerlo. Así pasa con los grandes programadores".
Así que adelante, compra ese libro de Java; probablemente obtendrás algo de él. Pero no cambiará tu vida o tus reales habilidades como programador en 24 horas, días o incluso meses.
Referencias

La facilidad de uso en el diseño de software

2005-08-31T12:24:00.000-07:00

Introducción
Puesta en práctica de la facilidad de uso
El término “facilidad de uso” representa un enfoque que sitúa al usuario, no al sistema, en el centro del proceso de creación de software. Esta filosofía, denominada diseño centrado en el usuario, incorpora los intereses y la defensa del usuario desde los inicios del proceso de diseño y otorga prioridad absoluta a sus necesidades a la hora de tomar cualquier decisión.
El aspecto más visible de este enfoque son las pruebas de facilidad de uso, en las que los usuarios trabajan e interaccionan con la interfaz del producto y comparten sus opiniones e inquietudes con los diseñadores y desarrolladores.
En este artículo se describe el concepto de facilidad de uso y las razones por las que dicho concepto debe constituir una parte importante dentro de los proyectos de diseño de software. En la primera parte se define el concepto de facilidad de uso en el contexto del desarrollo de software y su relación con otros métodos de determinación de la calidad de los productos. A continuación, se ofrecen las respuestas a las preguntas más frecuentes acerca de la importancia de la facilidad de uso y la incorporación de los principios del diseño centrado en el usuario en el proceso de desarrollo. Asimismo, en el artículo se incluyen referencias a libros, artículos y organizaciones que facilitarán la comprensión del concepto de facilidad de uso así como su puesta en práctica en los proyectos.
La mayor parte de los principios que se incluyen en este artículo son válidos tanto para el desarrollo de software comercial como interno. Durante la lectura del artículo, se debe prestar especial atención a términos como “usuario” y “producto” y determinar hasta qué punto están presentes en nuestros proyectos y en el usuario final.

Definición del concepto de facilidad de uso
El término "facilidad de uso" hace referencia a la facilidad que ofrece un producto para realizar determinadas tareas. Este término, aunque guarda cierta relación con los conceptos de utilidad y satisfacción, es, en realidad, un concepto diferente.

Facilidad de uso frente a Utilidad
Uno de los aspectos centrales que determinan la aceptación de un producto es su funcionalidad. Si un producto es funcional, permitirá alcanzar los objetivos para los que se diseñó. Este concepto engloba, a su vez, los conceptos de utilidad y facilidad de uso que, aunque guardan cierta relación, no se deben utilizar indistintamente.
El concepto de utilidad hace referencia a la capacidad de un producto para realizar una o varias tareas. Cuantas más tareas pueda realizar un producto, mayor será su utilidad.
Recordemos los procesadores de texto Microsoft® MS-DOS® típicos de finales de los años 80. Aunque estos programas generaban una gran variedad de características eficaces de manipulación y edición de texto, exigían el aprendizaje y memorización, por parte del usuario, de innumerables pulsaciones crípticas. Éstas constituyen un ejemplo típico de aplicación de gran utilidad (ofrece al usuario la funcionalidad necesaria) pero que gozan de una pobre facilidad de uso (el usuario debe dedicar mucho tiempo y esfuerzo a su aprendizaje y uso). Por el contrario, una aplicación de diseño tan simple como una calculadora, aunque muy fácil de utilizar, resulta de escasa utilidad.
Tanto la utilidad como la facilidad de uso son necesarias para lograr la aceptación del producto en el mercado y ambas forman parte del concepto de funcionalidad. Obviamente, si un programa dispone de una gran facilidad de uso pero carece de calidad, no existirá ninguna razón por la que se deba utilizar. Asimismo, si al usuario se le ofrece un programa eficaz pero difícil de utilizar, éste se sentirá reacio a utilizarlo y buscará otras alternativas.
Las pruebas de facilidad de uso ayudan a determinar la facilidad que ofrece un producto para realizar determinadas tareas. No obstante, dichas pruebas no permiten determinar la calidad ni la utilidad del producto. (Durante las pruebas de facilidad de uso, el usuario puede aportar ideas en relación a la utilidad del producto. No obstante, es necesario comprobar cualquier sugerencia utilizando métodos de investigación más exhaustivos.)

Satisfacción frente a uso
Está claro que el diseñador siempre pretende conseguir la satisfacción del usuario. Si al usuario le gusta el producto, probablemente lo utilizará y lo recomendará a otros. No obstante, del mismo modo que ocurre con la utilidad, no debemos confundir satisfacción con facilidad de uso.
A menudo, el usuario se siente atraído hacia un producto por razones ajenas a la utilidad o facilidad de uso. Tal vez le atraiga el estilo o la presentación, o quizás, el estatus que cree adquirir al comprarlo. Aunque el usuario tiende a sentirse atraído por productos con gran facilidad de uso, no debería creer que ésta se encuentra siempre tras un buen estilo y presentación.
La facilidad de uso hace referencia a la suficiencia de un producto para realizar las tareas que el usuario necesita. Las pruebas de facilidad de uso determinan el rendimiento de un producto, no la preferencia del usuario. Para ello, se pueden utilizar cuestionarios estándar que determinen las preferencias de los usuarios con respecto a los productos.

Descubrimiento frente a aprendizaje y rendimiento
Existen varios aspectos que intervienen en la facilidad de uso de un producto, pero este término hace referencia esencialmente a los atributos de descubrimiento, aprendizaje y rendimiento.
El término descubrimiento implica la búsqueda y el hallazgo de la característica de un producto en respuesta a una necesidad determinada. Las pruebas de facilidad de uso determinan el tiempo que invierte el usuario en localizar una característica determinada del producto y los errores cometidos por éste (selecciones de ubicación erróneas) en el proceso.
El término aprendizaje hace referencia al proceso que utiliza el usuario para determinar el funcionamiento adecuado de una característica descubierta para realizar una tarea determinada. Las pruebas de facilidad de uso determinan el tiempo invertido en dicho proceso y los errores cometidos por el usuario durante el mismo.
El término rendimiento hace referencia al punto en el que el usuario “domina” la característica y la utiliza sin necesidad de más aprendizaje. Las pruebas de facilidad de uso determinan el tiempo invertido por un usuario experimentado en ejecutar los pasos necesarios para utilizar una característica concreta.
Estos tres aspectos del concepto de facilidad de uso se ven influenciados, en gran medida, por la naturaleza de la tarea que se desea realizar y por la frecuencia con la que el usuario la lleva a cabo. El uso de determinadas características es tan escaso que el usuario las aprende una y otra vez cada vez que las realiza. Para estos casos, Microsoft desarrolla a menudo asistentes que facilitan el proceso.

Los eslóganes no funcionan
A menudo, los diseñadores creen que utilizar simples eslóganes como “aumente la facilidad de uso de su producto” ayudará a resolver los problemas de facilidad de uso. Aunque es importante mostrar una actitud positiva hacia este concepto, sólo la realización de pruebas con usuarios ordinarios en el contexto específico para el que se creó el producto ofrecerá a los diseñadores la información necesaria para crear un producto que satisfaga las necesidades del usuario. “Aumente la facilidad de uso de su producto” debe ser la máxima de todo diseñador de software, pero sólo tendrá sentido si el diseñador es consciente del significado correcto de “facilidad de uso”. Las pruebas con usuarios ordinarios constituyen la forma más confiable de determinar si se cubren o no sus necesidades.

Preguntas más frecuentes

¿Por qué debería tener en cuenta la facilidad de uso?
Si aún no ha considerado el concepto de facilidad de uso en el proceso de diseño de sus productos, tal vez se pregunte por qué es necesario o recomendable su consideración si, después de todo, es totalmente factible publicar un producto funcional y sin errores sin tener que realizar pruebas de facilidad de uso. La razón es que la incorporación de principios de diseño centrados en el usuario mejora considerablemente muchos de los aspectos de un producto.
La razón principal por la que es necesario realizar pruebas de facilidad de uso es la reducción del número de llamadas a los servicios de soporte. Una facilidad de uso pobre es la causa más común de las llamadas a los servicios de soporte técnico, servicios que, como saben todos los directores ejecutivos y de servicios de información de las empresas, pueden llegar a resultar demasiado costosos. Asimismo, el cobro a los usuarios del soporte recibido aumenta la insatisfacción potencial de éstos con respecto al producto. Por tanto, la facilidad de uso de un producto reducirá considerablemente el número de llamadas realizadas a estos servicios.
En lo que respecta al software creado para uso particular, la segunda razón para incorporar la facilidad de uso como parte importante del proceso de desarrollo es la reducción de los costes de formación. Un producto con una gran facilidad de uso resulta mucho más fácil de aprender para el usuario que otro producto que no haya incluido este aspecto en su lista de prioridades, ya que el usuario es capaz de aprender más rápidamente las características del producto y mantener el conocimiento adquirido durante más tiempo, lo que repercute directamente en la reducción de los costes de formación y en el ahorro de tiempo invertido.
Las pruebas de facilidad de uso permiten lograr una mayor aceptación por parte del usuario. El grado de aceptación de un producto depende de varios factores, entre los que se incluyen la facilidad de uso, la utilidad y la satisfacción. En el caso de los productos comerciales, la aceptación del usuario está directamente relacionada con el aumento de las ventas o con la lealtad, lo que conlleva probablemente la recomendación del producto por parte del usuario. En el caso de las aplicaciones internas, la aceptación hace referencia a la buena disposición del usuario a utilizar el software para realizar las tareas para las que se ha diseñado; una buena disposición por parte del usuario a utilizar el software supone necesariamente el incremento de la productividad. El aumento de la facilidad de uso es uno de los factores que contribuyen a incrementar la aceptación del usuario.
La facilidad de uso será el rasgo distintivo de su producto. Cuando dos productos cuentan con prácticamente el mismo grado de utilidad, aquel que disponga de mayor facilidad de uso contará con una mayor aceptación. Asimismo, la presentación y aspecto de Microsoft® Windows® y las directrices de programación que los acompañan, han establecido una serie de líneas generales para las interfaces de usuario básicas, de modo que los programas que ofrecen funciones similares presentan un aspecto muy parecido y funcionan de forma similar. Estas similitudes implican que las pequeñas diferencias en facilidad de uso pueden repercutir, en gran medida, en la decisión del usuario.
Finalmente, es necesario recordar que todos los productos se someten a pruebas de facilidad de uso tarde o temprano. El usuario, cada vez que utiliza su producto, realiza una prueba de facilidad de uso y dicta su veredicto a través de un uso continuado o un rechazo del producto. La comprobación del producto antes de su lanzamiento al mercado garantiza la aceptación por parte del usuario.

¿Cuáles son los costes que deberé afrontar?
A menudo, tanto los diseñadores de software como los directores de proyectos se muestran reticentes a iniciar procesos de diseño centrados en el usuario, así como a realizar pruebas de facilidad de uso, ya que asumen que resultarán demasiado costosos y se prolongarán en exceso en el tiempo. Pero esto no es así. La realidad es que la inversión en coste y tiempo es, a menudo, relativamente pequeña, sobre todo si se compara con el coste que resultaría de no hacerlo.
Consideremos, por ejemplo, con el producto aún en la mesa de diseño, la inversión en tiempo y coste que supondría la revisión de un diseño en la fase final del ciclo de desarrollo en lugar de hacerla al principio. Si se espera al final del proceso para realizar las pruebas de facilidad de uso en función de la reacción del usuario, posiblemente se tendrán que deshacer partes del programa que tardaron mucho tiempo en desarrollarse. Pero si se espera hasta la publicación del producto y, a continuación, se incorporan los cambios derivados de los comentarios negativos del usuario o en el soporte solicitado, el coste sería considerablemente mayor debido a los altos costes que supone el servicio de soporte o a la escasa aceptación del usuario.
Un estudio de facilidad de uso razonable puede realizarse en aproximadamente dos semanas y puede reducir considerablemente el tiempo y coste invertidos en la realización de cambios al final del ciclo de desarrollo. El coste invertido en la realización de las pruebas dependerá de la naturaleza del producto y de los elementos de la interfaz que se deseen comprobar.
Se puede establecer un paralelismo entre las pruebas de facilidad de uso y la comprobación de código. Un buen director de proyectos siempre tiene en cuenta la comprobación del código del producto al planear un proyecto de desarrollo. No lo ve como algo adicional que haya que agregar al proceso y al presupuesto, sino que lo considera un coste previsto en cualquier relación comercial porque, de no ser así, el coste sería mucho mayor. Pues bien, lo mismo podemos aplicar a la realización de las pruebas de facilidad de uso.

¿Cómo puedo incorporar "algo" de facilidad de uso a mi producto?
Al leer acerca de la facilidad de uso y comprender su importancia, a veces, los desarrolladores pretenden incorporar “algo” de facilidad de uso a sus productos, como si se tratase de un ingrediente que simplemente se agrega a un producto. La facilidad de uso debe ser una parte integrante del proceso de diseño, no una “cosa” que se agrega cuando se desea. La razón por la que los expertos en facilidad de uso utilizan los términos “enfocado al usuario” y “diseño centrado en el usuario” es que dicha capacidad depende del mantenimiento de las necesidades del usuario como un aspecto fundamental en el proceso de diseño. Un diseño centrado en el usuario implica necesariamente más que el mero seguimiento de una serie de reglas referentes a la ubicación de los botones y menús en la interfaz. Las pruebas de facilidad de uso constituyen una oportunidad para comprobar el diseño del producto. No se trata de una forma de “agregar” facilidad de uso al producto.
Gould, Boies y Lewis (1991) identifican cuatro principios en el diseño centrado en el usuario:
Enfoque temprano en el usuario. Los diseñadores deben esforzarse en comprender las necesidades de los usuarios desde la primera fase del proceso de diseño.
Diseño integrado. Los aspectos del diseño guardan una relación paralela más que secuencial. Es fundamental mantener el diseño interno en consonancia con las necesidades de la interfaz de usuario.
Pruebas tempranas y continuas. El único enfoque actual factible en el diseño de software es el empírico: el diseño funciona si el usuario final decide que funcione. La incorporación de pruebas de facilidad de uso en el proceso de desarrollo ofrece al usuario la posibilidad de enviar comentarios sobre el diseño antes del lanzamiento del producto.
Diseño iterativo. Los grandes problemas son, a menudo, un cúmulo de pequeños errores. Los diseñadores y desarrolladores deben revisar el diseño de forma iterativa en tandas de pruebas.

¿Por qué debo implicar al usuario?
Un diseñador debe reconocer que no es un usuario típico ya que posee un conocimiento y comprensión del sistema que está desarrollando mucho más profundo de lo que jamás tendrá el usuario medio. De este modo, determinados aspectos de la interfaz que están poco claros o resultan confusos para la mayor parte de los usuarios pueden resultar evidentes para alguien que ha intervenido en el proyecto. Ciertos desarrolladores de software son capaces de identificarse con el usuario medio hasta cierto punto, pero, para el usuario real, no hay nada mejor que interactuar directamente con el producto.
Por tanto, al centrarse en las necesidades de los usuarios típicos en las primeras fases del proceso de desarrollo y revisar de forma periódica el diseño en función de la reacción del usuario, los desarrolladores de software centrado en el usuario obtienen mejores resultados y, en consecuencia, mejores productos.
Un diseño más sofisticado implica una mayor aceptación por parte del usuario. La ventaja de disponer de un mayor número de compradores externos en el software comercial es obvia: un mayor volumen de ventas. La aceptación del usuario también constituye una parte importante del software desarrollado para uso interno: un mayor número de compradores externos implica una mayor productividad y un menor uso de soporte. Claramente, la implicación del usuario desde el principio del proceso de desarrollo es un indicio del interés del desarrollador por los problemas y necesidades del usuario, lo que aumenta la buena disposición de éste a facilitar al desarrollador la creación de un software de mejor calidad.

¿Existen algunas directrices a las que atenerse?
Microsoft ha desarrollado una serie de directrices de interfaz de la plataforma informática de Windows para garantizar que los programas de Windows disponen de un aspecto y una presentación coherentes. Otras empresas han desarrollado directrices similares para otras plataformas informáticas y expertos en facilidad de uso, como Jakob Nielsen, han escrito innumerables artículos sobre el diseño de páginas Web con gran facilidad de uso. Dada la riqueza documental existente sobre estos temas, a veces, los diseñadores creen que el seguimiento riguroso de las directrices y estándares es todo lo que se precisa para crear productos con una buena facilidad de uso.
El problema de este enfoque es que las directrices son, en sí, intrínsecamente generales. Las directrices deben ser aplicables a una gran variedad de casos, por lo que no siempre constituyen la mejor forma de actuación para la aplicación que nos encontramos diseñando. El seguimiento de una serie de directrices bien definidas facilita el diseño de una interfaz consistente, pero no se podrá determinar si dispone de facilidad de uso hasta que se aplique a usuarios reales. Las directrices no se deben seguir como se haría en un libro de cocina, esperando que se indique la forma de obtener el mejor resultado. Aunque dos diseñadores sigan las mismas directrices de dos formas diferentes, puede que ninguna de las implementaciones sea adecuada para la situación en cuestión. Asimismo, puede que, en determinadas circunstancias, el seguimiento riguroso de directrices lleve a la obtención de malos resultados o a conflictos entre las propias directrices. Sólo un diseño centrado en el usuario facilita la eliminación de dichos conflictos antes de que se conviertan en verdaderos problemas.
También podemos considerar este asunto desde otro punto de vista: dejemos que el diseño centrado en el usuario y no las directrices de las interfaces de usuario sea el árbitro en la toma de decisiones.

¿Es necesario crear un laboratorio de facilidad de uso?
Es importante saber que la realización de pruebas de facilidad de uso no implica la utilización de un laboratorio costoso, con cámaras en el techo, espejos unidireccionales y otra serie de instrumentos de enfoque de grupo. A menudo, las empresas que suelen realizar una gran cantidad de pruebas encuentran conveniente crear laboratorios dedicados exclusivamente a la realización de las mismas, de modo que los especialistas en facilidad de uso disponen de una amplia gama de recursos y equipos que ofrecer a sus clientes. No obstante, se pueden realizar pruebas válidas de facilidad de uso en un gran número de escenarios y circunstancias.
Otra posibilidad consiste simplemente en disponer junto al usuario de un controlador de productos (una persona versada en la realización de estudios antropológicos y recopilación de datos) mientras éste trabaja para observar la realización de tareas. Esto se puede llevar a cabo en una sala de conferencias u oficina. Dumas y Redish (1999) ofrecen una gran cantidad de información sobre la realización de pruebas mediante observación.
A medida que se familiarice con las pruebas de facilidad de uso, podrá ir agregando equipo adicional, como una cámara de vídeo, un espejo unidireccional o herramientas que permitan la visualización y grabación del monitor del usuario en tiempo real. No es necesario agregar todo el equipo al mismo tiempo. Incluso resulta más beneficioso ir agregando el equipo poco a poco.
Asimismo, se puede delegar la realización de las pruebas a los expertos en facilidad de uso. El apartado siguiente “¿Cómo empiezo?” ayudará al desarrollador a encontrar los expertos adecuados.

¿Cómo empezar?
Una vez se haya decidido a incorporar los principios del diseño centrado en el usuario en el proceso de desarrollo, se deberá determinar si se cuenta con los servicios de profesionales en facilidad de uso o si se delegan las pruebas a un proveedor.
La asociación de profesionales de la facilidad de uso (Usability Professionals Association, UPA) dispone de una guía de proveedores que puede ayudar a encontrar a los expertos en facilidad de uso adecuados para realizar las pruebas en un producto.
Asimismo, existen varios grupos de expertos dedicados a la asistencia en la creación de laboratorios de facilidad de uso propios o a desarrollar programas internos de facilidad de uso que permitan incorporar los principios de facilidad de uso al proceso de diseño de productos.
Si se decide disponer de profesionales propios, la asociación de ergonomía y factores humanos (Human Factors and Ergonomics Society) cuenta con un servicio de ubicación que le ayudará a encontrar empleados potenciales. Gran parte de los profesionales en facilidad de uso pertenecen también al grupo de interés especial de ACM sobre la interacción entre las personas y el equipo (ACM Special Interest Group on Computer-Human Interaction, SIGCHI) y a la UPA, en cuyas publicaciones o congresos podrá incorporar sus ofertas de empleo.
Se decida por una u otra opción, recuerde que se estará contratando un servicio de realización de pruebas, no se obtendrán las impresiones del usuario con respecto a su producto. Los profesionales en facilidad de uso, al igual que los diseñadores, no son usuarios típicos.
Consulte el apartado “Recursos,” que aparece a continuación, para obtener más información sobre estas empresas y organizaciones así como sobre la realización de pruebas de facilidad de uso y del diseño centrado en el usuario.