Las relaciones de poder en el desarrollo de software
Desde que entré al mundo del desarrollo de software, mi mirada de politólogo siempre me ha acompañado. Lo aprendido nunca se olvida. Y algo que me ha llamado la atención en estos tres años es cómo se configuran las relaciones de poder dentro de los equipos de desarrollo. No hablo solo de los programadores, sino de todos los actores que influyen en la creación de software.
Este no es un intento de queja ni un ataque a nadie en particular. Más bien, es una reflexión sobre ciertas dinámicas que, desde una perspectiva social, vale la pena analizar. Porque detrás del código, las metodologías ágiles y la inmediatez de las entregas, hay estructuras de poder que influyen en quién tiene voz, quién decide y quién se siente parte del proceso.
El purismo intelectual como barrera
En las ciencias sociales, el “purismo intelectual” es bien conocido. En el mundo académico, muchas veces se valora más el conocimiento teórico que la aplicación práctica. Pero en el desarrollo de software, donde prima la velocidad y la eficiencia, uno pensaría que este fenómeno no tendría tanto peso. Sin embargo, no es así.
Existe una barrera invisible entre quienes tienen una formación profunda en ingeniería y quienes llegaron al desarrollo desde otros caminos. No es un tema de títulos universitarios; de hecho, muchos de los más puristas no vienen de la academia, sino de años de experiencia autodidacta. La cuestión es que el conocimiento se usa, en ocasiones, como un símbolo de estatus más que como una herramienta para construir mejores productos.
Se defiende la teoría por encima de la práctica, el “clean code” como dogma inquebrantable, y el entendimiento profundo de los sistemas como el único camino legítimo para ser considerado un “buen desarrollador”. Pero la realidad es que, en la práctica, el desarrollo de software rara vez es un modelo perfecto. La mayoría de proyectos enfrentan restricciones de tiempo, pivotes inesperados y decisiones pragmáticas que desafían la idea de que solo hay una forma correcta de hacer las cosas.
Programar desde la caverna
Este purismo recuerda a la metáfora de la caverna de Platón: se cree que la única verdad es la que se conoce, y se rechaza cualquier otro enfoque. No es que el conocimiento profundo sea innecesario (todo lo contrario), pero aferrarse a él como única forma válida de desarrollo revela más miedo al cambio que verdadera maestría.
La computación cuántica, la inteligencia artificial, los modelos de lenguaje avanzados (LLMs)… Estamos en una época de cambios acelerados donde las herramientas evolucionan constantemente. Sin embargo, algunos sectores del desarrollo siguen atrapados en debates sobre si está bien o no usar ciertas herramientas sin entenderlas a fondo. Se exige un dominio absoluto de la teoría para legitimar su uso, como si no tuviéramos décadas de historia donde la tecnología ha avanzado gracias a la experimentación y la práctica, no solo a la teoría.
Dinámicas de cambio y colaboración
No se trata de decir que la teoría no importa ni que el desarrollo se convertirá en algo 100% automatizado. Pero sí vale la pena preguntarnos: ¿estamos valorando a las personas por su capacidad de crear, aprender y adaptarse, o por su adhesión a un estándar impuesto por una élite técnica?
Más allá de los egos intelectuales, el desarrollo de software es, sobre todo, un trabajo en equipo. La comunicación, la colaboración y la capacidad de construir juntos deberían pesar más que la cantidad de términos técnicos que alguien pueda recitar de memoria. La historia del software libre es prueba de lo que se puede lograr cuando el conocimiento se comparte en lugar de ser usado como una barrera de exclusión.
El desarrollo de software es, y siempre será, hecho por personas y para personas. Quizás es momento de poner ese principio en el centro de la conversación.