¿Aburrido?

Hace ya un tiempo que tengo agendada para comentar esta entrada de The Daily WTF. El artículo clasifica los proyectos de software según el interés que pueden representar para los programadores.

Así, el software “aburrido” tiene nombre y apellido:

[…] information systems. And while the purpose of an information system changes from company to company, as do the specific requirements, they all are essentially the same. There’s a database that models the real world, rules to define how the data may be changed, an interface to the database, and lots of different reports.

…que es casi todo software que soporte algún tipo de negocio, en contraposición con el software “divertido” que representa

[…] the type of things that we use on a regular, day-to-day basis: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, as software developers, we rarely have to use boring software ourselves.

En realidad se refiere a este último tipo de software como “sexy”, lo que me lleva a poco serias reflexiones sobre las inclinaciones del autor del artículo.

Pero más allá de eso descubro, no sin cierta sorpresa, que he dedicado mi vida a proyectos “aburridos”… es más, les he dedicado años de estudios universitarios (soy Licenciado en Sistemas de Información de las Organizaciones, que bajo este punto de vista es casi lo mismo que Licenciado en Sistemas Aburridos)… este blog, habrán notado, está también dedicado a ellos en gran medida.

El artículo me ha dejado pensando. He llegado a la conclusión de que… es verdad. Ese software es aburrido. Es innegable, un hecho de la vida.

Es aburrido para los usuarios, no cabe duda: no me imagino al cajero de una de las salas de juego que utilice el sistema de gestión de la empresa para la que trabajo saltando de alegría cuando el sistema le indique que “ha completado la venta del ticket” o algo por el estilo. Tal vez sí me imagino al gerente festejando luego de consultar un reporte de beneficio, pero no creo que se deba al hecho de utilizar el sistema.

Y puede ser aburrido para los programadores, dependiendo de lo que a éstos les interese.

Si sólo te parece divertido pasarte una semana testeando diferentes tipos de algoritmos de ordenamiento para bajar el tiempo de respuesta de un servicio en 100 o 200 milisegundos… sí, probablemente este tipo de software te parezca aburrido.

Si sólo te motiva quemarte las pestañas estudiando complejas fórmulas matemáticas para lograr que esa estúpida computadora diferencie un auto de una vaca… si, un arqueo de caja es aburrido.

Si únicamente saltas de alegría cuando ese driver que estás desarrollando para que otra impresora funcione en otro sistema operativo logra imprimir un “hola mundo”… y, probablemente que el sistema arroje un error comprensible para el usuario no te parecerá un gran logro.

Esas pueden ser las motivaciones de muchos. Están muy bien, ya que gracias a ese tipo de programadores tenemos sistemas de archivos resistentes a fallos, bases de datos cada vez más rápidas, lenguajes de cada vez más alto nivel, una miríada de sistemas operativos para cada necesidad, librerías de reconocimiento de imágenes y un montón de innovaciones espectaculares para revolucionar negocios y organizaciones (no saben cuánto puede agradecer alguien como yo el “simple” Plug & Play y los drivers transparentes).

Pero las mías (y creo que por suerte las de mis compañeros de equipo también, y las de muchos otros) son otras: quiero hacer software útil para una organización.

Ese objetivo puede implicar optimizaciones, reconocimiento de imágenes, interacción con otros dispositivos (de hecho hemos tenido que hacer o utilizar algo de todo eso eventualmente) y otras cosas “divertidas” (que les aseguro que finalmente no lo son tanto), pero lo que me ha llevado a enfrentar esos problemas ha sido siempre la satisfacción de cumplir un requerimiento de la organización, y sólo en menor medida la satisfacción de resolver un problema difícil con un algoritmo ingenioso.

La gracia del desarrollo de estos sistemas no está tanto en la codificación, que efectivamente es 90% rutinaria (consulta a base de datos, operaciones simples sobre colecciones, algunos cálculos, ingreso de datos del usuario, validaciones, grabar en la base de datos y listo).

La gracia está

• en los problemas que representa un entorno de desarrollo cambiante y muchas veces caótico, con clientes que desesperan, analistas que deliran, jefes de proyecto que dicen sí a todo y programadores que cometen (cometemos) más errores de comprensión del negocio que de codificación (a no enojarse por las referencias, ya ven que hay palos para todos);

• en la necesidad de armar y mantener una estructura que soporte esas constantes modificaciones y que al mismo tiempo sea simple y fácil de usar;

• en hacer que esa codificación rutinaria sea lo más rápida y limpia posible (o incluso automática), para tener más tiempo para lo que es realmente importante: diseñar, mejorar, innovar, simplificar;

• en la coordinación e interacción con otros compañeros de equipo u otros equipos que desarrollan otros módulos del sistema;

• en la comprensión del flujo de la información de un negocio en particular y en descubrir cómo el software puede optimizarlo, ayudando a las personas a preocuparse menos por tareas rutinarias (para eso está el sistema) y más por lo que sólo ellas pueden aportar mediante su esfuerzo.

Por supuesto, estos componentes están presentes en todos los sistemas (en los “divertidos” y en los “aburridos”), sólo que en unos tiene mayor importancia que en otros.

Más que buscar o crear chiches nuevos para integrar a nuestro proyecto,  partimos de los requerimientos y buscamos aquello que represente la mejor manera de satisfacerlos.

Así, si he aprendido a programar en entornos web ha sido porque un negocio lo requería. Si adopté MVC no fue por probar el nuevo framework de Microsoft sino porque tenía un enredo entre datos, negocio y presentación que necesitaba ordenar. Si experimenté con AOP fue porque encontraba requerimientos transversales, y así…

Creo, entonces, que no hay sistemas aburridos y divertidos. El mundo del desarrollo es enorme, así que está en cada uno encontrar el lugar en el que los requerimientos encajen en las propias motivaciones.

Así que si estás aburrido… ¡muévete!