Cada semana aparece una empresa nueva que promete entregarte una aplicación en la mitad de tiempo y por la mitad de precio. La letra pequeña casi siempre es la misma: buena parte de ese software no lo ha escrito una persona, lo ha generado una inteligencia artificial.
Nosotros hemos decidido no hacerlo. No por desconfianza hacia la tecnología —la usamos a diario para otras cosas—, sino por lo que le pasa a un proyecto cuando nadie del equipo entiende del todo lo que ha entregado.
El problema no es la primera versión
Una aplicación generada automáticamente suele funcionar bien el primer día. El problema llega tres meses después, cuando hay que cambiar algo.
En ese momento aparecen las preguntas que deciden si un proyecto sale adelante o se convierte en un pozo sin fondo: ¿por qué está hecho así?, ¿qué pasa si toco esto?, ¿esto se puede quitar? Si quien te entregó el software no sabe responder, cada cambio se convierte en una apuesta.
Nosotros venimos de sistemas donde un fallo no es una molestia. Álvaro ha mantenido software de gestión de tráfico aéreo; Adrián, servicios de monitorización de infraestructura de gas. En esos entornos aprendes una cosa muy concreta: el código se lee muchas más veces de las que se escribe. Optimizar la velocidad de escritura y olvidarse de la lectura es un mal negocio.
Lo que sí nos importa de verdad
Cuando decimos que escribimos el código a mano, no hablamos de artesanía romántica. Hablamos de tres cosas muy prácticas:
- Alguien responde. Si algo falla, hay una persona que sabe por qué está escrito así y puede arreglarlo en horas, no en semanas.
- La aplicación no engorda sola. El código generado tiende a repetirse. Repetir código significa que cada cambio hay que hacerlo en cinco sitios, y que tarde o temprano alguien se olvida de uno.
- Las decisiones sobre tus datos se toman con criterio. Dónde se guarda un dato personal, cuánto tiempo y quién puede verlo no es una decisión técnica: es una decisión legal. En nuestro caso la revisa Jhonathan, que es abogado.
¿Significa esto que somos más lentos?
Al principio, a veces sí. En el conjunto del proyecto, casi nunca.
Lo que ahorras generando código lo acabas gastando en corregir comportamientos raros, en explicar por décima vez cómo funciona algo o en rehacer una parte entera porque ya nadie se atreve a tocarla. Preferimos repartir ese esfuerzo desde el principio y llegar al final sin sorpresas.
También ayuda que no aceptamos todo lo que nos llega. Si un proyecto no encaja en el plazo o el presupuesto que hay sobre la mesa, lo decimos antes de empezar en lugar de descubrirlo a mitad de camino.
Cómo comprobarlo si estás valorando proveedores
No hace falta ser técnico para distinguir un enfoque del otro. Bastan tres preguntas en la primera reunión:
- ¿Quién va a escribir exactamente mi aplicación y seguirá estando dentro de un año?
- Si necesito cambiar algo dentro de seis meses, ¿cuánto tardaríais en decirme el impacto?
- ¿Quién revisa cómo se tratan los datos personales de mis empleados o mis clientes?
Las respuestas a esas tres preguntas dicen más sobre la calidad de lo que vas a recibir que cualquier presentación comercial.
Si te interesa cómo aplicamos esto en la práctica, puedes ver OnTempo, nuestra aplicación de registro de jornada y gestión de personas, o simplemente escribirnos y lo hablamos.
¿Te ha sido útil?
Si quieres comentarnos algo o tienes una duda sobre tu caso, escríbenos.