D0gware - Blog

• Para empezar, quiero plantearte dos escenarios que ilustran de qué va este breve artículo:

• • Durante la Guerra Fría, la NASA se propuso un desafío: diseñar un bolígrafo que funcionara en el espacio. Invirtieron millones de dólares y lo lograron: crearon un bolígrafo capaz de escribir en cualquier ángulo y condición. Mientras tanto, los rusos, con una visión más pragmática, optaron por un simple lápiz para tomar notas en el espacio. Podríamos decir que los estadounidenses invirtieron en conocimiento más allá del objetivo inmediato; sin embargo, los rusos identificaron el problema original y lo resolvieron de la manera más sencilla y efectiva.

• • Imagina un camión grande atorado bajo un puente por apenas unos centímetros. El caos vial estalla: llegan Protección Civil, el ejército, bomberos y grúas. Todos debaten cómo usar maquinaria pesada para mover el camión o incluso demoler el puente. De pronto, un niño que observa la escena sugiere: "¿Y si solo le bajan la presión a las llantas?"

• En el desarrollo de software existe un concepto clave que siempre debemos tener presente: la complejidad accidental. Esta se refiere a la complicación adicional que introducimos por las herramientas o decisiones que elegimos para abordar los requerimientos. Muchos desarrolladores caen en la tentación de adoptar diseños modernos por el entusiasmo de la novedad o, peor aún, por presiones de usuarios o analistas que asumen que "lo último" siempre es mejor.

• Todo comienza con un problema que, de entrada, suele ser complejo: el reto inicial. La complejidad real radica en delimitar el problema y los objetivos funcionales del sistema. ¿Qué proceso estamos automatizando? ¿Es un proceso manual robusto y maduro? ¿O nos piden automatizar incertidumbre y flujos ambiguos? Si el proceso está claro, surge la segunda complejidad real: resolver esos requerimientos mediante análisis de datos, flujos organizacionales y más.

• Hasta aquí hemos logramos superar las dos complejidades iniciales. Entonces, nuestro siguiente desafío es evitar la complejidad accidental, que depende enteramente de nuestras decisiones técnicas.

¿Cómo lo conseguimos?

Cada herramienta o diseño que elegimos tiene beneficios, pero también acarrea complejidad añadida. Esto puede ir desde la falta de dominio profundo de una tecnología (que exige horas extras de estudio) hasta costos de licenciamiento o implementación que desbordan presupuestos. ¿Y qué tal las compatibilidades entre sistemas operativos o el uso de librerías específicas?

Te enlisto algunas consideraciones técnicas para ayudar a simplificar el desarrollo de soluciones:

• Elige tecnologías según el proyecto, no las modas. No todo necesita soluciones "headless", ni "serverless", mucho menos con inteligencia artificial. Evita frameworks inmaduros o dependientes de tecnologías y librerías ajenas al contexto del problema.

• Piensa en el crecimiento de datos y demanda, pero con realismo. Una aplicación no pasa de 100 a 100 millones de usuarios de la noche a la mañana. Si ocurre, es señal de que el alcance inicial se entendió mal. En otras palabras: no caigas en la sobreingeniería.

• Mantén el código simple. Evita abstracciones innecesarias y no refactorices desde el inicio. Aquí aplica el principio KISS ("Keep It Simple, Stupid" o "Mantenlo simple, estúpido"): los sistemas funcionan mejor cuando son sencillos, no cuando se complican sin razón.

• Homogeneidad es simplicidad. El código base debe ser consistente; no mezcles diferentes formas de resolver lo mismo dentro de una misma aplicación.