El programador ha dejado de contestar. Puede que se haya ido a otra cosa, puede que la relación acabara mal, puede que simplemente se quedara callado. El software sigue funcionando, que es la parte que hace que la gente espere más de lo que debería - funciona, así que todavía no es una emergencia.
Sí es una emergencia. Cada semana que esperas caduca algo que no sabías que estaba a nombre de otra persona.
Comprueba estas cinco cosas hoy
No la semana que viene. Cada una de ellas se puede recuperar mientras la cuenta siga viva y se convierte en un problema legal caro en cuanto expira.
- El registrador del dominio. Busca tu dominio en un servicio WHOIS. Si el titular no eres tú ni tu empresa, no controlas tu propia dirección. Esta es la que acaba con negocios.
- El DNS. A menudo está en un proveedor distinto del registrador. Quien controla el DNS controla adónde va tu correo.
- El servidor o la cuenta de hosting. ¿A qué tarjeta se cobra? Una tarjeta caducada en la cuenta de otra persona borra tu web con un correo automático que no lee nadie.
- El repositorio de código. GitHub, GitLab, Bitbucket. Si no lo has visto nunca, da por hecho que no lo tienes.
- Las cuentas de terceros. El procesador de pagos, el servicio de facturación, la pasarela de SMS, la analítica. Cada una es un acceso distinto y cada una se puede cancelar sin ti.
Apunta lo que encuentres. Esa lista es el estado real de tu propiedad, y suele ser peor de lo que sugiere el contrato.
"El código es nuestro" no es lo mismo que ser dueño del sistema
La mayoría de los contratos ceden los derechos de autor del código fuente, y la mayoría de los clientes lo leen como propiedad. Es algo más pequeño de lo que suena.
Ser dueño del código significa que legalmente puedes usarlo y cambiarlo. No significa que tengas una copia, que alguien sepa ejecutarlo, que las cuentas con las que habla sean tuyas, ni que la persona que sabe por qué se construyó así esté obligada a explicártelo. Me he hecho cargo de sistemas en los que el cliente tenía unos derechos de autor perfectamente válidos sobre un software que no podía desplegar, en un servidor al que no podía acceder, con claves de API registradas a un correo personal de una empresa que ya no existía.
La propiedad es una lista de comprobación, no una cláusula.
Qué se suele poder salvar
Más de lo que la gente teme. Que el código te resulte ajeno no significa que sea malo, y el software heredado tiene una fama que no siempre merece - un sistema que escribió otra persona siempre parecerá peor que uno que escribiste tú, porque no ves el razonamiento.
Lo que de verdad lo decide es algo más concreto que la calidad del código:
- ¿Están los datos íntegros y se pueden exportar? Es la única parte insustituible. El código se puede reescribir en semanas; cinco años de fichas de clientes no se reconstruyen de ninguna manera.
- ¿Se sigue pudiendo desplegar? Un sistema que nadie puede reconstruir desde el código fuente es un sistema que corre en una máquina que no puedes reiniciar nunca.
- ¿Siguen mantenidas las dependencias? Un framework tres versiones mayores por detrás es un presupuesto, no un impedimento.
- ¿Se pueden recuperar las claves? Las claves se pueden volver a emitir. El problema son las cuentas que las guardan.
Fíjate en que ninguna de estas es "¿es elegante el código?". He estabilizado sistemas genuinamente feos en una semana porque los datos estaban limpios y el deploy funcionaba, y he recomendado sustituir otros muy ordenados en los que no se daba ninguna de las dos cosas.
La respuesta honesta suele ser "menos de lo que crees"
La gente llega esperando oír que hay que reconstruirlo todo, en parte porque es lo que le ha dicho quien presupuestó por última vez. A veces es verdad. Más a menudo el sistema está sano y lo que falló fue todo lo que había alrededor: nadie sabía desplegarlo, los backups nunca se probaron y una sola persona tenía todas las cuentas.
Eso es una semana de trabajo y un traspaso, no una reescritura. Prefiero decírtelo y cobrarte una semana de trabajo antes que venderte seis meses que no necesitabas - en parte porque es verdad, y en parte porque el cliente al que le dijeron la verdad es el que vuelve.
Cómo no volver a estar aquí
A quien contrates la próxima vez, exígele esto antes de que se escriba la primera línea, no al final: todas las cuentas se crean a tu nombre, las creas tú, y al programador se le añade a ellas. No transferidas en la entrega. Tuyas desde el principio.
No cuesta nada, lleva una tarde y es toda la diferencia entre un cambio de proveedor y una crisis. Si un programador se resiste, has aprendido algo valioso pronto, mientras aprenderlo todavía es barato.
El resto del estándar de entrega - documentación, tests, un deploy que pueda ejecutar tu propio equipo - está en mi página de servicios, y la razón por la que me importa tanto está en la nota sobre quién usa de verdad tu software.