Esta es una respuesta a : http://equipro.blogspot.com/2007/11/ingenieros-informticos-quienes.html

El post refleja una cierta frustración, la cual por cierto no niego pues yo mismo la he vivido. Pero nuestras conclusiones son muy diferentes.

Cuando uno inicia en este mundo del software se entusiasma (desde el punto de vista pecunario) pensando en Gates, Allen, Ellison, Torvald, Jobs y todos los millonarios que parecen decirte al oido "aqui hay mucho dinero para ti". Hasta Stallman hace mucho que tiene una billetera abultada y no hay nada de malo en ello.

Sin embargo los escenarios donde un desarrollador común trabaja y el escenario de trabajar en un corporativo son muy diferentes. En un corporativo como Apple, Microsoft, Oracle, IBM o Google ya existen soluciones que se venden y uno se integra al equipo de trabajo para mejorarlas. Todo es grande, confortable y profesional, servidores serios con sistemas costosos en oficinas padrísimas donde hay mesas de billar y consolas para jugar. Hay una metodologías de desarrollo y fórmulas del MIT para calcular tiempos de programación. Pero ese escenario es muy pequeño y practicamente sólo implementado en algunos lugares del primer mundo.

La gran mayoría de los desarrolladores somos (o fuimos) el clásico desarrollador "gutierritos" que sale y entra de un proyecto. En este mundo todo es precario, informal, amateur. Este mundo funciona de la siguiente manera, un "líder de proyecto/vendedor" (LDPV) convence a una empresa o institución del gobierno para hacer un desarrollo, muchas veces la empresa paga un análisis que se paga a la consultoría y toma alrededor de un mes. En realidad este (LDPV) no tiene idea de como se planea una aplicación, para eso tendría que ser arquitecto de software y este wey apenas puede hacer el "Hello World" en Java. Sin embargo el RoseSoft (pirata) que trae en la laptop tiene un montón de Wizards que imprimen un montón de diagramas y eso es lo que entrega como "análisis". Ese análisis en realidad nadie lo lee pero los diagramas intimidan al director de sistemas de la empresa y da el visto bueno para iniciar el proyecto.

Luego el LDPV busca en las bolsas de trabajo dos programadores con "amplia experiencia", "orientado a resultados" y "acostumbrados a trabajar bajo presión" y hace entrevistas porque el proyecto debe completarse en 60 días, ¿porqué 60 días? porque hasta ahí alcanzan los 60,000 pesos del presupuesto del proyecto. Luego de contratar a dos recién egresados por 800 dólares al mes el proyecto inicia y el primer día el LDPV les da una plática de 90 minutos a los dos recién egresados (RE) y con eso espera que ellos "entiendan" la aplicación, además les dice que si tienen dudas "consulten los diagramas que imprimí"

De modo que ese primer día en la tarde los dos RE empiezan a tirar código, nótese que hasta este momento no hay ningún diseño de aplicación. Por supuesto para poder codificar un proceso uno tiene que entender la mecánica y los actores que participan y como los dos RE no entienden nada sólo hacen formularios para hacer CRUDs y cuando diez días después por fin captan una parte del sistema tienen que reescribir varios archivos lo que produce el "burn out" o "estar quemado" y los RE se desmotivan y al mes de iniciado el proyecto empiezan a ver las bolsas de trabajo para buscar otra cosa. A estas alturas el LDPV está histérico pues no se lleva ni el 30% del proyecto y ya falta un mes para que el dinero se acabe.

Va con la empresa y renegocia una extensión de un mes pero mientras sale esa factura paga él el sueldo de los RE y no cobra nada una quincena. A los tres meses la aplicación parece un prototipo, hace algunas cosas pero no hay validación, ni sanitización, ni documentación pero eso es lo que se entrega y luego de intentar usarlo la empresa se da cuenta que tiene tantos bugs que no se puede usar y entonces el departamento interno de sistemas intenta completarlo pero como no entiende nada del código espaghetti de los dos RE deciden iniciar de cero con perl y luego de un año el programa funciona.

Esto lo he visto tantas veces que ya me aburre.

Todo esto debería suceder de una manera muy diferente:

1) El jefe de sistemas de una empresa tiene la mentalidad no sólo de sustentar la red y los servidores sino de involucrarse activamente en el aumento de la productividad de la empresa.

2) ¿Qué es la productividad? la capacidad de solventar de manera adecuada un mayor volumen de trabajo con los mismos recursos humanos. ¿Qué aumenta la productividad? la automatización de los procesos, ¿cómo se automatiza un proceso? Con tecnología, la mayoría de las veces con una aplicación de software que haga todo más sencillo, distribuido y hasta ameno. Todo en el primer mundo está automatizado, desde las hamburguesas hasta los misiles.

3) Entonces el jefe de sistemas calcula que automatizando la comunicación entre almacenes y los encargados de
importación ahorraría 8 horas hombre al mes con un programa de software. Si hay 30 personas que usarían el programa serían 2880 horas al año, 8640 horas en tres años, si los empleados en promedio ganan 56 pesos la hora en dinero serían $483,840.00 para la empresa. Pero no sólo sería el dinero porque con este nuevo programa habría sucursales mejor comunicadas y reportes mas detallados que quizas ahora ni existan. El software bien diseñado posee un enorme valor agregado.

4) Entonces hay un presupuesto de 250 mil pesos para un proyecto pagándoles a tres personas por medio año para diseñar y hacer el desarrollo.

Pero esto es una fantasia mia. La realidad es otra. Ahora bien, volviendo a la realidad ¿cómo escapar de esta dinámica que destruye autoestimas y crea dudas vocacionales? Debe haber alguna porque a mi me gusta crear software, me gusta pensar en clases, me gusta ver como mi programa va quedando cada vez mejor semana tras semana y me gusta sentir vergüenza de mi código de hace seis meses porque desde entonces he aprendido dos o tres trucos nuevos y también porque diseñar software se parece a subir una montaña: mientras más subes mejor es la vista y nunca quieres dejar de subir.

Hay varias maneras de ser desarrollador y no suicidarse en le intento, una de ellas sería entrar a una empresa de las que hablamos arriba: Google, IBM, Novell. Otra sería entrar al gobierno donde las exigencias son menores, el pago seguro y uno tiene más libertad de crear. El problema de trabajar en el gobierno es que (en mi experiencia) generalmente ahi caen los programadores más mediocres (incluyendo a tu jefe) y en general todo el ambiente es gris y tedioso. Recuerdo en una oficina del SAT donde la diversión era pararse corriendo a la ventana para ver salir a las secretarías del edificio de enfrente, y si no te parabas te decían "de lo que te perdiste wey!". Luego de un mes sólo quería salir de ahí.

Creo que la mejor manera de salir de eso es intentar ser como IBM, Novell o Google, es decir crear un producto que las empresas compren, no hablo de licencias sino de servicios, el software funciona, hace cosas que sería imposible hacer "a mano" y hay gente que no solo lo quiere: lo necesita y si no te lo compra a ti lo comprará a alguien más. Lo que hay que preguntarse es "¿Cuál software me apasiona lo suficiente como para dedicarle años?", yo intenté hacer un programa de ventas con facturas e inventarios pero la verdad todo eso me da tanta hueva que lo abandoné. El software educativo me encanta porque no sólo es software, tiene que ver con la mente de quien lo usa y por eso ahora trato de hacer un producto relacionado. El problema es que me sobreestime (suele sucederme) y lo diseñe muy grande y programarlo ha consumido más meses de los que pensaba pero la versión 0.1 estará por estos días ya liberada ;-)


Para concluir, hay un par de líneas que me confunden del post:

"No conozco otra profesión donde un profesional de las TI, como es un ingeniero informático pueda mirar a un cliente para decirle que no sabe porqué el sistema informático o un determinado programa no funcionan adecuadamente".

Eso me parece imperdonable, tu obligación es saber porque no funciona un determinado software, si se puede o vale la pena arreglarlo ese es otro cantar pero debes conocer tu profesión.

"Sin garantías en la calidad del resultado, o en el buen funcionamiento del mismo, tampoco hay respeto"

Mmmm, el cliente paga dinero y debe tener alguna garantía, como sucede en cualquier transacción económica. Claro que deben darse además algunas condiciones para ambos, cliente y servidor.