Ingeniería de software vs. ingenierías clásicas: similitudes, diferencias y desafíos

A finales de año pasado me incorporé a IED como ingeniero de software, un rol claramente en minoría dentro de la empresa. Mi contratación ya demuestra un interés por el mundo digital, pero desde entonces solo he visto reforzada esa apuesta, especialmente desde el inicio de nuestra colaboración con 540. IED busca seriamente reforzar su oferta de software como un soporte para aumentar su producto electrónico.

Esto es un movimiento natural, un buen ecosistema de software puede hacer una oferta electrónica más atractiva y ayudar a sacar más rendimiento al producto vendido. Sin embargo, aun siendo natural, está transición puede ser ardua. Abordar proyectos de software no es lo mismo que para otros tipos de ingenierías más “tradicionales”, esto quedó en evidencia desde el principio mismo de la disciplina, cuando muchos ingenieros empezaron a abordar el software usando las metodologías que habían usado tradicionalmente, resultando en mucho sufrimiento y rechinar de dientes. Como resultado de estas experiencias, durante los 2000 surgieron una plétora de nuevos frameworks para organizar el código y a los equipos que lo desarrollan (hexagonal architecture, extreme programming, agile, etc.), Waterfall se convirtió en tabú y se extendió una sensación general de que el software era “algo distinto”. Lo que nos lleva a la pregunta. ¿Qué hace al software tan complicado? ¿Es siquiera complicado o tan solo distinto?

Distintos

Primero de todo, el desarrollo de software no es tan complicado, al menos no más que cualquier otro tipo de ingeniería, es simplemente, distinto. Está diferencia surge de sus limitaciones, o más concretamente de la ausencia de estas. El software es tremendamente flexible, maleable y portable. Imaginemos un plano para un nuevo componente electrónico o dispositivo, para poder probarlo será necesario fabricarlo: contactar con un fabricante, pasarle las especificaciones, esperar a que tenga el prototipo listo etc, esto puede llegar a requerir semanas y un coste monetario. En el mundo del software, en cuestión de segundos se puede tener un prototipo listo y funcionando. En el mundo del software una actualización que arregle un problema critico puede ser entregada a miles de clientes por todo el mundo en cuestión de minutos a un coste ínfimo. Por el contrario, por poner un ejemplo, para un modelo de coche con un fallo de diseño crítico, la consecuente llamada a revisión a los vehículos ya en circulación puede requerir meses y causar perdidas catastróficas para el desafortunado fabricante. Está flexibilidad tiene consecuencias inmensurables a nivel tanto de desarrollo como de negocio.

Consecuencias en desarrollo

En ocasiones más flexibilidad implica más posibilidades para equivocarnos y más libertad para hacer las cosas mal. Cuando todo problema tiene un parche y cualquier solución puede ser mejorada más tarde, la tentación de tomar la vía rápida puede ser irresistible. Un apaño puede ser un pequeño inconveniente para desarrollos futuros, pero cuando una aplicación se convierte en una amalgama de remiendos mal avenidos, cualquier pequeña modificación se vuelve una tarea titánica. Bajo estas condiciones la implementación de nuevas funcionalidades se detiene hasta un goteo. La única solución llegados a este punto es dedicar una gran cantidad de recursos a arreglar chapuzas, a costa de los nuevos desarrollos, lo cual es muy difícil de justificar a nivel de negocio.

Y lo que hace este problema más insidioso todavía, es que en ocasiones tomar la vía rápida es absolutamente imprescindible. Para un nuevo producto, la prioridad siempre debe ser obtener una versión lo suficientemente avanzada como para ser comercializada, sin una visión concreta del producto o su viabilidad, la velocidad y flexibilidad es fundamental y prima sobre la sostenibilidad, de nada sirve tener la aplicación más robusta y escalable posible, si tiene que ser abandonada porqué nadie la usa. Es conformé el producto madura que se deber reconocer cuando pivotar a un enfoque más centrado en la robustez del producto. Porque el software siempre es una carrera de fondo, en el ecosistema actual las actualizaciones constantes no son un lujo, son una necesidad.