Cinco antipatrones de software que puedes encontrar en la vida diaria

Desarrollar software es una actividad compleja. Por eso, solemos caer en el empleo de «antipatrones», o intentar resolver problemas recurrentes con ciertas soluciones que han demostrado ser ineficaces y contraproducentes.

Los informáticos nos dedicamos a abstraer y modelar problemas de la realidad para intentar encontrar una solución óptima para los mismos, pero ¿y si recorriéramos el camino contrario? Hay problemas habituales en el desarrollo de software que pueden encontrarse en cualquier realidad. El empleo de antipatrones, también. Por ejemplo, estos cinco que podemos encontrar frecuentemente en cualquier escenario:

1. Mushroom Management

La «gestión de champiñones» o desarrollo ciego es la práctica de mantener al equipo de desarrollo completamente aislado de los usuarios finales del software que están desarrollando. Los requisitos se suministran a través de intermediarios.

El problema de esta práctica es el enorme riesgo de acabar desarrollando algo que no sea lo que tus usuarios o clientes quieran. Algo que puede verse en otras actividades, desde la industria alimentaria hasta los estudios de arquitectura.

2. Poltergeists

Un antipatrón de programación orientada a objetos son los o la existencia de «objetos» —piezas de software— cuyo único propósito es pasar información a otros. Se les da ese nombre porque, al igual que los fantasmas, este código se invoca inesperadamente y durante un tiempo de ejecución muy corto. El problema es que hacen el software más difícil de mantener y suponen un desperdicio de recursos.

Las reuniones informativas —esas en las que no se decide nada y podían haber sido un simple mail— son el trasunto corporativo más obvio de este antipatrón, pero no el peor. Algunas empresas albergan «poltergeists humanos» en su organigrama, correveidiles profesionales cuya principal responsabilidad es transmitir a ciertos empleados la información generada por otros. El problema es que hacen que la estructura sea más difícil de mantener y supone un desperdicio de recursos.

3. Cargo Cult programming

Estilo de programación caracterizado por el uso de patrones y estructuras de código sin entender realmente por qué se está haciendo. Lo que suele producir resultados inesperados. Su nombre deriva de los cultos cargo, surgidos a raíz del contacto de tribus aisladas del Pacífico con soldados o suministros de las potencias en liza durante la Segunda Guerra Mundial.

Es habitual ver cargo cult programming —por ejemplo— en los primeros pasos de alumnos de bootcamps, programas intensivos de muy corta duración donde se enseña a los alumnos los conocimientos mínimos para producir código funcional, pero no lo que hay detrás de «la majia» de frameworks y librerías como React o Rails.

También es habitual ver cargo cult en la gestión y organización de muchas empresas. Desde el emprendedor que cree que empezar en un garaje le dará más posibilidades de éxito; a la corporación que da por hecho que organizando su plantilla en squads, tribes y guilds —como se supone que hizo Spotify— va a replicar su trayectoria, sin analizar las verdaderas claves de la misma.

4. Optimización Temprana

La optimización temprana o prematura aparece cuando invertimos una cantidad considerable de tiempo intentando mejorar el rendimiento de nuestro código, antes de saber siquiera si funciona. Dicho código suele ser más difícil de mantener, pero el principal problema es que corremos el riesgo de desperdiciar nuestro tiempo, optimizando algo que no sabemos cuánto se va a usar... si es que se usa.

Es fácil observar esta optimización temprana más allá de la Informática. Por ejemplo, cuando una empresa diseña un proceso de selección absurdamente complejo antes de saber siquiera si va a recibir una sola candidatura. Un killer combo habitual es la combinación de la optimización temprana con cargo cult. Como cuando Informática Sanabria SL adopta el proceso de selección de Google.

La optimización temprana es la raíz de todos los males.

Structured Programming with go to Statements (1974)

— Donald Knuth (1938)

5. Hard Code

El hard code es una mala práctica de desarrollo de software consistente en incrustar datos directamente en el código fuente de un programa en vez de obtener esos datos, a la hora de ejecutar el mismo, de una fuente externa como un fichero de configuración o —directamente— los propios usuarios.

El problema del hard code es que presupone cómo será el entorno en el que se ejecutará el programa —por ejemplo, la ruta en el disco duro donde se encuentra un programa— y, si este cambia, hay que modificar el programa. 

Más allá del código, hay muchos procedimientos y estructuras hardcodeadas en las empresas. Desde procesos de alta de proveedores, que se aplican por igual a una megacorporación de miles de empleados que al bar de la esquina que te sirve churros y porras para una reunión, hasta compañías que no varían su modelo de negocio aunque el negocio haya cambiado.

Cuando empecé a escribir este artículo pensé que sería difícil encontrar cinco antipatrones que pudiera aplicar a la vida real. Lo difícil ha sido elegir sólo cinco. Podemos encontrar muchos más en el día a día de compañías y organizaciones: la ocultación de errores, la espera activa o el ancla de barco que nos cuesta soltar porque supone asumir que una inversión es, en realidad, un coste hundido.

Está por ver si las mismas soluciones que aplicamos para intentar evitar estos errores en nuestro código podrían emplearse también en otras actividades o sectores. A lo mejor tenemos los mismos problemas y nuestro trabajo no es muy distinto de cualquier otro excepto, eso sí, que nuestro trabajo es usar la tecnología para intentar solucionarlos.

Artículo publicado por David Bonilla en La Bonilista el 22 de agosto de 2021