Si nos fijamos en cualquier actividad, proceso o disciplina, desde lo lejano parece simple. Los gerentes sin experiencia en el desarrollo piensan que lo que hacen los programadores es sencillo, y los programadores sin experiencia en administración piensan lo mismo sobre lo que hacen los gerentes.
La programación es algo que algunas personas hacen, por algún tiempo. Y la parte difícil –pensar– es la menos visible y la menos apreciada por los no iniciados. Durante décadas ha habido muchos intentos de quitar la necesidad de esta habilidad cognoscitiva. Uno de los primeros y más memorables es el esfuerzo de Grace Hopper por hacer los lenguajes de programación menos crípticos; algunos predijeron que quitaría la necesidad de programadores especializados. El resultado (COBOL) ha contribuido a los ingresos de muchos programadores especializados durante las décadas siguientes.
La visión persistente de que el desarrollo de software se puede simplificar al quitar la programación es, para el programador que entiende de lo que se trata, obviamente ingenua. Sin embargo, el proceso mental que conduce a este error es parte de la naturaleza humana y los programadores son tan propensos a realizarlo como cualquiera.
En cualquier proyecto hay muchas cosas en las que un programador no está involucrado activamente: obtener requerimientos de los usuarios, conseguir la aprobación del presupuesto, configurar el servidor de producción, implementar la aplicación a los ambientes de QA y producción, migrar el negocio desde los viejos procesos o programas, etc.
Cuando no estás involucrado activamente en estas cosas existe una tendencia inconsciente a asumir que son sencillas y que las cosas suceden “por arte de magia”. Mientras la magia siga ocurriendo todo está bien. Pero cuando –esto sucede “cuando” y no “si”– la magia se detiene, el proyecto está en problemas.
He conocido proyectos que pierden semanas de desarrollo porque nadie entiende cómo se confía en la versión “correcta” de un DLL que está siendo cargado. Cuando las cosas empezaron a fallar intermitentemente los miembros del equipo miraban a cualquier otra parte antes de que alguien notara que una versión “equivocada” del DLL había sido cargada.
Otro departamento estaba funcionando sin problemas, proyectos enviados a tiempo, no más sesiones de depuración nocturna, no arreglos de emergencia. Tan tranquilamente, de hecho, que la Alta Gerencia decidió que las cosas “corrían por sí mismas” y lo podría hacer sin el administrador de proyectos. En los siguientes seis meses los proyectos en el departamento se veían tan bien como en el resto de la organización: retrasados, con errores y siendo parchados continuamente.
No tienes que entender toda la magia que sucede en tu proyecto, pero no está de más entender algo de ella, o apreciar a aquellos que entienden las partes que tú no.
Más importante, asegúrate de que cuando la magia se detenga, pueda ser iniciada de nuevo.
Traducción: Espartaco Palma