Falsedades que los programadores creen sobre los DNIs

1. “Un DNI válido tiene exactamente ocho caracteres”

Quienes cometieron el sistema bancario que muestro decidieron que un DNI debe tener, sí o sí, ocho caracteres. Si se ingresan sólo siete dígitos, el sistema no permite avanzar.

Para tomar esa decisión, ¿consultaron alguna normativa, revisaron la base de clientes, o realizaron cualquier otra actividad que permitiera una decisión basada en evidencia? ¿Salieron en algún momento de la caverna platónica desde la que programan?

No. Si lo hubieran hecho, se hubieran encontrado con miles de casos como el de mi madre, quien cobra su jubilación en ese mismo banco… y tiene un DNI de tres millones. O sea, 7 dígitos.

“Entonces tu mamá tendrá que poner un cero adelante”, podría decir el analista funcional cavernario responsable (¿?), ignorando que:

• las personas usuarias no tienen por qué adivinar requerimientos que no existen en el mundo real, sino que salieron de la galera del programador de turno.
• es muy poco probable que a una persona de más de 70 años se le ocurra probar semejante ridiculez.

En mi experiencia facilitando y observando sesiones de usabilidad con adultos mayores, cuando ingresan sus datos correctamente y el sistema no los deja avanzar, rara vez modifican la información. En lugar de eso, el 99% de las veces elaboran hipótesis, sospechas y quejas resignadas sobre el sistema, el banco o el gobierno de turno.

No es un problema “generacional”. Es una cuestión básica de accesibilidad, de un sistema que margina a sus usuarios y los obliga a depender de un tercero para actividades de su vida diario. Un sitio que des-habilita, reforzando estereotipos estúpidos como éste:

El supuesto de que todos los DNIs deben tener 8 caracteres es una decisión que los programadores tomaron basándose en sí mismos como referencia. No hubo una consideración real hacia las personas usuarias que deberían operar el sistema.

Los programadores son una de las profesiones más alejadas del público. Dentro de los equipos que desarrollan software, ocupan los últimos puestos del ranking de la empatía. Es común que no tengan conciencia de que están reemplazando sistemas de atención al público, ni de las disciplinas que abordan la calidad de atención en el software. Lamentablemente, aún hoy existen equipos donde, por falta de madurez, dirección y roles apropiados, los programadores son los únicos responsables de las decisiones de diseño de interacción — creando sistemas sesgados, inflexibles y hostiles que se infligen sobre las desafortunadas personas usuarias.

2. “El número de DNI es único”

Suele sorprender que el número de DNI argentino no sea único. Pero, ¿por qué la sorpresa? El hecho de que existan pares de personas con el mismo número de DNI no derriba una definición formal. Simplemente se opone a una creencia que nosotros habíamos asumido.

Como profesionales del software, no deberíamos sorprendernos cuando nuestros supuestos se revelan inválidos. Más bien, deberíamos mantener una postura de prudente sospecha sobre todo lo que creemos saber.

Que existan colisiones de números de DNI resulta bastante razonable cuando consideramos cómo surgieron. Cuando a principios del siglo XX se empezaron a asignar números de documento (en ese entonces, la Libreta de Enrolamiento), no existían ni internet ni telecomunicaciones fiables. Sin un mecanismo de sincronización, la correlatividad de los documentos quedaba librada a la suerte. La posterior creación de la Libreta Cívica para el voto femenino, con su propia numeración, complicó más las cosas.

Recién con la digitalización de los registros en las décadas de 1980 y 1990 se pudo normalizar la situación. Y es así que se encontraron millones de números de DNIs asignados a más de una persona. AFIP y ANSES decidieron que la única solución era hacer “borrón y cuenta nueva”. Es así como crearon en 1990 el número de CUIT/CUIL. En donde la “U” es de “Único”, cosa que el DNI no es.

Una de las primeras cosas que hacemos en Kambrica cuando evaluamos sistemas de atención al público, CRMs, etc., es observar si el sistema se basa en el falso supuesto de que los números de DNI son únicos, y si existe algún mecanismo para resolver colisiones. Generalmente, no lo hay, y a la pobre persona afectada no le queda más que jorobarse.

“Mala suerte”, dirá el analista funcional cavernario del capítulo anterior. No, no es mala suerte. Es ignorancia, soberbia y negligencia de quienes tienen el gran poder de definir cómo funcionan y se comportan los sistemas.

No podemos construir sistemas sobre falsedades

Quienes definimos el comportamiento de los sistemas que utilizarán otras personas no podemos caer en la soberbia de considerarnos la medida de todas las cosas, ni basarnos en lo que “nos parece”. Cada decisión de diseño de sistemas debe ser sólida y fundamentada en evidencia. De lo contrario, estaremos bloqueando a usuarios legítimos solo por ignorancia.

A más de diez años de promulgada la Ley N° 26.653 de Accesibilidad Web, trabajar sobre supuestos no sólo es chapucero e inadmisible: puede ser ilegal.

Para no caer en falsos supuestos, no hace falta que seamos infalibles, que lo sepamos todo. Tenemos al alcance de los dedos la posibilidad de resolver cualquier duda. Y de hecho, la aprovechamos continuamente… cuando somos conscientes de nuestra falibilidad.

Ningún programador se lanza a escribir miles de líneas de código sin consultar cada tanto la documentación o la web. Porque, si no lo hace, es casi seguro que el código no funcionará: ningún programador es, ni debe creerse, infalible al escribir código. Como dice Joel Spolsky, es más difícil leer código que escribirlo – y es por eso que es mejor encontrar los bugs lo antes posible.

Lo mismo ocurre con los supuestos sobre los cuales construimos el comportamiento de los sistemas. Nunca podemos caer en la soberbia de considerarnos infalibles en nuestro conocimiento sobre cómo funciona el mundo. Las personas usuarias merecen que investiguemos los requerimientos y supuestos que las afectan, tanto como las máquinas merecen que consultemos argumentos y funciones.

Santiago Bustelo
Septiembre 2024