El desarrollo de software no es un problema industrial

Existe una tentación persistente de tratar el desarrollo de software como una actividad industrial.

La tentación es comprensible. La industrialización promete previsibilidad. Sugiere que, con suficiente estandarización, suficientes procesos y suficiente aplicación de buenas prácticas, los resultados pueden volverse confiables. Si se definen los elementos de entrada con suficiente claridad y se restringe el proceso lo suficiente, debería ser posible obtener resultados similares una y otra vez.

Esta lógica funciona notablemente bien cuando se fabrican objetos físicos.

No funciona igual de bien cuando se construye software.

Sin embargo, gran parte de la forma en que el software se planifica, se gestiona, se estima y se evalúa asume que se comporta como un proceso industrial que simplemente aún no ha sido optimizado lo suficiente. Que el problema es de madurez. Que si los equipos adoptaran el marco adecuado, siguieran la metodología correcta o se adhirieran con mayor rigor a los estándares apropiados, la incertidumbre eventualmente desaparecería.

Después de suficientes años dentro de proyectos reales de software, esa creencia se vuelve difícil de sostener.

No porque los equipos sean incompetentes. No porque las herramientas sean insuficientes. Y no porque las personas resistan la disciplina. Sino porque el desarrollo de software no es, ante todo, un problema industrial.

Es un problema de conocimiento y diseño, llevado adelante por personas, bajo condiciones de incertidumbre que no desaparecen simplemente porque preferiríamos que así fuera.

Cuando una fábrica produce defectos, asumimos que algo falló en el proceso. Cuando el software se comporta de maneras inesperadas, solemos asumir lo mismo. Pero esta analogía se rompe silenciosamente cuando los sistemas superan un tamaño trivial. Los sistemas de software no se ensamblan a partir de partes estables con comportamientos fijos. Se construyen a partir de abstracciones que evolucionan, de una comprensión parcial del dominio y de supuestos que revelan sus debilidades solo después de que el sistema ya está en uso.

Por eso dos equipos, utilizando el mismo lenguaje, el mismo framework, la misma metodología y el mismo proceso, pueden producir resultados radicalmente distintos. No porque uno haya seguido las reglas y el otro no, sino porque la actividad central no es la ejecución mecánica. Es la interpretación y la continua toma de decisiones.

Tratar el desarrollo de software como un problema industrial conduce a un conjunto predecible de respuestas. Redoblamos los procesos. Agregamos controles. Exigimos estimaciones más precisas cada vez más temprano. Intentamos congelar los requisitos. Priorizamos el cumplimiento por sobre la comprensión. Y cuando la realidad se niega a cooperar, culpamos a la ejecución en lugar de cuestionar el modelo.

Lo que muchas veces queda sin examinar es si el deseo de previsibilidad realmente se alinea con la naturaleza del trabajo.

El software no se limita a implementar requisitos; expone malentendidos sobre ellos. No solo codifica diseños; pone a prueba sus supuestos. Todo sistema no trivial enseña a quienes lo crean algo que no sabían al comienzo. Ese aprendizaje no es un fallo de la planificación. Es el trabajo mismo.

Aquí es donde comienzan a hacerse visibles los límites del enfoque industrial. Trata el aprendizaje como desviación, el cambio como inestabilidad y la incertidumbre como algo que debe eliminarse en lugar de gestionarse.

Nada de esto implica que el desarrollo de software sea caótico, desestructurado o puramente creativo en un sentido romántico. Hay lógica, rigor y disciplina involucrados—muchas veces en gran medida. Pero la disciplina, en este contexto, no proviene de fingir que el trabajo es predecible. Proviene de reconocer dónde no lo es y de diseñar prácticas capaces de absorber esa realidad sin romperse.

Muchas de las frustraciones que las personas experimentan en proyectos de software no se deben a la falta de procesos, sino a una desalineación entre el proceso y la naturaleza del trabajo. Cuanto más rígidamente se diseña un sistema para imponer certeza, más frágil se vuelve cuando esa certeza no se materializa.

Visto de esta manera, problemas recurrentes como estimaciones incumplidas, descubrimientos tardíos, reescrituras, refactorizaciones y rediseños dejan de ser misteriosos. No son señales de inmadurez en el campo. Son síntomas de tratar una actividad exploratoria y fuertemente orientada al diseño como si fuera una línea de producción.

El desarrollo de software no está tensionado porque no haya logrado volverse lo suficientemente industrial.

Está tensionado porque seguimos exigiéndole que se comporte como algo que no es.