It's not a bug

Corría el año 98 y yo merodeaba por el campus de informática de la Universidad Pontificia de Salamanca en Madrid. No recuerdo muy bien cómo —porque en aquella época casi nadie tenía portátil— pero me llegó un meme (aunque entonces no los llamábamos así) que decía: It's not a bug, it's a hidden feature.

En ese momento pensé: vaya morro, qué excusa más barata. Si es un bug, es un bug.

Veinte años después, tras trabajar en grandes compañías y desplegar APIs en producción, he cambiado de opinión...

Recuerdo estar trabajando en un sistema complejo de gestión de transferencias de datos entre origenes muy diversos dentro de una compañia grande. El sistema que desarrollamos tenía un protocolo común de transferencia de bytes, y unos conectores específicos para cada tecnología (bases de datos como oracle, o mongo, etc, sistemas de archivos como sftp, nfs...).

Resulta que desarrollamos todo en Golang (algo que sin duda fue un éxito de rendimiento y mantenibilidad). Esto igual no es relevante, pero el caso es que cuando usábamos el driver del Oracle (una implementacion open source del oci) éste nos devolvía los datos leídos de la tabla en estructuras de Golang. De tal manera que nosotros convertíamos las estructuras en una línea CSV (strings).

Llegamos a producción bastante rápido (en solo seis meses ya había transferencias productivas). Poco después, recibimos un ticket por un formato ‘extraño’ que estaba produciendo el servicio al leer de Oracle. Para no hacer muy largo el articulo os sacaré de dudas, a día de hoy sigue produciendo el mismo formato extraño alejado de cualquier estándar de mercado.

Cuándo descubres un comportamiento inesperado en una pieza (sobre todo apis y servicios cloud; autoaprovisionados) no puedes simplemente fixearlo.

Si hubiéramos cambiado el formato a algún otro estandarizado, habríamos roto cientos de transferencias que habiéndose encontrado la misma situación, simplemente adaptaron sus desarrollos a esta hidden feature o comportamiento inesperado.

En su día analizamos el impacto de cambiarlo, era grande. Había otras posibilidades, como por ejemplo implementar una semántica nueva para el driver Oracle, que le dijera "use RFC3339". Esto hubiera mantenido el comportamiento para todo lo que ya estaba funcionando, y hubiera mitigado el inconveniente del tratamiento de fechas con formatos no estándar que teníamos. Además de brindar la posibilidad de evolucionar de forma independiente los desarrollos existentes.

Cuando desarrollas APIs o servicios cloud, no tienes contacto directo con los clientes, sino que debido a la autoprovisón, éstos usan tus apis y servicios como pueden o entienden a partir de la documentación de que disponen. En estos casos cambiar cualquier comportamiento del api es "delicado" y aún cuándo descubres que no se está comportando como esperas, no puedes tratarlo como un bug y simplemente fixearlo. Las posibilidades de romperle el aplicativo a tu cliente son altas, si no se toman las debidas precauciones.

Aquel meme que vi en el campus resultó tener más verdad de la que creí. No era solo una excusa: en muchos contextos reales, lo que parece un bug... no lo es.