27 enero 2007
¿Por qué programar está desprestigiado?
Las universidades menosprecian la programación
Existen centros que pueden enseñar a alguien los fundamentos básicos de la programación en unos pocos meses.
Recalco lo de básicos, porque se tardan años en adquirir la experiencia necesaria para poder escribir correctamente un programa medianamente grande y complejo.
Si sólo enseñaran a programar, las universidades se verían en igualdad de condiciones con los centros de menor nivel. O eso creen…
Lo cierto es que en las universidades (en general) no hay mucha gente que sepa programar. Me refiero a que hayan estado involucrados en programas grandes (del millón de líneas para arriba). Así que la mayoría de los profesores enseñan lo que saben: o sea, mucho de otras cosas que no son programar.
Lo mismo pasa con otras áreas, te calzan mamotretos de álgebra relacional, porque, en realidad no tienen mucha idea de Oracle.
Lo fácil llegado este punto, es menospreciar la programación como algo secundario, para no estar en inferioridad de condiciones con los centros que sólo enseñan a programar.
Aquí programa cualquiera
Ir a clase y tener un título no es más que un simple barniz. Hasta que no te las ves y te las deseas desarrollando y manteniendo una aplicación compleja no sabes en realidad nada de nada.
Pero a cualquiera le llaman “programador”.
Lo mismo que si te hubiesen puesto 100 horas en el Flight Simulator para luego darte los mandos de un Airbus.
Creo que deberíamos dejar de usar la palabra “programador”, está tan denostada como lo estaba en su día el “Departamento de Personal”. Deberíamos inventar algo nuevo como “Artista del Software” eso me gusta más.
Los analistas no tienen que producir resultados tan cuantitativamente medibles
Cuando se escribe un programa, o funciona, o falla. En desarrollo no existe tal cosa como un 99% bien. Si te dejaste comentada una inocente línea de código y como resultado el programa se cuelga en un punto, o hay un agujero de seguridad, estás muerto.
Esto es uno de los mejores consejos que da Dilbert: nunca aceptes un trabajo cuyo trabajo sea cuantitativamente medible.
La semana pasada me pasaron un PowerPoint con una “spec” de una analista. En la pantalla de inicio faltaba el botón de login. Un “fallito trivial” ¿no? A fin de cuentas el usuario siempre puede logarse pulsando simplemente Enter (si el programador lo implementa). Ahora ponte a programar y que se te olvide el mismo botón de login, verás qué risa…
Los analistas están más próximos al cliente
Por consiguiente, lo que dice el analista va a misa, y lo que dice el programador no va (normalmente) a ninguna parte.
Pero hay cosas que no se comprenden realmente hasta que no te pones a programarlas.
Nunca en toda mi vida he leído una especificación que explique todos los entresijos y sutilezas de un programa. Y eso es normal porque ¡la especificación sería tan larga como el programa!
Por tanto hay que entender que el trabajo del analista es siempre algo intrínsecamente incompleto, que debe ser corregido y ampliado por el programador, lo mismo que el aparejador y el jefe de obra completan todos los detalles omitidos en los planos del arquitecto.
Absurda asociación entre “cuello blanco” y “cuello azul”
A veces parece como si los elevados analistas fuesen los mirlos blancos de la corporación, en comparación con los feos y huraños programadores. Cuando en realidad, hacer un trabajo descriptivo es normalmente mucho más sencillo que encontrar la solución a los problemas descritos. Si yo tuviera que escoger, mandaría a mis recursos humanos más capaces a usar el compilador, y el resto a usar el Word, por una política de minimización de daños: los desastres que se pueden causar usando mal el Word son mucho menores que los que se pueden causar usando mal el compilador.
