Devolver el orgullo al nombre de "programador" para solucionar el déficit de programadores

miércoles, 30 de julio de 2008

Hace unas semanas atrás discutíamos en el foro de mi facultad acerca de las diferencias entre los títulos de "programador" y "desarrollador". En este foro comentaban maestros y alumnos acerca de esta distinción, entre los comentarios más frecuentes se encontraban que el programador simplemente codifica y el 'desarrollador' analiza, planifica, codifica y muchas otras cosas más. Esto me hace recordar la etapa del desarrollo de software de manera artesanal que tomó fuerza a finales de los 60's. Sin embargo, desde ese entonces, el desarrollo de software ha avanzado, aunque a pasos lentos que actualmente aun se sigue produciendo software a manos de técnicos y programadores artesanos.

Enrique Dans menciona el problema de la desvalorización de los programadores en su primer artículo referente al tema en Libertad Digital:

...el programador es considerado una especie de "obrero especializado", y sometido a una economía de salarios bajos, inestabilidad laboral, elevada rotación y fuerte incidencia de estrés.
Esta es la consideración que se tiene, cuando debería ser otra muy distinta.
Ser programador es un trabajo creativo, un papel indispensable en la economía de hoy que merece muchísimo respeto y que genera un elevado valor. Sin embargo, ¿dónde están los programadores? ¿Por qué no salen de las universidades, dispuestos a convertir esa hiperabundancia actual de ideas en código y a participar en esa revolución consistente en crear tantas actividades en el seno de la red? ¿Qué profesionales están generando las carreras de Informática o algunas Ingenierías, y por qué tienden a rechazar la idea de programar como si fuera un estigma o algo típico de obreros especializados?

En España, a este lado del túnel, se necesitan programadores. Y los programadores necesitan una reivindicación urgente de su profesión, que recupere el legítimo orgullo de quien crea, de quien desarrolla, de quien se responsabiliza de un todo, de quien se enamora de un proyecto y no se limita a ser un obrero en el mismo, sino un verdadero arquitecto. Se buscan programadores con orgullo y capacidad para serlo. Pero por lo que se ve, habrá que mirar debajo de las piedras.


Y México no escapa de este problema. Sumado a esto está la deserción de los estudiantes en las carreras de informática y sistemas computacionales, y las matrículas se reducen cada vez más. Como señala Emilio Osorio en la revista Software Gurú:
El desarrollo de software atrae cada vez a menos jóvenes, y muchos de estos cambian de carrera antes de graduarse... Mucho se ha hablado de las causas de esta crisis, algunos culpan a la falta de profesionalismo y experiencia real de los maestros, otros, al mal ejemplo que damos los que somos parte de esta industria: nuestras jornadas de trabajo, niveles de estrés y costumbres geeks no son muy atractivas para jóvenes de 18 años que sólo se quieren divertir.
Leyendo más acerca de porqué se ha infravalorado el título de programador he encontrado varias perspectivas. Una de estas alude a la poca importancia que le dan las empresas y casas de software a los programadores, viendo en ellos a simples máquinas mecánicas a los cuales se les dan unos planos de la construcción de un determinado software y produce código que hace lo que el analista le ha planteado. Tal como lo menciona Enrique Dans hablando acerca de la concepción común de un programador en la publicación de altianews de septiembre de 2007:
...mientras en nuestro entorno, la palabra “programador” define un trabajo de baja cualificación, casi mecánico, asociado al traslado de las especificaciones de un analista en líneas de código ejecutables por un ordenador, lo que las empresas necesitan no es eso, sino una noción más moderna del término: la de un profesional mucho más autosuficiente, con conocimientos de ingeniería del software, teoría de la computación, matemática, algorítmica e incluso nociones de estrategia de negocio, que desempeña una actividad de elevada cualificación y responsabilidad. Enrique Dans: “Programadores: cuando falla la base”
Otra de las rezones se da en el artículo mencionado son las instituciones académicas, ya que los profesores influyen en gran manera en los alumnos a despreciar el puesto de programador.
...mientras los profesores en las Escuelas Técnicas, insistiendo en el error y manifestando una clara incapacidad para formar a ese tipo de profesionales, se afanan en convencer a sus alumnos para que huyan de la programación como de la peste.
Ricardo Galli, creador de Menéame, también menciona este problema en su antiguo blog:

...más del 70% de los alumnos de las ingenierías informáticas están completamente desmotivados y/o desinteresados por su carrera, especialmente la programación.

Quizás se debe a que durante muchos años de habló que era la “carrera del futuro”. Quizás también se deba a que ser un buen programador es cada vez más difícil y que obliga a un esfuerzo intelectual muy importante. Quizás también se deba a la “falta de perspectiva” de cómo es la profesión en los centros importantes: mucho esfuerzo pero a la vez mucha autoconfianza y coraje.

Seguramente los profesores tenemos parte de esas culpas. Conozco a muchos que piensan que un “ingeniero no necesita programar”, conozco también a muchos que ya no se acuerdan de cómo se programa. Pero también conozco a muchos profesores que son unos monstruos programando y dando clases, pero esos justamente son los más “odiados” o ignorados por esa gran mayoría de alumnos que sólo desean aprobar las asignaturas de la forma más sencilla, segura y sin liarse demasiado el coco. Así muchas veces terminan festejando al profesor que les cuenta batallitas por que así sí que aprenden “cosas prácticas” y útiles.

Pero sí, los profesores –incluido yo–, somos parte importante del problema

Aunque los artículos hablan acerca del problema en España, en México he visto el mismo problema en mi propia universidad, tal vez no de forma tan extrema, pero si intentando convencer a los estudiantes de buscar un "nivel más alto" como lo es el Ingeniero de Software o "Desarrollador", los cuales según la concepción generalizada, programan menos y están más arriba en la escala jerárquica empresarial.

Otro problema son los sueldos de los programadores, que como ya he mencionado antes, las empresas desvalorizan la labor del programador, así que pagan bajos sueldos. Sin embargo, a estos mismos les urgen programadores.
...la empresa cree que necesita programadores a la vieja usanza, y pretende pagar dos duros a quienes son, en realidad, profesionales capaces de destilar ideas en código y convertir el proyecto en realidad. Y ante semejante estímulo, los profesionales simplemente rehuyen la confrontación y buscan otras metas. Y es que pasar de obrero a arquitecto no sólo requiere un nivel superior de cualificación. Supone, además, que existan incentivos para ello.
A diferencia, otros se arriesgan a opinar que no es que falten programadores, los hay, lo que hace falta es motivación. Se refieren a la motivación del programador, pero esto no es sino un reflejo de lo que tales programadores han aprendido durante su carrera y de la manera en la que ven el puesto de programador. Aunque lo que menciona Jordi Abad en su blog es muy cierto:
...el trabajo de programador está asociado a la base de la estructura jerárquica de una empresa. Esto implica: bajos salarios, mala reputación y comerse muchos marrones de las capas superiores de la pirámide. Es un trabajo muy poco agradecido. A pesar de ello se trata de un trabajo necesario e imprescindible por parte de una empresa que se dedica a programar software.
Ricardo Galli propone además sus propios puntos de vista referentes a las causas que generan estos problemas:
  1. Las empresas grandes que pueden pagar bien a los buenos programadores tienen obsoletas estructuras piramidales que lo único que logran es quemar a los buenos programadores en menos de un año.

  2. Las puntas de esas pirámides suelen ser aquellos que no quieren saber nada de programación y se dedican a ascender, delegando toda responsabilidad a los “analistas senior”, que a su vez delegan y culpan a los “analistas junior” y así abajo en la cadena hasta llegar al buen programador que está a punto de dejar porque ya está quemado.

  3. Empresas grandes que venden carne de ingenieros al kilogramo pagando salarios de becarios y haciendo verdaderas chapuzas porque al final nadie es el responsable. ¿Alguien recuerda al web del Congreso y tantas otras administraciones por ejemplo?.

  4. Las administraciones y grandes empresas, como tienen problemas en mantener a sus buenos programadores (por 1 y 2), contratan ingenieros al kilogramo a las que se dedican a venderlos.

  5. Las empresas pequeñas buscan programadores “básicos”, que sepan un poco de Visual Basic, con suerte Java, y montón de otras cosas como instalar MS Office o “un servidor Linux”.

  6. Muy pocas empresas tienen asumido que sus programadores requieren un entrenamiento inicial especializado en lo que va a hacer –que no puede brindarle ninguna universidad o ciclo formativo– y que esos programadores también necesitan una formación continua –vía cursos específicos o tiempo y tranquilidad necesario para trabajar en proyectos con técnicas y métodos más modernos y diferentes–.

  7. El problema de la disfunción metacognitiva, muy generalizada entre los informáticos.

  8. Existe una especie de presión a las universidades para que “formen profesionales adecuados al mercado del trabajo”. Ese mensaje ha calado profundo en muchos profesores, pero aún más entre los alumnos que exigen que se les enseñe Java desde primero –y nada más que Java– porque es lo que demanda el “mercado laboral” y que hace que pasen olímpicamente de otras asignaturas que marcan diferencias, por ejemplo álgebras o conceptos complejos de la “ciencia de la computación”.

  9. Quizás por #6, muy pocos programadores dedican tiempo a leer, aprender y navegar mucho por Internet, que se ha convertido en la fuente principal y fundamental para aprender las nuevas técnicas, tendencias y formas de llevar adelante proyectos. Existe una especie de sentimiento generalizado –que todavía no puedo comprender, con lo guapa y divertida que es la informática y programación– de “en mi poco tiempo libre me olvido del ordenador”…

Como bien lo ha dicho, he visto mucho de esto con mis compañeros de clases y colegas de trabajo. A muy pocos de ellos les llama verdaderamente la programación y muy pocos leen y se mantienen actualizados. En la región sur de México existen muy pocas empresas especializadas en desarrollo de software, y los que están, ofrecen bajos salarios y no tienen mejores prácticas de desarrollo. A esto también me quiero referir, a la centralización de las empresas en el Edo. de México, Monterrey y Guadalajara. Esto provoca que muchos jóvenes con deseos de superación y con grandes capacidades pierdan de la oportunidad de poder desarrollarse profesionalmente ya que vivien en otros estados.

También quiero citar a una publicación de
BusinessWeek en donde señala una importante consultora acerca del déficit de talentos en la India para el 2010.
Building showpiece campuses the size of many U.S. colleges is just one way big Indian employers are battling to hold on to budding engineers, designers, and finance specialists... Today, companies face high turnover, escalating salaries, and shortages of qualified workers and managers. Less than a quarter of companies surveyed in 2006 in India by McKinsey & Co. said they were meeting recruiting needs. By 2010, McKinsey predicts, India will face a shortfall of 500,000 staff capable of doing work for multinationals.
Con este problema en puertas, las empresas Indias están necesitando trabajadores para las multinacionales y atrayendo mano de obra de los países vecinos y de América Latina, con lo que deberemos afrontar más rápidamente este problema. Menciono esto porque, debido a los sueldos de un programador en México en comparativa con otros países, parece ser que hace falta concientizar de la importancia del programador, el cuál es la parte más activa e importante de una empresa. Como bien dos programadores crearon Google, Microsoft y Apple. En salarios, los programadores mexicanos se encuentran en el lugar 20 de los países con mejores sueldos (tablas de salarios en México), justo debajo de España y Corea, ocupando Hong Kong y Suiza los pirmeros puestos.

Parte de la solución reside en el cambio de mentalidad del profesorado y del gobierno. Por ejemplo, en Argentina, según el periódico La Gaceta, se está diseñando un programa de becas para las carreras de TI y así poder incrementar el número de matrículas y reducir las bajas para lograr afrontar los nuevos programas económicos del país.
El flamante programa contempla la entrega de 6700 becas, con una inversión total de 52 millones de pesos para el período 2009-2013 que serán destinadas a jóvenes de todo el país que estudien en universidades nacionales.
Las becas serán destinadas a quienes estudien las carreras de Ingeniería Electrónica, Ingeniería en Telecomunicaciones, Ingeniería en Computación, Ingeniería Informática, Ingeniería en Sistemas de Información, Licenciatura en Informática, Licenciatura en Análisis de Sistemas, en Sistemas y en Ciencias de la Computación.
Cambiando la mentalidad de los empresarios (los de más alto nivel jerárquico) , la academia, y estrechando la brecha academia-sector productivo es como se logrará incrementar nuevamente las matrículas en las carreras de TI y mejorar la economía nacional con base en el conocimiento.

Para finalizar quiero recomendar y citar una
entrevista al Dr. Carlos Montes de Oca en Software Gurú:
...el dueño de una fábrica de coches sale a las 6 de la tarde, y ahí tiene su fábrica, con su valor intacto; puede venderla y recuperar su inversión. En cambio, el dueño de una fábrica de software, a las 8 de la noche que sus empleados ya se fueron a su casa, está descapitalizado. Lo único que tiene son escritorios y unas máquinas depreciadas.
No perdamos el orgullo de ser programadores, las empresas están cambiando a darnos mayor importancia porque nos necesitan. Y no pretendamos llamarnos Desarrolladores (Developers) solo porque la gente que no programa crea que es un nivel más alto.

Creando un User Control con VB.NET 2005

domingo, 6 de julio de 2008

Actualmente estoy mejorando una aplicación de escritorio que hice para los chicos de las materias de Contabilidad I y II de las carreras de Contaduaría y Administración. Esta aplicación usa una ventana para crear asientos de diario, creando y quitando registros, cuentas y asientos. Al final, con un solo clic generan los esquemas de mayor, balanza de comprobación, balance general y rayado diario y se exportan a Excel. Pues durante el upgrade me encontré nuevamente con la dificultad de dar al usuario la facilidad de agregar y quitar registros visualmente, porque en la primera versión estuve modificando manualmente todos los tamaños y posiciones de decenas de controles que tenía en la ventana de trabajo. Lo que hice en esta segunda versión fue diseñar un control personalizado (User Control) llamado ControlAsiento.vb que contiene a otro User Control llamado ControlRegistro.vb, los cuales me facilitaron la vida.
Para este pequeño tutorial estaremos consider
ando Visual Studio 2005, usando VB.

¿Qué es un UserContr
ol y para qué sirve?
Un User Control no es más que una clase común .vb que también provee las referencias para poder trabajar con las clases dentro del espacio de nombres System.Windows.Forms, a diferencia de los Class Library, que es buen tema para otro post. Con los User Control podemos crear controles más complejos o avanzados derivados de los controles que ya nos proporciona el IDE, tal como veremos más adelante con un ejemplo. Aquí les muestro paso a paso cómo crearlos y usarlos. En el siguiente ejemplo haremos una pequeñísima parte de lo que tuve que hacer para la aplicación que estaba desarrollando, esto es poder generar en tiempo de ejecución nuevas instanacias de los controles que vamos a diseñar y programar.



¿Cómo se hace?

1. Después de abrir el IDE de Microsoft Visual Studio 2005 y empleando el lenguaje Visual Basic, creamos una nueva Aplicación de Windows como comunmente. Yo he llamado "Ejemplo1" a mi proyecto.




2. Cuando se crea nuestro proyecto nos presenta un nuevo formulario vació para comenzar a trabajar. Pues bien, lo que haremos será agregar un
User Control a nuestra aplicación. En el explorador de soluciones (Solution Explorer) desplegaremos con un clic derecho sobre el nombre de nuestra aplicación una ventana emergente donde seleccionaremos la opción Add > User Control.


3. Nota que al abrir la ventana de diálogo está seleccionado el tipo de control User Control. Le daremos un nombre a nuestro nuevo control, en nuestro caso será ControlRegistro.vb. Este será el control de más bajo nivel, es decir, el último que solo contendrá a controles predefinidos por Visual Studio.





4. Podremos ver un nuevo lienzo que no contiene barras de título ni bordes, en el cual comenzaremos a diseñar nuestro control.





5. Para el ejemplo solo programaremos un botón en cada
User Control, aunque esto vendrá después de haber diseñado todo lo demás.






6. Habiendo temrinado con el diseño de ControlRegistro, crearemos
entonces ControlAsiento, que contendrá una cantidad indeterminada de registros. Para esto procederemos de la misma forma en la que creamos ControlRegistro. En el explorador de la solución (Solution Explorer) desplegaremos con un clic derecho sobre el nombre de nuestra aplicación una ventana emergente en la que seleccionaremos la opción Add > User Control y lo nombramos ControlAsiento.vb, y procederemos a hacer el diseño de la interfaz. Para esta interfaz necesitaremos agregar al menos un control del tipo ControlRegistro que hemos creado, sin embargo no podremos acceder a este control en la Caja de herramientas mientras no hayamos reconstruido la aplicación para que las modificaciones en ControlRegistro tomen efecto en los lugares en los cuales se haya usado. Hasta ahora no lo hemos usado y para esto también necesitaremos reconstruir. Seleccionamos en el menú principal Build > Rebuild Ejemplo1.





7. ControlAsiento tendrá el siguiente aspecto.








8. Al temrinar el diseño debemos reconstruir nuevamente la aplicación de la forma que ya hemos mencionado, entonces podremos ver nuestro control en la caja de herramientas.




9. Finalmente tendremos el siguiente aspecto en nuestro formulario principal Form1.












Pues bien, ya hemos diseñado nuestros controles, solo falta darles vida, para esto pondremos fragmentos de código en ControlRegistro, ControlAsiento y Form1.

*** Form1 ***

Public Class Form1
Dim asiento As ControlAsiento

Sub crearAsiento(ByVal asientoAnterior As ControlAsiento)
' Calculamos la posición del nuevo asiento a partir del asiento anterior, el cual hizo la llamada
' y agregamos el nuevo ControlAsiento al formulario
asiento = New ControlAsiento
asiento.Location = New Point(asientoAnterior.Location.X, asientoAnterior.Location.X + asientoAnterior.Height + 5)
asiento.Label1.Text = asientoAnterior.Label1.Text + 1
With GroupBox1
.Size = New Size(.Width, .Height + asientoAnterior.Height + 5)
.Controls.Add(asiento)
End With
End Sub
End Class

*** ControlAsiento ***
Public Class ControlAsiento
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
' Llamamos al método crearAsiento() del formulario que contiene a este asiento.
CType(Me.FindForm, Form1).crearAsiento(Me)
End Sub

Private Sub ControlAsiento_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
' Es solo un ejemplo de cómo se puede agregar un manejador de eventos a un control,
' ya que en micaso he usado mucho este tipo de manejadores al momento de crear controles dinámicamente
' y tener varias formas de acceder a un mismo evento
AddHandler Button1.Click, AddressOf Button1_Click
End Sub

Sub crearRegistro(ByVal sender As ControlRegistro)
Dim reg As New ControlRegistro
' La separación que agregaremos a la posición del registro y demás controles, y la cantidad que agregaremos al tamaño del GroupBox1
Dim y = sender.Height + 3
reg.Location = New Point(sender.Location.X, sender.Location.Y + y)
' Bajamos también la caja de texto multilinea y los botones del ControlAsiento
redaccion.Location = New Point(redaccion.Location.X, redaccion.Location.Y + y)
Button1.Location = New Point(Button1.Location.X, Button1.Location.Y + y)
Button2.Location = New Point(Button2.Location.X, Button2.Location.Y + y)
' Con Me.ParentForm obtenemos el formuylario que contiene a este control y lo convertimos al tipo Form1, que es la clase que tenemos
With CType(Me.ParentForm, Form1).GroupBox1
.Size = New Size(.Width, .Height + y)
End With
' Agregamos el nuevo control al contenedor correspondiente, en este caso ControlAsiento que contiene al botón que hemos presionado
Me.Controls.Add(reg)
End Sub
End Class

*** ControlRegistro ***
Public Class ControlRegistro
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
' Obtenemos el ControlAsiento que contiene a este ControlRegistro
Dim asiento As ControlAsiento = Me.Parent
' Llamamos a la subrutina que hicimos en ControlAsiento para generar nuevos registros
asiento.crearRegistro(Me)
End Sub
End Class
He resaltado en negritas algunas funciones que son de mucha utilidad para poder acceder a los controles que contienen a nuestros
User Control, y así poder usar propiedades y métodos de estos.
Lo que el código anterior hará será generar un nuevo asiento debajo del asiento que contiene al botón '+' en donde se hizo clic. Y generará un nuevo registro debajo del registro en el que se encuentra el botón '+' en el que se hizo clic.


Como hemos visto, podemos usar
User Control no solo para aquellos casos en los que tendremos que usar un control complejo en varias partes de nuestra aplicación, sino también en casos en los que sea necesario crear dinámicamente algunos controles complejos sin necesidad de rompernos tanto la cabeza, como a mí me pasó.
Espero que les sirva de algo este breve tutorial.