"Como jugadora, lo deseo. Pero como desarrolladora, no me gustaría trabajar en la retrocompatibilidad. Es un trabajo de mantenimiento que te destroza el alma".
– Una desarrolladora de nuestro equipo que permanecerá en el anonimato. Llamémosla Dev-I por ahora.
La semana pasada estuve hablando con desarrolladores internos de Appian sobre la retrocompatibilidad ("BC", por sus siglas en inglés) cuando una de ellas compartió esta cita. Como ávida jugadora y fan de Nintendo, también compartió la imagen de la retrocompatibilidad de Nintendo (gracias al usuario de Reddit u/rushiosan) e insistió con vehemencia en que la utilizara en el blog. Así que aquí tienes, Dev-I.
La posición de Dev-I no es nueva.
Muchos desarrolladores no soportan el trabajo de mantenimiento del software porque realizar el mantenimiento del código es aburrido.
Para mí, es similar a tener la capacidad de construir y enviar un cohete a Marte, pero en lugar de ello pasas la mayor parte de tu tiempo haciendo el mantenimiento de un cohete de los años 90 que podría o no volar de nuevo (¡Me sale la vena de ingeniero aeroespacial!)
Pero, ¿por qué se odia tanto el mantenimiento? La respuesta se encuentra en algún lugar entre los 306 millones de horas, la pérdida de productividad y la falta de reconocimiento.
Este blog ofrece dos perspectivas: nuestra misteriosa Dev-I, que no soporta el trabajo de mantenimiento como la retrocompatibilidad, y nuestro jefe de Producto, que está facilitando la vida a esos desarrolladores.
No hay termino medio en el trabajo de mantenimiento
Por término medio, los desarrolladores como Dev-I dedican 17 horas a la semana a tareas de mantenimiento. Con 18 millones de desarrolladores en todo el mundo, eso supone un total de *saquemos la calculadora* 306 millones de horas semanales dedicadas al mantenimiento en todo el mundo.
Trescientos seis millones de horas en total. En cuestiones como refactorización de código, mejoras, migración... y retrocompatibilidad.
Nadie cuestiona la importancia del mantenimiento. Pero, como dice uselessdev de uselessdevblog en este artículo, siempre hay que elegir entre aportar valor o dar mantenimiento.
Cuanto menos se dedique a las tareas de mantenimiento, más deuda tecnológica se acumulará. Las empresas entienden esto, pero a menudo no invierten suficiente tiempo o dinero en el mantenimiento. Porque el negocio consiste en crear valor, ¿verdad?
"Mi empresa me paga para que me centre en aportar valor. Pero esto te lleva a la zona de la 'deuda tecnológica'. No hay ningún incentivo para pagar a la gente para hacer frente a la deuda tecnológica" – uselessdev
El mantenimiento nunca es el principal atractivo de ser un desarrollador de software. Cuando los desarrolladores como Dev-I aprendieron a codificar no lo hicieron con la idea de hacer mantenimiento de código.
Retrocompatibilidad: Gratificante para algunos, repetitiva para otros
Algunos trabajos de mantenimiento –como la retrocompatibilidad– tienen el potencial de ser gratificantes.
Si no que se lo pregunten al equipo que está detrás de la retrocompatibilidad de Xbox. La nueva Xbox Series X es retrocompatible con las cuatro generaciones de Xbox, lo que hace las delicias de jugadores de todo el mundo (excepto de Dev-I y de los fans de Nintendo).
Poner cualquier juego antiguo de Xbox en la consola más reciente, rezar un par de oraciones (opcional), sentir como los ojos se llenan de lágrimas de nostalgia y empezar a jugar. Es así de sencillo.
Se trata de ofrecer una experiencia de cliente que cambia el juego. Esto ilusiona a millones de usuarios de Xbox en todo el mundo. Se trata de un trabajo de mantenimiento que otorga un reconocimiento directo a los desarrolladores.
Pero no todo el trabajo de retrocompatibilidad es gratificante o interesante, especialmente en el mundo del software low-code de Dev-I.
Retrocompatibilidad en low-code (o cómo hacer feliz a Dev-I)
La brutal realidad de todas las empresas B2B es que, la mayoría de las veces, necesitan reutilizar datos y aplicaciones creadas con una versión anterior de la plataforma. La aplicación más antigua de Appian que todavía funciona es de 2008. Dev-I todavía estaba en el instituto. Se le podría pedir que integre esa aplicación en una de la última versión. Es algo que vemos con nuestros clientes a menudo.
Quizá por eso Appian tiene una promesa de retrocompatibilidad tan sencilla como la de Xbox. "La retrocompatibilidad es a menudo lo que me hace feliz y me libera del trabajo 'que te destroza el alma'", dice Dev-I.
Al asegurarnos de que las funciones y aplicaciones antiguas funcionen aún mejor cuando se actualiza a una nueva versión, eliminamos el trabajo manual, aburrido y repetitivo de los desarrolladores de todo el mundo.
Para el ingeniero que hay en mí, esto era demasiado bueno para ser verdad. Pero cuando me acerqué a la comunidad de Appian para ver lo que decían nuestros usuarios sobre la retrocompatibilidad, captó mi atención esta respuesta de Stefan Helzle, gerente de una empresa multinacional de servicios profesionales.
¿No hay problemas de retrocompatibilidad desde 2010? Esto es un aval bastante rotundo.
"Nosotros sufrimos para que usted no tenga que hacerlo" – La opinión de un arquitecto de productos sobre la retrocompatibilidad
Hablé con Matt Hilliard, arquitecto de producto de la plataforma Appian, sobre nuestra retrocompatibilidad. Matt es un desarrollador de OG que empezó a codificar en Java en 2003 antes de centrarse en el low-code. Si alguien puede explicar con detalle nuestro compromiso con la retrocompatibilidad, ese es Matt.
"Hemos creado todo nuestro proceso interno en la plataforma Appian. Antes de que cualquier cliente reciba la última versión, nuestras aplicaciones clave ya están funcionando con la nueva versión. Si metemos la pata con la retrocompatibilidad, nos enteramos primero internamente", dice Matt.
"Hacemos extensas pruebas de regresión para asegurarnos de que las aplicaciones existentes funcionen. En cierto modo, sufrimos mucho para evitar que nuestros clientes sufran un poco".
Tenemos cientos de aplicaciones internas para llevar nuestro negocio, todas ellas creadas sobre Appian. Si algo no funciona en una nueva versión, puede estar seguro de que el equipo de desarrolladores de Matt se enterará antes de que se lance al público.
En palabras de Matt, hay algunos principios clave para ofrecer una retrocompatibilidad sin precedentes.
- Cualquier uso de una función, por pequeña que sea, la conservamos y trabajamos para mejorarla
- Disponer de pruebas de regresión automatizadas completas y uso interno de la plataforma
- Solo exponer las características/configuraciones que los clientes necesitan de verdad, ya que las respetamos durante años
- Corregir siempre en caliente los infrecuentes errores de retrocompatibilidad que se cuelan en nuestros controles de calidad
"Los errores ocurren. Los fallos ocurren. Se producen cambios de comportamiento. Así son las nuevas versiones", afirma Matt. Los desarrolladores son muy pragmáticos.
"Por ello, nos comprometemos con la empresa a corregir siempre los problemas de retrocompatibilidad, por muy sutiles que sean o por muy pocos que sean los clientes que los utilicen".
Construir para el desarrollador
Al crear aplicaciones móviles públicas (las que se compran en las tiendas de aplicaciones móviles) estamos a merced de las empresas tecnológicas para las actualizaciones. Se actualiza cuando y como ellos quieren.
Sin embargo, para Appian, los desarrolladores de aplicaciones como Dev-I son nuestros clientes. No podemos volver locos a los desarrolladores.
Si construyes en la nube de Appian, la actualización a las nuevas versiones se realiza de forma automática y sin problemas. Pero si no lo haces, tenemos el compromiso de hacerlo lo más fluido posible para los desarrolladores.
Con cuatro lanzamientos al año, la única manera de hacerlo es ofrecer una retrocompatibilidad total.
Según el último recuento, hay más de 2000 puestos de trabajo de desarrollador de Appian disponibles actualmente en LinkedIn en todo el mundo.
Eso supone más de 2000 nuevos desarrolladores que entran en las empresas teniendo que lidiar con datos y aplicaciones anteriores. Y ni siquiera estoy contando los miles de desarrolladores de Appian que ya están lidiando con eso hoy en día (no miro a nadie, Dev-I).
Con la retrocompatibilidad, queremos dar a los desarrolladores como Dev-I más tiempo para sus actividades intelectuales, ya sea para crear nuevo código o para jugar a la Nintendo Switch.
Para los desarrolladores curiosos
Puede leer todo sobre la filosofía de cómo Appian construye para la retrocompatibilidad aquí.
Sin embargo, sé que los desarrolladores son muy curiosos. Así que les invito a probar Appian en Appian Community Edition, un entorno gratuito donde se puede explorar Appian.
Escoja uno de los cursos de la personalidad "Builder" y pruébelo. Pruebe a esperar unos tres meses por la siguiente versión y, de paso, compruebe la retrocompatibilidad.
