miércoles, 12 de marzo de 2008

Quien Mato al Ingeniero de Software ?

Este articulo es muy interesante y muestra la problemática real del desarrollo de software, la pregunta es todos deberían estudiar informática?

Robert Dewar, autor junto Edmond Schoenberg del artículo “¿Dónde están los Ingenieros de Software del mañana?” continuó la discusión al respecto en otra entrevista para Datamation. A continuación una traducción general con algunas opiniones de dicha entrevista:

Su argumento se resume así: los programas universitarios de ciencia de la computación no son lo suficientemente rigurosos, y no promueven la resolución de problemas y pensamiento en profundidad. En vez de eso, en un esfuerzo por aumentar el matriculado, los programas se enfocan en un currículo fácilmente accesible, y fallan en preparar a los estudiantes a competir con sus colegas internacionales.
Describe que su artículo fue malinterpretado en el punto en que comenta que la adopción de Java como primer lenguaje en los cursos ha llevado a ésta decadencia. Si bien Dewar entiende que las bibliotecas gráficas de Java permiten a los estudiantes crear software sin entender el código fuente por debajo, éste no es el problema principal.

“Mucho se trata de ‘hagamos ésto más divertido’. Sabes, ‘la matemática no es divertida, reduzcamos los requerimientos de matemáticas. Los algoritmos no son divertidos, deshagámonos de ellos. Ewww - bibliotecas gráficas son divertidas. Hagamos que la gente juegue con las bibliotecas. Y [olvidarse] todo éste asunto con ‘línea de comando’ - haremos que la gente use interfaces visuales lindas donde puedan apuntar y hacer clic y crear cosas gráficas llamativas y divertirse.”

Dewar menciona que su casilla de correo se llenó de respuestas positivas a su artículo, de estudiantes así como empleadores. Mucho lectores le han agradecido por hablar de una situación que creen necesario debe ser atendida, cuenta. Un email era de un IR que trabaja con un programador junior. El trabajador más viejo sugirió que el joven ingeniero chequeara el stack del núcleo para ver sobre un problema, pero desafortunadamente, “nunca había oído sobre un stack de núcleo”.

Desde el punto de vista de Dewar, la culpa es de las universidades que están deseperadas por compensar las bajas matriculaciones en programas de ciencia de la computación, aunque signifique destrozar los programas. Es conocido ampliamente que las matriculaciones han decrecido. Las causas principales: la caída de las punto com, y los encabezados constantes sobre outsourcing.
Responden a ésta baja en estudiantes del sector “atontando” los programas, esperando hacerlos más accesibles y populares. Lo que sea muy demandante o percibido como tedioso, se reemplaza con material simplificado que atraiga más enrolamientos. Obviamente como dice Dewar, ésto es contraproducente.

“Para mí, los números no son necesariamente la primera preocupación. La primer preocupación es que la gente obtenga una buena educación.”
Éstos estudiantes que fueron alimentados con material fácil no están preparados para competir globalmente.

Dice, uno de los pasos más contraproducentes que dieron las universidades fue adoptar Java como el lenguaje más usando en los cursos introductorios de programación, en un deseo de hacer la carrera más popular. Recuerda una discusión en la NYU hace varios años cuando decidieron cambiar el lenguaje introductorio de Pascal a Java. Pascal nunca había sido tan popular en la industria, cosa que no importaba; aprender Pascal tendía a promover prácticas de programación sólidas.
“Enseñaban Pascal porque parecía pedagógicamente la mejor opción”, dice Dewar.
El cambio a Java se hizo “puramente sobre la base de la demanda percibida de los estudiantes”. Para estar seguro, es un código popular para aplicaciones web y es relativamente fácil para los principiantes. Sin embargo, es exactamente ésta facilidad que lleva al núcleo de lo que está mal con los currículos de hoy en día.

“Si vas a una tienda y compras un libro de Java, son 1.200 páginas; 300 páginas son el lenguaje y 900 son bibliotecas misceláneas. Y es verdad que puedes sortear muchas cosas juntas en java muy fácilmente… así que puedes sortear cosas juntas sin un conocimiento mínimo,” dice. “Pero para mí, eso no es ingeniería del software, eso es algún tipo de programación consume-nivel.”

“El problema con Java es que esconde muchas cosas… esconde los temas de compilación - ¿qué está haciendo un compilador? Creo que si fuera a hablarle a un estudiante de Java, ni conocerían la palabra ‘compilador’. Si la conocieran, estoy seguro que no voy a obtener una idea si preguntara ‘¿qué hace un compilador?’”
El problema, a nivel de mercado en Norte América sería “Si la gente sale de las escuelas y saben Java y programación Web, y saben cómo armar cosas usando bibliotecas, ese es el tipo de habilidades que no se demandan”, Los trabajos que requieren no más que éstas habilidades de bajo nivel puede perfectamente hacerse desde países con sueldos bajos.
Como resúmen, el constructor a partir de bibliotecas de Java de hoy, es el repartidor de pizzas de mañana.

¿Quién debería estudiar (y quién no) Ciencias de la Computación?

Se necesita una persona con un set bien específico de inclinaciones y talentos para ser un programador de computadoras, comenta Dewar. Son éstas personas específicas para quienes deberían apuntar sus programas las escuelas - no la masa de personas semi-interesadas que usan bibliotecas pre-hechas para crear aplicaciones sin inspiración. Reflexión final de Dewar:

“La mayoría de los que entramos en programación realmente lo hacíamos porque lo encontrábamos divertido. Encontramos el desafío intelectual divertido. Encontramos que enfrentarnos a un problema complicado, luego pensar soluciones algorítmicas interesantes, es divertido. Encontramos estructuras de datos listas que resuelven problemas interesantes, divertidas.”
“Tal vez no sea divertido para una audiencia más grande, pero la educación de ciencias de la computación debería ser más sobre encontrar a esas personas que disfrutan ese tipo de diversión y enfocarse a ellos en vez de hacerlo todo fácil.”
“Si la gente encuentra aburrido computar algún valor interesante, entonces corre ese programa y obtiene un valor de 42 cuando debería ser 83, y encuentre porqué obtuvieron 42 en vez de 83, si encuentran eso tedioso y aburrido, entonces no son la clase de gente que necesitamos.”

Para los que se sientan identificados con la gente que describe en su reflexión final, creo que vamos por buen camino.

¿Los dos tipos de Programadores ?

En Coding Horror, un blog bien interesante para programadores, Jeff Atwood escribe un post titulado “The Two Types of Programmers”, donde plantea una agrupación más general de los tipos de programadores.

“Contrario al mito, no hay catorce tipos de programadores.. Hay realmente solo dos, como nos recuerda Ben Collins-Sussman.

Hay dos “clases” de programadores en el mundo del desarrollo del software: voy a llamarlos el 20% y el 80%. Los tipos del 20% son lo que se llamarían programadores “alfa” - los líderes, el tipo que lugares como Google y Fog Creek software buscan contratar desesperadamente. Éstos tipos fueron los primeros en instalar Linux en su casa en los 90´s; la gente que escribe compiladores en Lisp y aprende Haskell los fines de semana “por diversión”; participan activamente en proyectos open source; siempre están al tanto de las últimas, y más frescas tendencias en la programación y herramientas.

Los tipos del 80% hacen el bulto de la industria del desarrollo de software. No son estúpidos; son meramente vocacionales. Fueron a la escuela, aprendieron suficiente Java/C#/C++, luego obtuvieron un trabajo escribiendo aplicaciones internas para bancos, gobiernos, firmas de viajes, firmas legales, etc. El mundo usualmente ni ve su software. Usan cualquier herramienta que les provee Microsoft — usualmente VS.NET si están en C++, o capaz un GUI IDE como Eclipse o IntelliJ para desarrollar en Java. Nunca han usado Linux, y no están muy interesados en él de todas formas. Muchos nunca han usado siquiera control de versiones. Si lo han hecho, es con cualquier herramienta entregada con la caja Microsoft (como SourceSafe), o alguna cosa antigua que le hayan entregado. Saben exactamente lo suficiente para hacer su trabajo, luego se van los fines de semana a casa y se olvidan de las computadoras.”Personalmente, convivo con esta teoría a diario en clase. Una frase típica, a tono de burla, en mi salón de clase es: “Eso el Visual Studio te lo hace solo” ó “¿Para qué vas a aprender eso si ya está hecho?” ó “Ésto nunca lo vas a usar, es al pedo aprenderlo“. Con esa mentalidad se maneja este 80%.

El problema, el primer año aprendimos a usar Visual Basic, un IDE que te autocompleta, te tabula, y el framework .NET que incluye todo. Y resulta muy difícil para la mayoría salir de eso. Trabajar en C a bajo nivel es como darse contra un muro de piedra en un automóvil a 90 km/h y sin cinturón de seguridad…

Lo peor no es ésto, sino la cabeza de no salir de lo que ya se aprendió, de aprender una cosa que resulta “cómoda”, y no salir de eso. Muchos dijeron cuando empezamos con la materia: “¿Para qué quiero aprender C si nunca lo voy a usar?” ó “Yo nunca voy a programar un sistema operativo, ¿para qué quiero aprender C?” Conociendo esa mentalidad, ¿quién contrataría a ésta gente para un puesto de programador?

Me imagino la situación (situación Dilbert):
Jefe - “Mirá, tenés que hacer una librería en C que interactúe con nuestro framework de persistencia para controlar el puerto serie del servidor
Empleado - “¡Ah no!, yo eso no lo sé hacer, aparte el Visual no trae cómo hacerlo…

Son el tipo de gente que cumple con las 12 señales de que eres un mal programador. Son una nueva generación de 80% que se está gestando…

Para reafirmar más ésta teoría, se aplica la teoría general del Dr. Gregory Walter Graffin III, quien declaró que

En cualquier muestra al azar de la población general, se encontraría que el 80% de la gente son completos idiotas.

Es totalmente compatible, aislamos una muestra de la población, con la característica en común de ser programadores. El 80%, por ende, no son muy inteligentes…
El artículo de Coding Horror continúa diciendo:

“Cuando trabajo con equipos de programadores en el campo, consistentemente me asombro con el abismo entre ese 20% y el resto del mundo. Hace que la división entre el campo open-source y el campo Microsoft parezca un charco llano.

Declaración shockeante #1: La mayor parte de la industria está hecho del 80% de los programadores.. Sí, la mayoría del mundo son tiendas pequeñas de desarrollo para Windows, o firmas pequeñas que contratan programadores internos. La mayoría de las compañías tienen unos pocos tipos del 20%, y son generalmente los que presionan a sus jefes de pelo parado para cambiar políticas, actualizar herramientas, o usar un sistema de control de versiones sano.
Declaración shockeante #2: La mayoría de los alpha-geeks se olvidan de la declaración shockeante #1. La gente que trabaja con software open source, participan en argumentos apasionantes de criptografía en Slashdot, y bajan los últimos lanzamientos GIT son extremadamente propensos a perder de vista el hecho de que “el 80%” existe. Se emocionan con la última distro de Linux o herramientas de AJAX o sistema SCM distribuido, pasan todo el fin de semana en eso, bloguean al respecto… y luego están confundidos sobre porqué no pueden lograr que su oficina empieza a usarlo.

Tal vez no es algo impresionante para mí, pero un excelente e importante recordatorio para todos, sin embargo.

A menudo pienso que perdemos el tiempo escribiendo blogs los cuales son mayormente leído por el mismo 20%. En mi experiencia existe un pequeño efecto de goteo de los programadores alfa hacia todos los demás. Y si lo hay, lleva décadas.”

Jeff continúa su artículo incitando al 20% a cambiar, a construir un puente entre el 20% y el 80%:

“Si realmente quieres cambiar el status quo del desarrollo de software, si realmente quieres marcar una diferencia este año, tienes que ayudar fuera del pequeño grupo insular de programadores alfa y crear el cambio en el otro 80% del mundo. Y eso es mucho, mucho mas difícil que predicarle al convertido 20%. Es por eso que admiro a gente como Scott Mitchell, porque entiende la importancia de llegarle al otro 80%.”
(…)
“Desearía que fuera más sencillo para mí, porque estoy de acuerdo con Scott” (…) “Creo que la verdadera medida de éxito no es cuántos alpha geeks podés hacer que te presten atención. Es cuántos típicos, poogramadores promedio has alcanzado, aunque sea de una forma pequeña. Si realmente te importa el arte del desarrollo de software, nos ayudarás a construir ese puente entre el 80% y el 20% también.

Es difícil lidiar con éste 80%, pero a lo largo de la carrera, van a estar siempre presentes. ¿Qué piensas al respecto? ¿Te consideras ofendido por el post? Estás en el 80…

domingo, 9 de marzo de 2008

Nace el Proyecto JDataObject

Un grupo de Alumnos de la Universidad Nacional del Santa y mi persona estamos desarrollando un proyecto con las siguientes características

I.- DESCRIPCION DEL PROYECTO
Desarrollo de herramientas y componentes para la generación de consultas de Base de datos y diseño de objetos (Texto,Campos, Imágenes, Campos calculados, lines, etc.) asi como de sus propiedades para la edición y mantenimiento de los datos.
Añadir una nueva funcionalidad a NetBeans que permita la creación de Objeto de datos (JDataObjetc) para el manejo y edición de datos a través del control JDataControl.
El proyecto esto formado de 2 elementos:

1.-Plugin para NetBeans que permite el diseño dinámico de consultas así como el diseño de Objetos de Datos (JDataObjetc). El objeto JDataObject es un objeto que encapsula una consulta SQL así como las propiedades de cada uno de los objetos definidos en esta. Estos objetos pueden ser Texto, campos de tablas y campos calculados. El objeto también pose propiedades en si mismo para las funciones inherentes al trabajo con Datos y la presentación de estos. El diseñador de objetos JDataObjet utiliza archivos en formato XML para almacenar las diferentes propiedades de cada objeto.

2.-JDataEditControl.-
Es un Bean que encapsula la funcionalidad del trabajo con una consulta de base de datos haciendo uso de cursores desplazables con cualquier base de datos cuyo controlador JDBC soporte estas funcionalidades. La mayoría de las operaciones cotidianas de trabajo con una consulta actualizable de datos se pueden realizar de una manera muy sencilla con una mínima programación. Este control aumenta tremendamente la productividad en la creación de aplicaciones que trabajan con una base de datos.
Módulos que conforman el Proyecto
• Diseñador dinámico de consultas
• Diseñador de Objetos JdataObjetc
• Componente JdataeditControl

II- BENEFICIOS PARA LA COMUNIDAD DE NETBEANS
• Permitir a NetBeans poder competir con otros entornos de desarrollo como PowerBuilder, Delphi y Visual Basic los cuales cuentan con herramientas productivas para el acceso y manejo de datos.
• Incrementar el desarrollo de aplicaciones Desktop con NetBeans
• Incremento de la productividad en el desarrollo de aplicaciones con Base de datos.
• Facilidad de adopción de Netbeans para desarrolladores de otros lenguajes y entornos de desarrollo.
• Introducción al mundo de las Base de datos de una manera fácil y práctica para los programadores de Java noveles.

III.- PLAN DE IMPLEMENTACION
El proyecto se implementara utilizando solo componentes proporcionados por la plataforma de Netbeans y el proyecto Ireport de JasperSoft. Se desarrollara un modulo que extienda las capacidades de Trabajo con base de datos, para lo cual se desarrollara un generador dinámico de consultas, este generador enviara la consulta SQL al diseñador de Objetos JDataObject, en el cual se podrá ajustar las propiedades de visualización y otras de cada objeto pudiendo ser este Texto, Imágenes, Dibujos y campos calculados. Los objetos JDataObjet podrán ser llamados por el componente JDataEditControl que es un Beans que encapsulará la mayoría de operaciones con el tratamiento de datos, se utilizara como repositorio de información archivos en formato XML. El Proyecto esta dividido en 3 Módulos
• Diseñador dinámico de consultas .- Esta se desarrollara de manera visual permitiendo al usuario seleccionar el origen de base de datos y realizar la selección de Tablas y campos de estas , así como establecer las relaciones existentes entre las diferentes tablas, pudiendo alternativamente ingresar parámetros de recuperación de la base de datos.
• Diseñador de Objetos JDataObjetc.- La consulta generada con la herramienta anterior es utilizada por esta herramienta la cual permitirá el diseño y ubicación de los diferentes campos así como de sus propiedades, los formatos de presentación de los registros serán 2 de manera Tabular y otra un Grid. Todos los parámetros de la consulta se grabaran en un archivo XML el cual será interpretado mas adelante por el Control JDataEditControl
• Componente JdataeditControl (Grid y Tabular).- Es un componente que permite trabajar con el Objeto JDataObjetc, y provee las funciones y propiedades para el manejo de las operaciones con los registros de la base de datos.
Se utilizara la plataforma NetBeans para la creación del plugin para la generación de consultas dinámicas así como el diseño del JDataObjetc.