Una nueva funcionalidad siempre cuesta tiempo, esfuerzo y recursos, está claro. Y mucho del tiempo empleado, y de los recursos que dedicamos a una nueva funcionalidad o característica en Velneo, no es sólo diseñarla y programarla, sino que lo empleamos en probarla, en documentarla, en el despliegue de la novedad...
Para empezar, las novedades no comienzan su ciclo de vida con la versión, se vienen investigando y definiendo mucho antes, se ha valorado su impacto para los usuarios, qué necesidades cubren y qué beneficios aportan, pero también qué impacto tendrá sobre la estabilidad y mantenimiento del producto actual.
Porque la estabilidad y el mantenimiento de la funcionalidad, es la que mayor coste tiene realmente, y lo que realmente puede derivar en deuda técnica.
De hecho, también se valoran las distintas soluciones posibles y también las distintas formas de implementación que puedan tener, y qué repercusiones han tenido. Alguna novedad la hemos “rehecho” hasta 4 o 5 veces para quedar a gusto con el resultado. Un ejemplo reciente de ello, ha sido el nuevo objeto Reemplazo, que se estudió su forma de implementarlo de cara al usuario de diferentes formas, como propiedad, como subobjeto, como estilo, como comando de instrucción… Pero también la forma y el momento en el que se hace el reemplazo: dinámico, en el cliente previo a la carga, tras la carga… Todo ello con el fin de que esta novedad no sólo satisfaga las necesidades, si no de que nos aseguremos de que permanece en el tiempo sin generarnos deuda.
Porque sobre todo, el coste no está tanto en hacer la novedad, que funcione, sino en mantenerla, en que funcione en Windows, en Linux, en macOS, en Android, en iOS, en sistemas operativos de 64 bits, en sistemas operativos de 32 bits, con una huella de consumo de recursos lo menor posible, con estabilidad y usabilidad, aportando un beneficio al desarrollador y al usuario final, en cada actualización de librerías, en cada actualización de sistemas operativos.
Otro ejemplo de todo ello, pueden ser dos novedades de las últimas versiones. Por un lado, en rejillas, la optimización de columnas para punteros que introdujimos en Velneo 26. Con ella arrancamos una migración “tranquila”, que pretende ir sacando todas las condiciones y casuísticas a la luz, permitiendo optimizar manualmente aquellas rejillas que nos interese. En Velneo 27, ya configuramos por defecto este comportamiento para las nuevas rejillas, con lo que conseguimos el efecto beneficioso de la novedad, habiendo solucionado gran parte de las incidencias que aparecieron gracias al proceso previo.
Esta misma técnica de despliegue de novedades la hemos empleado en la nueva versión Velneo 27 con el reemplazo de objetos. Hemos comenzado a aplicar la novedad a determinados objetos, iremos viendo las incidencias que puedan aparecer, no sólo de funcionalidad sino también de mantenimiento, e iremos viendo qué mejoras se pueden incluir en los nuevos objetos en que trabajemos para incorporar la nueva funcionalidad de reemplazo.
Pero es que definir qué novedades y nuevas funcionalidades se van a implementar, ya son también una herramienta para evitar la deuda técnica. Las presiones comerciales, que provocan que una decisión no sea sólo técnica, puede hacer que tomemos malas decisiones, que no beneficien realmente a nuestros desarrolladores. Sin embargo, aquí contamos con la ventaja del modelo de negocio de Velneo, basado en la suscripción.
Esto nos permite centrarnos realmente en las necesidades de nuestros clientes, no en la moda imperante para generar venta nueva, porque nuestro interés es que nuestros desarrolladores tengan en Velneo la herramienta que les permite disfrutar de la programación y conseguir sus objetivos profesionales.
Esta tranquilidad que nos da nuestra forma de funcionar, nos permite realmente trabajar en qué necesitamos los desarrolladores, buscar lo mejor, e innovar. Y por ello, otro trabajo muy importante es el estudio de las ideas del foro de ideas, por eso es tan importante nuestro voto en el foro de ideas. Todo ello con el fin de encontrar aquellas que realmente tienen sentido en la herramienta y realmente aportan, para no encontrarnos luego con zombis, objetos muertos en vida desde el primer día porque no se usan realmente, y que sin embargo hemos de mantener.
También en este caso es importante tener en cuenta los estándares. Cuando comenzamos, empezamos usando mucha terminología propia, y aunque continuamos usando alguna, ya que en muchos casos no existen análogos en otras herramientas, sí que hemos alineado cierta nomenclatura. Alguno recordará en los inicios el uso de la nomenclatura de Sitios y Cajas, que desde hace bastante ya se conocen por Soluciones y Proyectos. Pero también nos hemos abierto a tecnologías como Javascript, QML, Chromium, Importador SQL, API Rest, que nos permiten una mayor apertura de Velneo a la programación estándar y a lo que venimos acostumbrados a escuchar los desarrolladores.
Luego, en nuestro día a día, cuando desarrollamos código, aplicamos técnicas como la integración continua, control de versiones, revisión por pares, programación en pareja, por supuesto refactorización, además de análisis estático y dinámico de código, tests unitarios, documentación autogenerada desde el código, y otra serie de técnicas que tienen como fin evitar trampas que nos pone, que nos permiten encontrar dónde podemos generar deuda técnica y buscar la mejor forma de llevarlo a cabo, y que nunca serán suficientes.
Refactorizar, por ejemplo, es importante porque no siempre tenemos el conocimiento completo la primera vez que trabajamos en un tema, pero también complicado, porque buscando la estabilidad, no queremos provocar cambios de comportamiento. Pero aunque intentamos que a la primera, el código sea ya para siempre, es cierto que no siempre podemos prever todo, así que hay que revisarlo no sólo para que resuelva la funcionalidad, sino también para que acepte el paso del tiempo.
Porque es cierto que tenemos el concepto de escribir código como nuestro trabajo, como arte, pero no puede estar por encima de la funcionalidad, sino a su servicio, al servicio de los desarrolladores.
