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.

Y si llegaste hasta acá: te cuento que llegue a leer esta publicación de Joel, después haber visto el banner de Inti sobre un nuevo Curso de Software Embebido.

Adaptado de Five Worlds, de Joel Spolsky.