Developing software is not an easy matter

19

Developing software is not an easy matter

Desarrollar software no es una cuestión fácil

Tina Cardrige

Microsoft. cardrigeT(AT)microsoft.com

INFORMACIÓN DEL ARTÍCULO

Tipo Reflexión

Historia

Recibido: 30-09-2014 Correcciones: Aceptado: 22-11-2014

Keywords

Software development,

programming, programming tools.

Palabras clave

Desarrollo de software, programación, herramientas de programación.

ABSTRACT

Why is it so difficult to learn to develop software? This question has been trying to answer for a long time, but has not yet found a solution to this issue. Moreover, it tends to confuse development with programming, and this also creates problems to elucidate the question. In an era in which urgently required improve the quality, and reliability, and safety of software it becomes urgent to potentiate or develop skills and abilities in professionals to meet these needs. But students are not interested in making careers involving these concepts, they prefer other less demanding and easier to achieve a certification. This article attempts to answer the question and present some suggestions for overcoming this difficulty.

RESUMEN

¿Por qué es difícil aprender a desarrollar software? Este interrogante se ha intentado responder desde hace mucho tiempo, pero todavía no se ha encontrado una solución a esta cuestión. Además, se tiende a confundir desarrollo con programación, y esto también genera problemas para dilucidar la pregunta. En una época en la que se requiere urgentemente mejorar la calidad, la fiabilidad, y la seguridad del software se hace apremiante potencializar o desarrollar habilidades y destrezas en los profesionales para atender estas necesidades. Pero los estudiantes no están interesados en tomar carreras que involucren estos conceptos, prefieren otros de menos exigencias y con mayor facilidad para alcanzar una titulación. En este artículo se intenta responder a la pregunta y se presentan algunas sugerencias para superar esa dificultad.

© 2014 IAI. All rights reserved. 1. Introducción

La mayoría de personas tiene acceso, utiliza o depende de un sistema software, y el desarrollo de la actual sociedad está sometido a los productos desarrollados en software. Con este panorama, ¿por qué el software no satisface plenamente a los usuarios? ¿Por qué sus productos presentan falencias en seguridad y fiabilidad? ¿Por qué las legislaciones no le prestan suficiente atención a este asunto? En general, se podría encontrar mejores formas de desarrollar software, aminorar sus costos, y endurecer las políticas de seguimientos a estos productos. Pero el hecho de que la programación gire en torno a personas, y que lo lleven a cabo personas, dificulta llegar a soluciones rápidamente. Programar puede ser sencillo, al menos es la creencia popular, pero desarrollar es una cuestión de ciencia y conocimiento, por eso es difícil. Por esto es que cada día menos estudiantes quieren ser desarrolladores.

Se necesitan más desarrolladores, y esto se ha convertido en un punto de controversia mundial. La Oficina de Estadísticas Laborales de los Estados Unidos predijo en 2008 una enorme demanda de profesionales en informática [1]. De acuerdo con este informe, la demanda de profesionales de TI de 2006 a 2016 será el doble de la tasa de crecimiento del resto de la fuerza laboral. La

estimación actualizada en noviembre de 2009 [2] predecía que las ocupaciones en Informática y Matemáticas eran el grupo ocupacional de más rápido crecimiento dentro del grupo principal de más rápido crecimiento. Las estadísticas de la cantidad de profesionales en TI desempleados sugiere que tal vez haya demasiados programadores hoy en día, pero muy pocos desarrolladores [3].

Para la mayoría ambas ocupaciones son lo mismo, programadores y desarrolladores, pero un excelente trabajo de la RedLatinaIS [4, p. 20] aclara esta cuestión y determina las diferencias sustanciales entre ambas:

Los programadores escriben buen código. Hacerlo bien y limpio es un factor importante, pero a menudo tienen prioridad otras cuestiones. Las habilidades matemáticas son opcionales, aunque poseerlas les ayuda a ser conscientes de los problemas comunes y de las soluciones relacionadas con el dominio, pero son primordiales las relacionadas con la comunicación y la interacción social. Son generalistas sin un tipo de especialización verdaderamente profundo; son capaces de encontrar caminos en torno a los problemas, y de conectar diversos componentes para cumplir con una serie de requisitos. Su trabajo consiste en aplicar el Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

20 conocimiento que poseen, del lenguaje de programación,

para escribir código eficiente y eficaz, a la vez que respetan los conceptos de calidad y de seguridad, y responden al diseño que se ha construido desde la Ingeniería de Software.

Los desarrolladores escriben código de calidad. Hacerlo limpio, claro, bien factorizado y libre de errores son cuestiones importantes que tienen en cuenta, y además conocen el significado de buen código dentro de un dominio. Tienen adecuados conocimientos en matemáticas y en cómo buscar buenas soluciones para los problemas; poseen amplios conocimientos en algoritmia y buenas habilidades en su área de experticia y las relacionadas; debido a que su trabajo se desenvuelve al interior de equipos multi-disciplinares, poseen buena capacidad de comunicación verbal y escrita, y de interacción con otras personas. Son profesionales que contribuyen de diversas maneras para que el producto software tenga éxito, y su trabajo consiste en aplicar principios científicos e ingenieriles para comprender, abstraer y moldear un problema, que se pueda resolver mediante un programa informático, para luego aplicar una metodología con el objetivo de llevar a la práctica la solución creada, tradicionalmente soportada en código de lenguaje de programación. En términos generales son responsables de aplicar procesos de calidad en todo el ciclo de vida del software.

Aunque puede no estar claro si la industria necesita más programadores o más desarrolladores, lo que sí es una realidad es que muchos estudiantes comienzan por el camino de la programación y se desaniman rápidamente. Las cifras de las altas tasas de deserción en los cursos introductorios de computación son comunes en la literatura y en las discusiones en diferentes Congresos y Conferencias. Jens Bennedsen y Michael Caspersen [5] hicieron el primer intento razonable para averiguar lo que realmente parecen las tasas de fracaso. Solicitaron datos a profesores de todo el mundo a través de varias listas de correo de Ciencias Computacionales (CS). Más de 60 instituciones presentaron sus tasas de fracaso en estos cursos, lo que significa que estos datos son auto-seleccionados y auto-reportados. Por ejemplo, escuelas con resultados realmente embarazosos pueden haber optado por no participar, o mentir, y los resultados pueden estar sesgados debido a que el muestreo era no-aleatorio. En general, el 35% de los estudiantes fracasan o se retiran del primer curso. Por lo tanto, los indicios indican que aproximadamente uno de cada tres estudiantes que inician un curso CS, en todo el mundo, falla o se da por vencido. ¿Por qué pasa esto?

Aunque los resultados del estudio reportan el éxito o el fracaso en tomar un curso en una universidad, para algunos el criterio de asistir a un proceso de educación formal no es la única definición posible de éxito. Hay muchos programadores que nunca tomaron un curso formal en toda su vida, pero tienen éxito en la vida laboral. Nuevamente, persiste la confusión entre lo que es ser programador y ser desarrollador, y lo peor, la industria tampoco parece diferenciar.

Claro que se necesita un proceso formal de capacitación para adquirir o potencializar las habilidades, destrezas, y

capacidades para desarrollar software. Así que primero hay que establecer la razón por la que los estudiantes tienen dificultades para este aprendizaje. Si fuera posible establecer si es que desarrollar software es una actividad anti-natural, se podrían buscar formas alternativas y nuevas didácticas para hacerlo más fácil o diferente. Una investigación liderada por el profesor colombiano Edgar Serna [6-10] determinó que una característica necesaria para este tipo de profesionales es que desarrollen su capacidad lógico-interpretativa y abstractiva, porque, como él mismo concluye, el desarrollo de software es un proceso netamente abstracto, y se requiere una mente lógica para interpretarlo, modelarlo, y simularlo. Al parecer se debería comenzar por ahí para buscar que los estudiantes no abandonen estas disciplinas.

2. Aprender a desarrollar/programar

En la década de 1980 en la Universidad de Yale se utilizaba reiteradamente un ejercicio el curso de programación en Pascal [11]: Escribir un programa que sume repetidamente números enteros positivos, e imprimir su promedio cuando lea el valor entero 99999. Conocido como el problema de la precipitación, se convirtió en uno de los más estudiados en los primeros años de la investigación en informática educativa. En el artículo de 1983, del que se toma la formulación presentada, el equipo de Yale estaba explorando cómo mejorar el rendimiento de los estudiantes en la solución del ejercicio, y se lo presentaron a tres grupos diferentes: 1) estudiantes de primer semestre, que ya sabían utilizar los ciclos while, repeat, y for, 2) estudiantes de segundo semestre, que ya habían recibido por lo menos un curso de estructuras de datos, y 3) estudiantes de tercer y cuarto año de programación de sistemas.

En cada grupo la mitad de los estudiantes utilizó Pascal tradicional y la otra mitad tenía la oportunidad de utilizar otro lenguaje (C o Phyton). Los resultados, resumidos en la Tabla 1, pueden sorprender: sólo el 14% de los estudiantes de primer semestre pudo resolverlo en Pascal, y el 30% de los estudiantes del segundo semestre no pudo resolverlo en ningún lenguaje. Este estudio fue repetido en la literatura varias veces [12, 13], formal e informalmente, sorprendente con resultados similares cada vez.

Tabla 1. Rendimiento de los estudiantes de Yale

Grupo Con Pascal Con C o Phyton

Primer semestre 14% 24%

Segundo semestre 36% 61%

Tercer y cuarto año 69% 96%

La solución al ejercicio requiere un condicional relativamente complejo que controle el ciclo: si la entrada es negativa, la ignora y continúa con la siguiente; si la entrada es positiva y diferente de 99999, la lleva a la suma, incrementa el contador, y continúa con la siguiente; si la entrada es 99999, la ignorar, sale del ciclo, y muestra la suma. Es fácil cometer un error al tener en cuenta la entrada 99999 en la suma.

21 programación fuera realmente mala? En esos años pocos

estudiantes podrían haber aprendido algo de programación antes de entrar en la universidad, así que cualquier instrucción que recibieran provenía de los cursos del primer semestre. Durante muchos años los investigadores se preguntaron cómo llevar a cabo un estudio acerca de la programación de computadores en el que se pudiera evitar el factor de una posible mala formación en la institución.

En 2001, Mike McCracken [14] organizó un grupo de investigadores para realizar un mismo estudio en cada una de sus cursos: asignar el mismo ejercicio y darles a los estudiantes 90 minutos para presentar una solución en papel. Cuatro instituciones de tres países participaron en este primer estudio multi-institucional, multi-nacional (MIMN) de rendimiento de los estudiantes en informática. Mediante una comparación de resultados a través de fronteras institucionales y nacionales, los investigadores esperaban obtener una imagen clara de lo que realmente pueden hacer estudiantes en sus primeros cursos.

El problema fue evaluar expresiones aritméticas (prefijo, infijo, o postfijo) sólo con números, operadores binarios (+, -, /, *), o negación unaria (~ con el fin de evitar la complicación de sobrecargar el signo menos). En total, 216 estudiantes presentaron respuestas. La puntuación media sobre un una rúbrica de clasificación independiente del lenguaje de 110 puntos fue 22,89 (21%). Los estudiantes solucionaron terriblemente el ejercicio.

El grupo de trabajo realizó varias evaluaciones de los datos, y encontraron que el rendimiento varía dramáticamente entre cursos. También evidenciaron los efectos joroba, que muchos profesores de informática han señalado y que varios trabajos han tratado de explicar. Algunos estudiantes simplemente hacen las cosas, y funcionan bien, pero la mayoría no lo logra. ¿Por qué es que algunos estudiantes simplemente consiguen programar y otros no? Se ha investigado desde variables como la experiencia previa en el área y los conocimientos matemáticos [15], y todavía no hay explicación convincente para este efecto.

Algunos estudiantes pueden no responder a un estilo particular de enseñanza o profesor, pero ¿por qué tantos estudiantes de diferentes instituciones lo hacen tan mal? ¿Estamos enseñando mal en todas partes? ¿Estamos sobre-estimando lo que los estudiantes deben ser capaces de hacer? O ¿no estamos midiendo las cosas correctas? Raymond Lister [16] organizó otro grupo de trabajo en 2004 para explorar algunas de estas preguntas. La idea de este equipo era que el grupo de McCracken pedía demasiado de los estudiantes. Darles un problema requiere un alto nivel de pensamiento para diseñar e implementar una solución. Entonces decidieron centrarse en las habilidades de bajo nivel para leer y trazar código. Crearon un cuestionario de opción múltiple (MCQ por sus siglas en inglés), en el que se les pedía a los estudiantes llevar a cabo tareas como lectura de código e identificación de resultados, o identificar el código correcto para llenar los vacíos en un fragmento de programa. Las preguntas se

centraron en la manipulación de arreglos. Les pidieron a los participantes de todo el mundo tratar la misma MCQ con sus estudiantes. Los resultados fueron mejores, pero aún decepcionante. Los 556 estudiantes tuvieron un puntaje promedio del 60%. Aunque estos resultados sugirieron que el grupo McCracken sobrestimó lo que los estudiantes podían hacer, Lister y su grupo esperaban un rendimiento mucho mejor en sus preguntas.

Los esfuerzos McCracken y Lister les enseñaron a los investigadores que es difícil subestimar la cantidad de estudiantes a entender cuando se trata de enseñar a desarrollar software. Están aprendiendo claramente mucho menos de lo que pensamos. Ahora, algunos estudiantes están aprendiendo; pero la mayoría no. Entonces, ¿qué tan difícil es aprender a desarrollar software para que la mayoría de estudiantes no lo logren?

2.1 ¿Por qué es difícil?

Los lingüistas suelen coincidir en que los seres humanos están cableados para el lenguaje. El cerebro ha evolucionado para aprenderlo rápida y eficientemente. Es decir, estamos conectados específicamente para el lenguaje natural. Por el contrario, la programación es la manipulación de un lenguaje artificial inventado para un propósito relativamente poco natural: decirle a un determinado agente no humano (computador) exactamente qué hacer. Tal vez la programación no es una actividad natural para los humanos, y sólo unos pocos son capaces de realizar los ejercicios mentales complejos para tener éxito en este acto anti-natural.

En este orden de ideas, ¿Cómo podemos responder esta pregunta? Podemos intentar un enfoque similar a la modificación de Lister al trabajo de McCracken: escoger una parte más pequeña de la tarea y centrarse sólo en eso. Programar es decirle a una máquina qué hacer en un lenguaje no-natural. Y, si les indicamos a los participantes del estudio que describan en lenguaje natural ¿cómo le dirían a otro ser humano como llevar a cabo una tarea determinada? ¿Cómo definirían sus programas? Si quitamos el lenguaje artificial, ¿está programación sería natural o de sentido común?

En 1981 Miller [17] les pidió a los participantes en sus estudios crear instrucciones para que otros las siguieran. Los participantes recibieron descripciones de varios archivos (empleados, cargos, salarios), y tareas como: hacer una lista, organizada por el nombre, de los empleados que cumplan cualquiera de los siguientes criterios: 1) tienen un cargo técnico y ganan 6 dólares o más por hora, o 2) es soltero y gana menos de 6 dólares por hora. Miller aprendió mucho acerca de qué era difícil y qué era fácil para los participantes. En primer lugar, los sujetos completaron sus tareas. En los resultados no dice que 1/3 abandonaron o fracasaron, como pasa todo el tiempo en los cursos de programación. El reto fundamental de especificar un proceso para que ejecute otra persona no parece ser el problema.

22 programación estudiados por otros investigadores es la

estructura de la solución. Los temas de Miller no definieron iteraciones, pero sí un conjunto de operaciones. Por ejemplo, ellos no dijeron: tome cada carpeta y mire el apellido; si comienza con S... En su lugar, hablaron de hacer las cosas para todos los apellidos que empiezan con S... Miller se sorprendió de esto: nadie especificó las condiciones de finalización para este ciclo. Algunas personas hablaron sobre condiciones IF-like, pero ninguno utilizó un ELSE. Estos resultados puntualizan la posibilidad de que definir un lenguaje de programación natural es más fácil para los principiantes. Miller llevó a cabo otro experimento separado donde les dio a otros participantes las mismas instrucciones del primer experimento pero definiendo vagamente los ciclos necesarios. Ninguno tuvo problema con estas instrucciones. Era obvio cuando parar al procesar los datos. Los sujetos procesaron el conjunto de datos, pero se incrementaron un índice.

John Pane [18] tomó de nuevo esta exploración a finales de 1990 y principios de 2000, porque estaba interesado explícitamente en la creación de un lenguaje de programación que estuviera más cerca de cómo las personas describen naturalmente procesos para que otros utilicen. Replicó los experimentos de Miller, pero con diferentes tareas y entradas. Le preocupaba que al proporcionar archivos y solicitar listas, Miller pudo haber direccionado los resultados. En cambio, Pane les mostró a los participantes imágenes y películas de videojuegos, y luego les preguntó cómo le indicarían al computador que realizara lo mismo; por ejemplo, escribir una declaración para que mueva a Pac-Man en relación con la presencia o ausencia de otras cosas. Como Miller, encontró que las personas no son explícitas acerca de los ciclos. Al ir más allá de caracterizar los tipos de instrucciones que escribieron en términos de paradigmas de programación, encontró un montón de uso de restricciones (éste está siempre haciendo eso), de programación orientada a eventos (cuando Pac-Man se lleva todos los puntos se pasa al siguiente nivel), y de programación imperativa. Nadie habló de objetos ni una sola vez. Hablaron sobre las características y los comportamientos de las entidades en el videojuego, pero no las agruparon (por ejemplo, en clases). Nunca hablaron de los comportamientos desde la perspectiva de las propias entidades; todo estaba desde la perspectiva del jugador o el programador.

Con base a los experimentos de Miller y Pane, se podría afirmar que las personas pueden ser capaces de especificar funciones para otro agente, pero los actuales lenguajes de programación no les permiten programar la forma en que piensan acerca de las tareas. Si los lenguajes de programación fueron hechos más naturales, ¿podría la mayoría de estudiantes aprender a programar? ¿Podrían las personas resolver problemas complejos que implican algoritmos significativos? ¿Sería bueno tanto para tareas simples como para profesionales? Y si no, ¿podrían los estudiantes en algún momento aprender un lenguaje profesional?

Un grupo de investigadores que se hacen llamar Commonsense Computing Group [19] ha estado

respondiendo algunas de estas preguntas. Les piden a estudiantes de primer semestre resolver tareas algorítmicas significativas, como la clasificación o la paralelización de un proceso, en lenguaje natural y antes de que hayan aprendido cualquier lenguaje de programación. Han encontrado resultados sorprendente en estas tareas. En un estudio [20] les pidieron a los estudiantes crear un proceso para un teatro que decide tener dos vendedores de billetes. Supongamos que vendemos entradas telefónicamente para los conciertos de la siguiente manera: cuando un cliente llama y pregunta por un número (n) de asiento: 1) el vendedor encuentra los n mejores asientos que están disponibles, 2) marca los n asientos como no-disponible, y 3) le ofrece las opciones de pago: tarjeta de crédito o débito, o la entrega en una dirección. Supongamos que tenemos más de un vendedor que trabaja al mismo tiempo, ¿qué problemas se podrían encontrar, y cómo poder evitarlos? Unos 66 participantes en cinco instituciones intentaron resolver este problema, con sorprendente éxito. Como se ve en la Tabla 2, casi todos los estudiantes reconocieron cuál era el verdadero desafío del problema, y al 71% se le ocurrió una solución funcional.

Tabla 2. Problemas y soluciones identificados

Logros % Estudiantes

Problemas identificados:

 Venta de entradas más de una vez

 Otros

97% 41% Soluciones razonables a los problemas 71%

La mayoría de las soluciones eran ineficientes (porque ellos mismos eran los solucionadores) así que todavía hay mucho que estos estudiantes deben aprender. Los estudiantes pueden ser más capaces de pensar computacionalmente de lo que se cree. Sin embargo, el hecho de que puedan resolver problemas de procesamiento paralelo sugiere que el problema de lograr que los estudiantes programen puede estar en las herramientas.

3. Opciones de mejoramiento

3.1 Las herramientas de programación

¿Cómo hacer que las herramientas mejoren? Una posible respuesta obvia es migrar hacia una notación más visual. Desde el surgimiento del lenguaje de programación basado en iconos de David Smith, Pygmalion [21], la teoría ha sido que el razonamiento visual tal vez es más fácil para los estudiantes. Ciertamente, ha habido gran cantidad de estudios que muestran que en general las visualizaciones ayudaron a los estudiantes en computación [22], pero relativamente pocos de ellos son cuidadosos.

23 una pregunta al respecto, por ejemplo, acerca de los datos

de entrada que se muestran o de los resultados de la salida. Sin importar cuánta experiencia tuvieran los sujetos con lenguajes visuales o textuales, o qué tipo de lenguaje visual se usara, comprender el lenguaje gráfico siempre les tomó más tiempo, y, en general, comprendieron los lenguajes visuales más lentamente que los textuales. Green y Petre publicaron varios trabajos sobre variaciones de este estudio [24, 25], pero la verdadera prueba llegó cuando Tom Moher y sus colegas [26] apostaron en favor de los lenguajes visuales. Tom y sus estudiantes graduados estaban utilizando una notación visual, Redes de Petri, para enseñar programación a estudiantes de secundaria. Consiguieron una copia de los materiales de Green y Petre y crearon una versión en la que el único lenguaje visual utilizado fue Petri Nets. Entonces, Tom volvió a ejecutar el estudio personalmente con sus estudiantes como sujetos. El sorprendente resultado fue que, de nuevo, los lenguajes textuales eran más fácilmente comprendidos, sin importar las condiciones.

¿Estamos equivocados acerca de los lenguajes visuales? En realidad, ¿la visualización tiende a reducir el entendimiento del software? ¿Qué pasa con estudios como los de Naps et al [22]? ¿Estaban equivocados?

Hay un método estándar para comparar múltiples estudios, llamado meta-estudio. Barbara Kitchenham describe este procedimiento en su trabajo [27]. Chris Hundhausen y sus colegas hicieron este tipo de análisis en estudios sobre la visualización de algoritmos [28]. Encontraron que sí, hay una gran cantidad de estudios que muestran beneficios significativos para los estudiantes, a la vez que también hay una gran cantidad de estudios con resultados no-significativos. Algunos que muestran resultados significativos no hacen evidente cómo podrían ayudar realmente (Figura 1). Encontraron que el hecho de cómo se utilizan las visualizaciones importa mucho. Por ejemplo, utilizándolas en demostraciones de lectura tuvieron poco impacto en el aprendizaje del estudiante, pero al hacer que los estudiantes construyeran sus propias visualizaciones tuvieron un impacto significativo en su aprendizaje.

Figura 1. Resumen de los 24 estudios [28]

Unos pocos estudios variaron el uso de la visualización mientras mantienen todas las demás variables constantes, por ejemplo, tipo de curso, tipo de estudiante, profesor, asignatura. Aunque después de su análisis los autores sospechan que la forma de visualización que se utilice es importante, los resultados no son suficientes para probar su sospecha. Una cosa que enseñan los estudios en

educación es que en realidad es bastante difícil predecir los resultados. Los seres humanos no son tan predecibles como un proyectil que cae o un cóctel químico. De hecho, hay que probar toda sospecha e hipótesis, y, a veces probarlas varias veces en diferentes condiciones, hasta que estar convencidos de algún hallazgo.

3.2 ¿Existe otra forma, otras variables?

Lo que sabemos hasta ahora es que los estudiantes en carreras de computación aprenden mucho menos acerca de diseño y programación de lo que se podría predecir, y que fallan el primer curso a un ritmo bastante alto. Encontramos que el cambio de lo textual a las modalidades visuales no ofrece consistentemente mejores resultados, lo que sugiere que otra variable puede estar en juego. Pero, ¿qué otras variables se podrían manipular con el fin de mejorar el éxito en el aprendizaje de la programación?

En 1999, Georgia Tech decidió exigir computación introductoria para todos los estudiantes de pregrado. Durante los primeros años, sólo un curso satisfacía este requisito, y, en general, el porcentaje de aprobados fue del 78%, que es bastante bueno para el análisis de Bennedsen y Caspersen [5]. Sin embargo, esa cifra no es tan buena cuando se empieza a desagregar. La tasa de aprobación para los estudiantes de Artes Liberales, Arquitectura y Administración fue inferior al 50% [29]. Las mujeres fracasaron en casi el doble de la tasa de los hombres. Un curso dirigido a todos los estudiantes, en el que la mayoría de hombres en carreras técnicas pasa, pone de relieve problemas generales en la enseñanza de la computación.

Forte y Guzdial [30] iniciaron en 2003 un experimento para enseñarles a los estudiantes un tipo diferente de curso introductorio, contextualizado en torno a la manipulación de los medios de comunicación. En esencia, los estudiantes trabajaron los mismos tipos de programas como en cualquier curso introductorio de Ciencias Computacionales. De hecho, trataron de cubrir todos los temas [31] que recomiendan los estándares de ACM e IEEE vigentes. Sin embargo, para analizar todos los ejemplos de los libros de texto, el código de ejemplo en las conferencias, y las tareas los estudiantes debían manipular los medios digitales. Aprendieron cómo recorrer los elementos de una matriz, por ejemplo, mediante la conversión de todos los píxeles de una fotografía en escala de grises. En lugar de encadenar cadenas, concatenaron buffers de sonido para hacer el empalme digital. Mediante la eliminación de ojos rojos en una imagen, sin estropear cualquier otro rojo en la misma, se utilizó para iterar a través de un sub-rango de una matriz. La respuesta fue positiva y dramática. Los estudiantes encontraron el nuevo curso más relevante y convincente, en particular las mujeres cuya tasa de aprobación se elevó por encima de la de los hombres (pero no con cualquier significación estadística) [32]. La tasa media de aprobación en los siguientes tres años se elevó al 85%, incluso a las carreras técnicas en las que no llegaba al 50% por semestre [29].

Suena como un gran éxito pero, ¿es realmente cierto lo que dicen? ¿Ese nuevo enfoque es la única cosa que ha cambiado? Tal vez esas instituciones de repente 0

2 4 6 8 10 12

No-significativos Significativos Significativos en análisis visual

24 comenzaron a aceptar estudiantes mucho más

inteligentes. Quizás Georgia Tech contrató a un nuevo instructor carismático que hechizaba a los estudiantes con el cuidado en el contenido. La investigación en las áreas sociales se refiere a estos factores como una amenaza a la validez del estudio. En este caso, los investigadores incluyeron semestres con diferentes instructores y los resultados abarcan tres años de valor, por lo que es poco probable que de repente los estudiantes fueran muy diferentes. ¿Podría ser entonces que el éxito en la enseñanza de la programación se puede lograr al introducir los medios en la computación?

La primera prueba de los medios en la computación en una institución diferente se realizó en Gainesville State College, en Georgia [33]. Este estudio también encontró mejoras dramáticas en las tasas de éxito entre los estudiantes, los cuales provenían de áreas como la informática y la enfermería. Sin embargo, tanto en Georgia Tech como en Gainesville los estudiantes eran predominantemente blancos. ¿Cambiarían en algo los resultados si los estudiantes fueran de las minorías étnicas? En la Universidad de Illinois en Chicago (UIC), Pat Troy y Bob Sloan introdujeron los medios en sus cursos de computación [34]. Un curso ofrecido a estudiantes que querían especializarse en Ciencias Computacionales, pero que no tenían antecedentes en programación. Durante varios semestres, la tasa de aprobación de estos estudiantes también aumentó. UIC tiene una población estudiantil étnicamente diversa, donde la mayoría pertenece a grupos étnicos minoritarios. Con estos resultados, ¿es posible generalizar que los medios en la computación ayudan al aprendizaje de la programación? El argumento puede ser que éstos siguen siendo casos inusuales. Los estudios en Georgia Tech y Gainesville eran adolescentes, mientras que en Chicago se trató de estudiantes que quieren especializarse y el curso no hace parte normal de sus carreras de pregrado. Bet Simon y sus colegas de la Universidad de California (UCSD), en San Diego, comenzaron a utilizar los medios en los cursos introductorios de las carreras técnicas [35], y encontraron que se incrementó el número de estudiantes que aprueban.

¿Eso es todo? ¿Los medios en la computación son la solución? ¿Todo mundo debería utilizarlos? Aunque diversos estudios lo han aprobado [36, 37], no están libres de ambigüedades. En primer lugar, estos autores no han dicho si los estudiantes aprenden lo mismo con los medios en la computación que sin ellos. Si alguien afirma que lo ha logrado con este enfoque es muy escéptico, porque actualmente no se cuenta con métricas fiables y válidas para hacer esa afirmación. Allison Tew y su equipo [29, 33] trataron de responder a la pregunta de si los estudiantes aprenden lo mismo en diferentes cursos introductorios. Desarrollaron dos pruebas isomórficas con preguntas de opción múltiple en cada uno de los lenguajes que querían comparar: un problema destinado a evaluar un concepto particular (una iteración sobre una matriz) era esencialmente el mismo en ambas pruebas y en todos los lenguajes. Aplicaron estas pruebas antes y después del curso con el fin de medir la diferencia que había en el aprendizaje del estudiante. Encontraron que los

estudiantes aprendieron nuevas y diferentes cosas en el curso de nivel 1, pero que estas diferencias desaparecieron en el curso de nivel 2. Eso es un gran hallazgo, lo que sugiere que las diferencias en el nivel 1 no eran tan críticas para el éxito futuro. Pero en pruebas subsiguientes nunca encontraron el mismo resultado.

¿Cómo puede ser eso? Una posibilidad real es que las pruebas no eran exactamente las mismas; los estudiantes interpretaron de manera diferente; o puede ser que no midieron exactamente el tipo de aprendizaje que se pretendía probar. Por ejemplo, tal vez la respuesta a algunas de las preguntas podría ser adivinada porque los distractores estaban tan lejos de ser factibles que los estudiantes los pasaban por alto sin realmente saber la respuesta correcta. Una buena prueba para medir el aprendizaje debe ser confiable y válida, en otras palabras, medir lo correcto, y que los estudiantes la puedan interpretar de la misma manera todo el tiempo. Por eso es que hasta el momento no es posible determinar con certeza que los estudiantes están aprendiendo las mismas cosas bajo diferentes enfoques. Es muy bueno que los estudiantes tengan mayor éxito con los medios, y es genial que a los estudiantes de la UCSD les vaya mejor incluso en el segundo curso, pero realmente no se puede decir con seguridad que todos los estudiantes aprenden las mismas cosas.

En segundo lugar, incluso aunque en Georgia Tech, Gainesville, UIC, y UCSD fueron capaces de demostrar que los estudiantes aprendieron lo mismo en el curso introductorio, ¿qué podría probar todo eso? ¿Que el curso se debe trabajar personalizado? ¿Que este tipo de curso es mejor que el tradicional, sin importar el éxito que peste alcance? ¿Qué funciona para cada tipo de estudiante sin importar su preparación o interés? ¿Que no importa la preparación y experiencia del profesor? Por supuesto, todo esto es ridículo. Siempre se puede imaginar algo que podría salir mal.

En general, los enfoques curriculares nos ofrecen modelos prescriptivos, sino teorías predictivas. Los estudios de los medios en la computación muestran evidencia de que, para una variedad de estudiantes y profesores, la tasa de éxito en un curso introductorio se puede mejorar, pero no que inevitablemente se va a mejorar. Prometer algo así sería como tener una receta mágica. No es una teoría predictiva en el sentido de que puede predecir mejoras, pero sin conocer muchas más variables que aún no han sido probadas. Tampoco puede ser predictiva porque no es posible decir que al no usar los medios se garantiza el fracaso.

4. Conclusiones

25 Mientras que, por ejemplo, el National Council of Teachers

of Mathematics, se creó en 1920.

La mayoría de estudios en este sentido apuntan más hacia lo complejo que es para que los humanos aprender a programar. Seguimos maravillados con la inteligencia y la creatividad de los seres humanos, y que incluso los estudiantes sin formación en informática ya puedan pensar en términos algorítmicos. Sin embargo, el desarrollo de esa habilidad hasta el punto de que se pueda utilizar para dar instrucciones a un dispositivo en un lenguaje máquina se produce más lentamente de lo que se podría esperar. Podemos lograr que los estudiantes lo hagan a través del proceso, pero aún no tenemos medidas efectivas de lo mucho que están aprendiendo. Lo que realmente necesitamos como campo son teorías predictivas, basadas en modelos de cómo las personas realmente desarrollan su comprensión de la informática. Desde esas teorías se podrían construir planes de estudio en el que se pueda confiar. Tenemos pocos trabajadores, y sólo se acaba de empezar en esta difícil tarea. Existen pocos eventos científicos dedicados a este tipo de discusiones. Pero aun así, ya se han dado los primeros pasos hacia la comprensión de por qué es que a los estudiantes les resulta tan difícil aprender a programar [9, 10].

Como el mismo profesor Serna lo expresó en La Habana en 2013 [39]: Somos una Sociedad Software-Dependiente, y sino empezamos a profesionalizar el desarrollo de estos productos podríamos avocarnos a una crisis peor que a la falta de los mismos dispositivos que intentamos

programar .

Referencias

[1] Vegso, J. (2008). BLS Predicts strong job growth and high salaries for IT workforce through 2016. Computing Research News 20(3), pp. 1-1.

[2] Lacey, A. & Wright, B. (2009). Employment outlook: 2008– 18 - Occupational employment projections to 2018. Monthly Labor Review, November 2009, pp. 82-123. [3] Rampell, C. (2010). Once a dynamo, the tech sector is slow

to hire. The New York Times, Sept. 7.

[4] Serna M. E. (Ed.). (2013). Manifiesto por la profesionalización del desarrollo de software. Medellín: Editorial IAI.

[5] Bennedsen, J. & Caspersen, M. (2007). Failure rates in introductory programming. ACM SIGCSE Bulletin 39(2), pp. 32-36.

[6] Serna, M.E. (2013). Logic in Computer Science. Revista Educación en Ingeniería 8(15), pp. 62-68.

[7] Serna, M.E. & Serna, A.A. (2013). Logic in Computer Science. In Baralt, J. et al (Eds.), XII Conferencia Iberoamericana en Sistemas, Cibernética e Informática: CISCI 2013. Orlando, USA.

[8] Serna, M.E & Flórez, O.G. (2013). The logical reasoning as functional requirement in engineering. In Larrondo, P.M.M. et al. (Eds.), Eleventh LACCEI Latin American and Caribbean Conference for Engineering and Technology. Cancún, México.

[9] Serna, M.E. & Polo, J.A. (2014). Logic and abstraction in engineering education: A necessary relationship. Revista Ingeniería Investigación y Tecnología XV(2), pp. 299-310.

[10] Serna, M.E. & Zapata, A.L. (2014). Approach to logic and abstraction in the engineering training. Revista Internacional de Educacion y Aprendizaje 2(1), pp. 35-47. [11] Soloway, E.; Bonar, J. & Ehrlich, K (1983). Cognitive

strategies and looping constructs: An empirical study. Communications of the ACM 26(11), pp. 853-860.

[12] Johnson, W. & Soloway, E. (1987). PROUST: An automatic debugger for Pascal programs. In Kearsley, G. (Ed.), Artificial intelligence and instruction: Applications and methods, pp. 49-67. Boston: Addison-Wesley.

[13] Spohrer, J. (1992). Marcel: Simulating the novice programmer. Norwood: Ablex.

[14] McCracken, M. et al (2001). A national, multi-institutional study of assessment of programming skills of first-year CS students. ACM SIGCSE Bulletin 33(4), pp. 125-180.

[15] Bennedsen, J. & Caspersen, M. (2005). An investigation of potential success factors for an introductory model-driven programming course. Proceedings of the first international workshop on computing education research, pp. 155-163. October 1-2, Seattle, USA.

[16] Lister, R. et al [2004]. A multi-national study of reading and tracing skills in novice programmers. ACM SIGCSE Bulletin 36(4), pp. 119-150.

[17] Miller, L. [1981]. Natural language programming: Styles, strategies, and contrasts. IBM Systems Journal 29(2), pp. 184-215.

[18] Pane, J.; Myers, B. & Ratanamahatana, C. (2001). Studying the language and structure in non-programmers’ solutions to programming problems. International Journal of Human-Computer Studies 54(2), pp. 237-264.

[19] Cambria, E. et al (2009). Common Sense Computing: From the society of mind to digital intuition and beyond. Lecture Notes in Computer Science 5707, pp. 252-259.

[20] Lewandowski, G., D.J. Bouvier, et al. 2007. Commonsense computing (episode 3): Concurrency and concert tickets. Proceedings of the third international workshop on computing education research, pp. 133-144. September 15-16, Atlanta, USA.

[21] Smith, D. (1975). PYGMALION: A creative programming environment. PhD dissertation. Computer Science Department, Stanford University.

[22] Naps, T. et al (2003). Evaluating the educational impact of visualization. ACM SIGCSE Bulletin 35(4), pp. 124-136. [23] Green, T. & Petre, M. (1992). When visual programs are

harder to read than textual programs. In Veer, G. et al (Eds.), Proceedings Human-Computer Interaction: Tasks and Organisation, pp. 167-180. July 2-5, Rome, Italy.

[24] Green, T.; Petre, M. & Bellamy, R. (1991). Comprehensibility

of visual and textual programs: A test of superlativism

against the match-mismatch conjecture. In Koenemann, J.

et al (Eds.), Empirical Studies of Programmers: Fourth Workshop, pp. 121-146. Ablex.

[25] Green, T. & Petre, M. (1996). Usability analysis of visual

programming environments: A cognitive dimensions

framework. Journal of Visual Languages and Computing 7(2), pp. 131-174.

[26] Moher, T. et al (1993). Comparing the comprehensibility of textual and graphical programs: The case of Petri nets. In Cook, C.; Scholtz, J. & Spohrer, J. (Eds.), Empirical Studies of Programmers: Fifth Workshop, pp. 137-161. Ablex. [27] Kitchenham, B. (2011). What we can learn from systematic

reviews. In Oram, A. & Wilson, G. (Eds.), Making Software - What really works, and why we believe it, pp. 35-54.

O’Reilly Media.

26 [29] Tew, A.; Fowler, C. & Guzdial, M. (2005). Tracking an

innovation in introductory CS education from a research university to a two-year college. ACM SIGCSE Bulletin 37(1), pp. 416-420.

[30] Forte, A. & Guzdial, M. (2004). Computers for communication, not calculation: Media as a motivation and context for learning. Proceedings of the 37th Annual Hawaii International Conference on System Sciences, pp. 1-10. January 5-8, Hawaii, USA.

[31] Guzdial, M. (2003). A media computation course for non-majors. ACM SIGCSE Bulletin 35(3), pp. 104-108.

[32] Rich, L.; Perry, H. & Guzdial, M. (2004). A CS1 course designed to address interests of women. ACM SIGCSE Bulletin 36(1), pp. 190-194.

[33] Tew, A.; McCracken, M. & Guzdial, M. (2005). Impact of alternative introductory courses on programming concept understanding. Proceedings of the first international workshop on computing education research, pp. 25-35. October 1-2, Seattle, USA.

[34] Sloan, R. & Troy, P. (2008). CS 0.5: A better approach to introductory computer science for majors. ACM SIGCSE Bulletin 40(1), pp. 271-275.

[35] Simon, B. et al (2010). Experience Report: CS1 for Majors with Media Computation. ACM Innovation and Technology in Computer Science Education Conference, pp. 214-218. June 26-30, Ankara, Turkey.

[36] Guzdial, M. & Ericson, B. (2009). Introduction to Computing and Programming in Python: A Multimedia Approach. Pearson Prentice Hall.

[37] Guzdial, M. & Ericson, B. (2009). Problem solving with data structures using Java: A multimedia approach. Pearson Prentice Hall.

[38] Fincher, S. & Petre, M. (2004). Computer Science education research. RoutledgeFalmer.