Archive for category Ingeniería

Un Concepto de Ingeniería

Entender la ingeniería como actividad profesional es tan importante como estudiar y ganar las materias que sirven para graduarse de ingeniero. Hay muchas preguntas en la mente de la gente que requiere sus servicios y también en la de quienes se plantean estudiar una carrera universitaria.

Tres aspectos inherentes a la ingeniería pueden servir para definirla.

Ingeniería es: tener la ciencia para determinar dónde estámos - para analizar un problema -, poder diseñar la solución - explorar dónde nos gustaría estar -, y construir el camino que nos lleva de donde estamos a donde nos gustaría estar

Ingeniería es: tener la ciencia para determinar dónde estámos - para analizar un problema -, poder diseñar la solución - explorar dónde nos gustaría estar -, y construir el camino que nos lleva de donde estamos a donde nos gustaría estar

El primero es el aspecto científico. El ingeniero tiene a su disposición herramientas que en general son comunes a investigadores y gente de ciencia pura: el método científico, las ciencias básicas – matemáticas, física, química, ciencias computacionales, estadística, etc. – el conocimiento acumulado que se publica en libros y revistas especializadas, congresos y conferencias donde se ponen en común experiencias y descubrimientos particulares, etc., todo ello le capacita para analizar problemas de diferentes disciplinas.

La segunda faceta del ingeniero es la de diseñador. Dado un problema específico a resolver se deben aplicar criterios, considerar opciones, decidir cuál es la más adecuada y especificar la estrategia para implementarla. Luego se deben atender a un sinfín de detalles de planeación y puesta en común con todos los involucrados, previos al inicio de la implementación de la solución. Todo ello es un proceso de diseño.

En la práctica de la ingeniería ningún problema es igual a otro. Aunque se disponga de soluciones aplicables en multitud de situaciones, siempre es necesario adecuar el diseño o rediseñar de acuerdo a las condiciones particulares. En esto se diferencia de la ciencia pura, que busca precisamente soluciones generales, aplicables siempre y que producen los mismos resultados consistentemente. Por supuesto esto no quiere decir que no sea posible hacer ciencia ingenieril, al contrario, las universidades y los centros de investigación producen ciencia en todas las ramas de la ingeniería, y ésta es utilísima al ingeniero, pero en el ejercicio profesional se requiere algo más que proviene del criterio, la experiencia, la intuición y otras cualidades.

Siempre he dicho que los ingenieros no atendemos lo suficiente a los aspectos estéticos del diseño. Por ejemplo, no es raro que un edificio diseñado por un arquitecto tenga mayor atractivo visual y espacial que el de un ingeniero civil, o que una página de Internet elaborada por un ingeniero de sistemas produzca una experiencia de usuario menos completa que la de un diseñador gráfico. Pero hay otros aspectos del diseño que no escapan al ingeniero: la eficiencia, la funcionalidad, la racionalidad, etc.

Por supuesto esto no quiere decir que no se deba mejorar la formación del ingeniero para que sus diseños sean más estéticos, al contrario, a mi me parece que esta es una seria deficiencia en muchas escuelas de ingeniería y que debe ser subsanada. Lo que quiero decir es que en el diseño ingenieril se da prioridad a lo ético sobre lo estético.

La tercera faceta es el trabajo de construcción y aquí el ingeniero se aparta del diseñador puro, a quien solo le interesa proveer la solución, el ingeniero quiere construir y no se conforma con solo diseñar.

En muchos contextos ingeniero y constructor se consideran sinónimos, por ello, en lo personal prefiero los títulos universitarios de la carrera que empiezan con “ingeniero de” sobre los que utilizan “ingeniero en” porque al sustituir ingeniero con constructor tiene mucho más sentido “constructor de” que “constructor en”. El punto es que un ingeniero es alguien práctico y no un acumulador de conocimientos o erudito “en” una determinada rama del saber.

Resumiendo las tres facetas, una definición de ingeniería sería:

Ingeniería es disponer de la ciencia para analizar un problema, diseñar la solución y trabajar para construirla.

3 Comments

Imagine Cup 2009, a Segunda Ronda

El pasado lunes recibí el tan ansiado aviso de Imagine Cup donde me indican que había calificado para pasar a la segunda ronda.

En la carta también venía un enlace a la página donde se pueden consultar los resultados de todas las categorías menos la de Software Design, que se define hasta hoy miércoles 22.

Carta de Imagine Cup donde me indican que avanzo a la siguiente ronda

Carta de Imagine Cup donde me indican que avanzo a la siguiente ronda

Por curiosidad revisé cómo estaba la participación de Guatemala y la del resto de países de Centro América, además de algunos otros países del mundo. Aquí les presento un resumen, aclarando que es sin datos de Software Design ni de IT Challenge (salvo para Costa Rica):

País Participantes Avanzaron
Guatemala 10 2
El Salvador 7 2
Honduras 6 2
Nicaragua 0 0
Costa Rica 5 1
Panamá 4 1
Belice 0 0
México 62 27
USA 248 76
India 428 108
Japón 610 79

Hay otros países con participación importante pero que no incluí en este resumen.

De momento entonces tenemos dos participantes de Guatemala en segunda ronda, uno en la competencia de Photography, de la UFM, y su servidor en Design, representando a la Galileo. La gente del El Salvador clasificó en Design for Development, y en Design. Los hondureños se metieron en una competencia de alto nivel: Robotics & Algorithm, y el tico en otra no menos complicada: IT Challenge. Claro, no estoy diciendo que Design y Photography no tengan un alto grado de dificultad, al contrario, eso lo demuestra el hecho de que en Design participaron 335 equipos y solo pasaron 150, en Photography 1249, de los cuales clasificaron 224.

En el transcurso de la semana conoceremos los resultados de Software Design, donde se que también hay chapines participando.

La parte importante de la carta, ¡Avancé!

La parte importante de la carta, ¡Avancé!

2 Comments

Publicando en Internet

La revista electrónica Ingeniería Primero ha sido un esfuerzo del Ing. Federico Salazar.

La revista electrónica Ingeniería Primero ha sido un esfuerzo del Ing. Federico Salazar.

Se me ocurrían algunas ideas al terminar de escribir un pequeño artículo para el blog del grupo de científicos que participan en una comunidad en línea que se llama Ciencia en Guatemala.

Como era un artículo sobre computación cuántica y eso es algo que tiene mucho que ver con física moderna, decidí pedirle a Enrique Pazos Avalos, que escribe regularmente allí y que estudia un doctorado en física, que le echara una miradita antes de ponerlo en línea, no fuera a ser que tuviera alguna metida de pata.

Pedirle a alguien que lea lo que uno escribe para obtener una opinión es bastante usual y de hecho yo lo he hecho varias veces para otros artículos que he publicado en otros medios. Cuando no lo hago, por prisa, o por llevármelas de muy pilas, usualmente termino metiendo la pata, como cuando en un artículo para la revista electrónica de la Facultad de Ingeniería de la URL escribí que Heiderberg era el postulador del principio de incertidumbre, cuando el nombre correcto es Heisenberg, eso fue en el artículo titulado “Entradas y Salidas”.

En esa ocasión estaba un poco presionado, no tenía mucho tiempo para escribir y se me estaba terminando el plazo para entregar el artículo. La prisa es mala consejera.

Ahora salió también publicado en la misma revista otro artículo mío siempre sobre computación cuántica que Enrique gentilmente también accedió a revisar.

El blog de Ciencia en Guatemala.

El blog de Ciencia en Guatemala.

Gracias a las tecnologías modernas, cualquier cosa que uno escriba para ponerla en línea es susceptible de recibir una mejor retroalimentación que la que se daba cuando las ideas se ponían exclusivamente en impresos en papel. Lo escrito se puede buscar y encontrar, y al leerlo es posible al menos escribir un mensaje al autor para comentarle cualquier idea.

Pero definitivamente lo mejor es el tipo de discusión que se genera en torno a los blogs. Con ellos uno no puede escribir a la ligera, si es que quiere escribir en serio, ya que cualquier error eventualmente será descubierto por alguien y rebatido. Entre más serio el medio más cuidado hay que poner.

Por eso me gustaría más que Ingeniería Primero, la revista de la URL que mencioné, tuviera un foro donde se pudiera discutir cada artículo. Seguro en el futuro será así. De momento si alguien quiere echarle una mirada a lo que escribo y comentar, pongo aquí la lista de mis artículos:

Hackeando Guatemala sobre el papel de los Hacers en una sociedad como la chapina.

Todos Somos Expertos en Algo sobre un experimento de publicación en Internet llamado Squidoo.

Ingeniería de Sistemas sobre cuáles son las peculiaridades de esta rama de la ingeniería, en este artículo me ayudó Arturo Rivera con la revisión.

Harry Potter y los Lenguajes de Programación es como una especie de interpretación de los libros de Harry Potter desde la óptica de programación y sistemas. Este es mi artículo favorito.

Entradas y Salidas sobre la teoría de sistemas y la definición de sistema. Este es el que tiene el error que apunté arriba sobre Heisenberg.

Computación Cuántica sobre las posibilidades de esta forma de computación.

Espero no haber omitido ninguno. Y bueno, también espero publicar más en el futuro.

No Comments

Usabilidad de los Rótulos en las Carreteras

Este rótulo está cerca de Cocales en Suchitepéquez. Nombres largos como Santiago Atitlán se comprimen, lo que dificulta aún más su lectura.

Este rótulo está cerca de Cocales en Suchitepéquez. Nombres largos como Santiago Atitlán se comprimen, lo que dificulta aún más su lectura.

Recorrimos una vez más las variopintas carreteras que van de la ciudad de Guatemala a la costa sur uniéndonos a los miles de veraneantes que consumieron ávidos los cuatro días y medio de descanso que la Semana Santa nos trae cada año, junto con tradición y vida en familia.

Y una vez más pude comprobar el lamentable estado de esas carreteras.

Pero que arreglen las carreteras es menos complicado que cambiar una práctica incorrecta y hasta perjudicial, porque está casi tan arraigada en la ingeniería de las carreteras como la procesión en el alma del devoto cargador: escribir los rótulos en mayúscula.

Desde los primeros textos que leí sobre factores humanos (ver por ejemplo El Factor Humano, 14 MB) aprendí que la clave está en conocer las capacidades humanas y adaptar los productos de ingeniería para que el usuario no se vea limitado o constreñido por el artefacto, ya que uno de los fines de la ingeniería debe ser solucionar los problemas prácticos de la vida y por lo tanto hacerla más sencilla, no más complicada.

Y por como funciona la visión humana se conoce, desde hace bastante tiempo, que lo que está escrito combinando correctamente las mayúsculas y las minúsculas, siguiendo las reglas de ortografía, que por algo existen, es mucho más fácil de leer que si se usa exclusivamente mayúsculas.

Algunos ejemplos de rótulos en un formato muy parecido al que se usa en las carreteras en Guatemala. A la derecha se ven los contornos de las letras, que es en lo que se enfoca el sentido de la vista para leerlos. Se nota la dificultad para leer las palabras que se deriva de la similitud en las formas y contornos.

Algunos ejemplos de rótulos en un formato muy parecido al que se usa en las carreteras en Guatemala. A la derecha se ven los contornos de las letras, que es en lo que se enfoca el sentido de la vista para leerlos. Se nota la dificultad para leer las palabras que se deriva de la similitud en las formas y contornos.


Pero esto no se termina de entender o de conocer y los rótulos en las carreteras siguen en mayúscula. Los problemas que se derivan de esta práctica son varios:

  • Reducción de la visibilidad del mensaje ya que hay que acercarse más para leer en mayúscula que en texto combinado.
  • Pérdida de tiempo, valiosos segundos que al ir conduciendo en carretera pueden ser cruciales, porque leer en mayúsculas es más lento.
  • Confusiones por letreros mal entendidos (se toma un camino equivocado).
  • Reducción de la velocidad del tráfico para poder leer los letreros.
  • Distracción de la atención del conductor que intenta leer el rótulo.

La razón de que sea más fácil leer textos que combinan correctamente mayúsculas y minúsculas que los que están solamente en mayúscula yace en la forma en que preparamos y procesamos la información visual con el sentido de la vista.

Los mismos rótulos de arriba solo que en minúsculas. En los contornos a la derecha es mucho más sencillo identificar diferencias puntuales entre una y otra palabra, la forma de cada palabra ayuda a leerla completa más rápido.

Los mismos rótulos de arriba solo que en minúsculas. En los contornos a la derecha es mucho más sencillo identificar diferencias puntuales entre una y otra palabra, la forma de cada palabra ayuda a leerla completa más rápido.


Disponemos de células sensitivas especializadas en colores, los conos, y otras especializadas en intensidad de luz, formas y movimientos, los bastones. En la lectura usualmente atendemos poco al color, ya que se usa uno sólo por lo general, y mucho a la forma y al contorno. Es un hecho conocido que no leemos interpretando letra por letra sino palabras completas, que reconocemos por su figura. Al escribir todo en mayúsculas se pierde esa valiosa información de figura y se mete todo en un extraño rectángulo que requiere interpretar letra-por-letra.

En resumen, además de arreglar las carreteras hay que hacerlas más usables, con adecuada señalización y rótulos escritos adecuadamente. Hacer caminos bien asfaltados o de trazo perfecto puede ser una buena obra técnica, pero no es suficiente para hacerla usable. Para esto se requiere tomar en cuenta los factores humanos.

6 Comments

Jef Raskin y las Leyes del Diseño de Interfaces

El libro de Jef Raskin se llama en español Diseño de Sistemas Interactivos: la Importancia de Nuestra Relación con las Computadoras

El libro de Jef Raskin se llama en español Diseño de Sistemas Interactivos: la Importancia de Nuestra Relación con las Computadoras

La semana pasada terminé de leer “Diseño de Sistemas Interactivos” del difunto Jef Raskin (1943 – 2005). Este libro es una traducción de “The Humane Interface: New Directions for Designing Interactive Systems”, y confieso que nuevamente me sucedió lo mismo que con el libro “Presos de la Tecnología” (traducción de “The Inmates are Running the Asylum” de Alan Cooper), es decir, me enteré de las excelentes referencias del escrito hasta que revisé su nombre en inglés. Es asombroso lo mucho que puede cambiar el nombre de un libro cuando lo traducen al español.

Curiosamente ambos libros los compré en rebaja por menos de Q30.00 en la librería del IGA. Tengo que ir más seguido a comprar allí.

Volviendo al libro, me llamó la atención la analogía que Raskin hace entre las leyes de la robótica, postuladas por Isaac Asimov, y las que él considera que deberían ser las leyes del diseño de interfaces:

Primera: Una computadora no debe causar daño al trabajo del usuario, o, por su inacción, permitir que el trabajo del usuario reciba algún daño.

Segunda: Una computadora no debe hacer al usuario perder tiempo u obligarlo a trabajar más de lo que es estrictamente necesario.

Y no hay tercera, al parecer no hace falta más, con solo estas dos podríamos encontrar miles de ejemplos de interfaces fuera de la ley.

El libro también da muchísimos principios de diseño, algunos muy generales, como “los usuarios establecen el ritmo de una interacción”, y otros muy prácticos como “si un control debe operarse siempre, (o nunca) no lo proporcione”.


Esta es la portada de la versión en inglés que dice algo totalmente diferente a lo que dice en español, el contenido del libro se mantiene, la portada ¡nada que ver!

Esta es la portada de la versión en inglés que dice algo totalmente diferente a lo que dice en español, el contenido del libro se mantiene, la portada ¡nada que ver!

Siempre a la caza de nuevos retos de investigación y siguiendo en la línea de mi proyecto científico para el 2009, encontrar la descripción de ZoomWorld que Raskin hace en el capítulo 6, me hizo proponerme hacer una estructuración en metodología DEIU de ese interfaz de usuario.
Indagando un poco más encontré que ZoomWorld es solo una parte del proyecto Archy, también iniciado por Raskin, que a su vez es un ejemplo entre varias interfaces basadas en el paradigma de ampliación o Zooming Interface Paradigm – ZIP.

El primer esfuerzo por construir un ZIP fue el realizado por Ken Perlin, Jim Hollan y Ben Bederson y se llama Pad++, además es el que está mejor documentado y el que se ha mantenido activo por más tiempo.

El mejor conocido, sin duda, es Google Maps y Google Earth, aunque se puede argumentar que no se trata estrictamente de un ZIP sino de una aplicación de técnicas de ZIP para un interfaz de aplicación. Eso es discutible.

De vuelta de nuevo al libro, Raskin presenta un interesante discusión sobre lo que él dice debería ser un Interfaz Humano, como un paso adelante a lo que se podría llamar simplemente interfaz humano-computador. “Una interfaz es humana si responde a las necesidades humanas y es considerada con las limitaciones humanas” en contraposición las interfaces han sido diseñadas tradicionalmente con el enfoque de atender primero las necesidades de las máquinas o los requerimientos de información de los sistemas o el modelo mental del programador. Hay que mejorar la enseñanza de los factores humanos y su aplicación en el diseño en las escuelas de ingeniería de software.

En el libro se tocan otros temas interesantes también, como el de la cognética – la ergonomía de las facultades cognoscitivas – o el de la definición de interfaz de usuario que me interesa particularmente y sobre el que espero escribir en otro artículo.

En resumen, se trata de un libro muy bueno, un auténtico clásico de la literatura de HCI y de usabilidad de sistemas interactivos. Me encantó especialmente un párrafo casi al final del libro, en el capítulo siete, donde se tocan temas diversos, hablando sobre las sofisticadas interfaces de los ambientes de programación modernos y su diferencia con las sencillas herramientas de programación antiguas:

Algo francamente maravilloso se ha perdido: en particular la retroalimentación inmediata que necesitan los humanos a fin de iterar con rapidez su camino hacia un programa efectivo. No soy tan ingenuo para pensar que podemos mantener la sencillez original por completo y alcanzar el nivel de complejidad de los programas que ahora se demanda, pero estoy seguro de que podemos hacerlo mucho mejor que lo que tenemos.

No Comments

El ciclo de ingeniería

Las cuatro actividades principales del ciclo de ingeniería: analizar, diseñar, construir, evaluar.

Las cuatro actividades principales del ciclo de ingeniería: analizar, diseñar, construir, evaluar.

En el 2001, mientras preparaba una presentación que haría en un congreso, me topé con un artículo escrito en 1996 por Keith A. Butler, que influenció significativamente mi visión de la ingeniería y de los factores humanos.
En este artículo, “Usability Engineering Turns 10”, publicado en la revista especializada Interactions de la ACM, Butler explica en qué consiste la ingeniería de la usabilidad y por qué puede considerarse una rama de la ingeniería con todo derecho.
Su argumento básico es que sigue el ciclo de ingeniería. Hasta ese momento la usabilidad era para mi algo así como la aplicación de la teoría conocida sobre factores humanos, computadoras y usuarios para construir sistemas que fueran fáciles de usar y de entender, eficientes y satisfactorios. Pero no la entendía como una ingeniería.
Tampoco estoy seguro de que yo entendiera bien cuál es la esencia de la ingeniería, y eso a pesar de que para ese entonces llevaba ya más de 3 años de haberme graduado y más de 10 de haber cerrado ingeniería y estaba estudiando la maestría.
El ciclo de ingeniería consiste en una serie de actividades que se realizan iterativamente en cada proyecto. En mayor o menor medida el ingeniero las planifica y ejecuta una o varias veces si es necesario, de acuerdo a la naturaleza del proyecto.
Para algunos proyectos de ingeniería el ciclo se ejecuta una sola vez, pero en otros, especialmente en los de ingeniería de sistemas, el ciclo puede recorrerse varias veces hasta alcanzar la solución. Se construyen múltiples prototipos que pueden desecharse hasta llegar a la versión final.

Para algunos proyectos de ingeniería el ciclo se ejecuta una sola vez, pero en otros, especialmente en los de ingeniería de sistemas, el ciclo puede recorrerse varias veces hasta alcanzar la solución. Se construyen múltiples prototipos que pueden desecharse hasta llegar a la versión final.

Butler plantea que sus actividades principales son cuatro: análisis, diseño, construcción y evaluación. El análisis es la etapa en la que el problema a resolver, o sea el proyecto a realizar, se estudia a fondo para entender su extensión, los elementos implicados, las personas a las que afecta y aquellas a las que podría afectar, los recursos con los que se cuenta para resolverlo, las técnicas disponibles que pueden utilizarse, cómo otros han resuelto el problema, los patrones y estándares implicados, etc.
En el diseño se plantea la solución a implementar. A pesar de que la solución puede ser de común aplicación en la industria o para el tipo de problema que se intenta resolver, la adaptación que se requiere para las circunstancias concretas puede implicar una innovación considerable. Si la solución es novedosa entonces resulta innovadora por sí misma. Así que todo diseño de ingeniería siempre implica innovación.
Luego inicia la construcción. Tanto el diseño como la construcción son etapas bien específicas para cada rama de la ingeniería, no se ejecutan igual si se trata de un proyecto de ingeniería química o de ingeniería mecánica y definitivamente no con las mismas perspectivas. Se puede decir que la construcción es la parte administrativa de un proyecto de ingeniería, ya que implica planeación, organización, dirección y control, que son las cuatro funciones administrativas comúnmente aceptadas. Dependiendo del proyecto la construcción puede resultar la etapa más larga.
En la evaluación se hace un examen de cómo se llevó a cabo el proyecto, si se resolvió el problema que se había planteado y si se hizo de una forma efectiva y eficiente. Puesto que no es conveniente dejar esta etapa exclusivamente para el final, ya que ayuda a identificar errores y efectos negativos que es importante resolver tan pronto como sea posible, es común que las evaluaciones se hagan con cada etapa parcial del proceso de construcción.
El ciclo se cierra cuando del resultado de la evaluación se desprenden nuevos problemas que requieren nuevamente de análisis, diseño, construcción y evaluación.
Algunos autores definen un ciclo de ingeniería con más actividades principales de las que se plantearon aquí. A mi me parece que estas cuatro especifican muy bien lo esencial de cualquier ciclo de ingeniería y que de hecho identifican lo que podríamos llamar el método de ingeniería, pero eso será tema de otro artículo.
Encabezado del artículo de Butler, publicado en 1996 en la revista Interactions de la ACM.

Encabezado del artículo de Butler, publicado en 1996 en la revista Interactions de la ACM.

1 Comment

¿Por qué son tan aburridos los libros de programación?

El ciclo de programación son los pasos que se ejecutan iterativamente al programar.

El ciclo de programación son los pasos que se ejecutan iterativamente al programar.

En un día cualquiera, teniendo unos minutos para leer, uno puede tomar un libro de física, de matemática, de biología, un tomo de alguna enciclopedia y hasta un libro de administración de empresas y pasar un buen rato leyendo alguno de los apartados. En general se disfruta, creo que yo sería feliz si pudiera trabajar leyendo en una biblioteca.
Pero cuando se intenta hacer lo mismo con un libro de programación el resultado es muy diferente.
No creo que mi percepción que se deba a que la programación es una de mis grandes pasiones, ni tampoco a que en general se le considera un tópico “complicado”. Lo que creo es que los libros de programación están en general muy mal hechos.
Para empezar la programación es algo eminentemente práctico y por lo tanto no se aprende leyendo teoría sino programando. Usualmente se enseña algo de teoría, pero la relación es más o menos de 20% de teoría contra 80% de práctica. Siguiendo esta fórmula muchos libros de programación parecen una mezcla de 20% de libro de matemáticas y 80% de libro de instrucciones para armar muebles “hágalo Usted mismo”.
En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.

En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.

Luego está el asunto de que siempre tiene que enseñarse un lenguaje concreto, no se puede enseñar programación “en genérico” o una forma de codificación que sirva para cualquiera. Entonces los libros sobre el tema siempre van amarrados a un lenguaje o dialecto computacional y eso los hace altamente vulnerables al paso del tiempo.
Como consecuencia cualquier libro de programación que uno tome del anaquel de una biblioteca probablemente está desactualizado en el lenguaje que utiliza aunque sus conceptos teóricos sigan vigentes la mayoría.
Tomar un libro de programación y pretender leerlo nada más significa que uno tendrá que negarse a poner en práctica inmediatamente los conceptos que están expuestos en él, lo cual no es sencillo porque los ejemplos abundan y no son como los de un libro de física, con el que basta tomar papel y lápiz para “practicar”, lo lógico con la programación es ir a la computadora y programar.
En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.

En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.

Estos libros intentan imponer un orden en la exposición de conceptos, pero en programación las herramientas se utilizan conforme se van necesitando, sin seguir necesariamente una jerarquía de complejidad, así que uno termina usando el libro para encontrar atajos y segmentos relevantes (“hacks”) que son lo que se necesita en el momento, saltándose capítulos y yendo de ejemplo en ejemplo.
Por supuesto, para eso es más útil una referencia del lenguaje, con lo cual el libro de programación pierde buena parte de su razón de ser.
Hay que repensar la forma en que se estructuran los libros y los cursos de programación. Para empezar hay que abandonar completamente la idea de que se utilice exclusivamente un lenguaje concreto como herramienta de apoyo. Algunos lenguajes son mejores que otros para mostrar técnicas como recursión, estructuras de control, manejo de errores, tipos de datos, algoritmos básicos, manejo de números, construcción de interfaces de usuario, etc.
Las pruebas implican ejecutar el programa en variedad de escenarios.

Las pruebas implican ejecutar el programa en variedad de escenarios.

Entonces lo que hay que hacer es enfocarse en la técnica y luego usar libremente el lenguaje que más convenga en cada caso, sea Java, C++, Pascal, Prolog, Basic, SQL, GPSS, Lisp, Scratch, Logo, Assembler, Python, PHP, HTML, Cobol, etc.
Para evitar el problema de que el lector quiera probar cómo funciona el ejemplo hay que cambiar el enfoque y convertirlos en retos del tipo ¿qué hace este código? ¿Qué error tiene? ¿Dónde podría mejorarse? ¿Es eficiente al aumentar la cantidad de entradas? Este tipo de razonamiento inducido es más beneficioso que simplemente copiar el texto en la computadora y ejecutarlo.
Luego hay que centrarse en las competencias básicas de un programador: recorrer el ciclo de programación, diseñar un programa antes de codificarlo, utilizar patrones, leer y entender código que no ha sido escrito por él en un lenguaje que no es el que domina, encontrar errores y depurarlos, etc.
Por supuesto el enfoque no es el mismo si se trata de libros dirigidos a estudiantes de primaria, secundaria o universitarios; si la carrera está relacionada con Ciencias de la Computación o si la programación se toma como una materia auxiliar. Pero definitivamente creo que se puede hacer algo mejor que revisar tediosamente todas las posibles estructuras y comandos de un lenguaje particular, que es lo que hacen buena parte de los libros que conozco.
Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.

Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.

Por último hay que terminar de separar completamente los cursos de programación en dos: la parte teórica en el aula y la parte práctica en el laboratorio – donde lo importante será precisamente ingresar código en la computadora y ejecutarlo – con textos independientes, el teórico con una vigencia mayor que el práctico.
Siempre he dicho que para cualquier ingeniero la habilidad de programar es tan básica como resolver ecuaciones o hacer un diagrama de fuerzas. La diferencia con los ingenieros de sistemas no es más que el enfoque y probablemente la intensidad. Así que tenemos una gran necesidad de buenos libros de programación, bien orientados y que puedan ser leídos con gusto aún 10 años después de haberse utilizado en un curso.
Algún día espero poder escribir un libro así.

3 Comments

El diseño en ingeniería

Feria de Ingeniería en la Universidad Rafael Landívar en Guatemala

Feria de Ingeniería en la Universidad Rafael Landívar en Guatemala

Un diseño es la expresión de una idea que soluciona de forma innovadora un problema concreto y sirve de guía para llevarlo a la práctica, es decir, para construirlo y evaluarlo.

De todas las ramas de la ingeniería, los planos de construcción en las obras civiles son la expresión más popular de diseño. Con el tiempo han alcanzado un buen nivel de accesibilidad y muchísimas personas sin formación técnica pueden entenderlos sin mayor explicación.

No ocurre lo mismo en el resto de ramas de la ingeniería. En mayor o menor grado es posible pasar directamente del análisis a la construcción sin tener un diseño bien especificado.

Probablemente se deba a que el ingeniero es una persona práctica que se apasiona por solucionar un problema en cuanto termina de planteársele. Esta pasión, sin embargo, puede jugar en contra de la eficiencia en el proceso e incluso poner en riesgo todo el proyecto.

El caso más crítico es el de la ingeniería de sistemas informáticos, donde a menudo de hecho apenas se cubre algo del análisis y se pasa directamente a la codificación, que aquí equivale a la construcción.

Un profesor universitario lo resumía de esta forma “their design was the code” o “su diseño era el código”, como tratando de decir que simplemente habían empezado a codificar sin ningún diseño.

Las desventajas de trabajar sin diseño son muchas: falta de una orientación adecuada para el equipo, ya que cada miembro puede tener ideas diferentes sobre lo que se quiere construir; se puede adelantar mucho en la construcción y tener que desecharlo todo por falta de consistencia o porque simplemente se asumió algo que después resulta incorrecto; se le dedica demasiado tiempo a aspectos del problema y se descuida otros de igual o mayor importancia; no hay forma de evaluar si lo que se ha avanzado corresponde en tiempo y esfuerzo a lo que se habría esperado; y un largo etcétera.

Una vez más, hay fallos en la formación universitaria del ingeniero que promueven este vicio. Para empezar muchos profesores alientan a los alumnos a iniciar el trabajo sin exigir que primero se tenga un diseño. Simplemente asumen que no es necesario, que ya habrá otro curso en donde se les enseñe eso o que para el caso particular no aplica.

Los diseños pueden tomar muchas formas: prototipos, maquetas, esbozos en papel, diagramas, dibujos, storyboards (secuencias de dibujos que muestran cómo funcionará el artefacto terminado). En ingeniería de sistemas son muy populares los diagramas UML pero aunque son una excelente herramienta de ninguna forma se pueden considerar suficientes, sobre todo para sistemas interactivos que involucran usuarios. En estos es muy necesario acudir a los bosquejos, prototipos en papel, y otras formas de modelado, para dar oportunidad al usuario final de revisar si lo que espera del sistema es en realidad lo que se está construyendo.

Diseñar implica tomar decisiones. Se escoge una opción y se elimina el resto de posibilidades, para definir el diseño concreto. Estas decisiones implican criterio, compromiso y responsabilidad. Criterio porque no se pueden tomar simplemente por gusto o por conveniencia propia. Compromiso porque la decisión tomada debe acompañar todo el ciclo de ingeniería hasta la evaluación final, estando preparado para recibir cuestionamientos si hace falta. Responsabilidad porque las decisiones tomadas afectarán no solo a la obra construida sino a todos los involucrados, incluyendo a los usuarios finales.

En una conferencia del Dr. Fernando Cajas le escuché decir que más que matemáticas y física – materias tradicionalísimas en las escuelas de ingeniería – lo que había que enseñar era cómo diseñar.

Diseñar en ingeniería es idear un artefacto que resuelve un problema concreto – en oposición a un problema general, que estaría más relacionado con investigación. Enfocarse demasiado en las habilidades numéricas y los problemas abstractos que presentan las matemáticas y la física solo confina a los estudiantes a un ámbito muy restringido del universo de situaciones que enfrentan los ingenieros como profesionales. Lo peor que podría pasar es que ellos creyeran que de eso se trata la ingeniería.

Por supuesto que tiene muchísimo que ver con matemáticas y física, pero definitivamente va mucho más allá.

2 Comments

Trabajo en equipo e ingeniería

Alumnos de un curso de electrónica preparándose para presentar su proyecto

Alumnos de un curso de electrónica preparándose para presentar su proyecto

La ingeniería hoy en día implica necesariamente el trabajo en equipo. Aunque algunas de las actividades de análisis y diseño se pueden realizar individualmente, sin consultar con nadie, valiéndose únicamente de la propia creatividad y experiencia, el resto del trabajo en el ciclo de ingeniería requiere en la gran mayoría de casos de otras personas que colaboren en la empresa.

Los ingenieros deberían ser personas acostumbradas a trabajar en equipo, pero lo extraño del asunto es que en general, en las escuelas de ingeniería, se le pone poca atención a enseñarle al futuro profesional cómo trabajar en equipo. De alguna forma se asume que el estudiante ya sabe cómo hacerlo, que lo aprenderá intuitivamente o que quizás no es que deba “aprenderse” sino más bien se trata de algo a lo que hay que “acostumbrarse”.

Hay que distinguir el “trabajo en equipo” del “trabajo en grupo”. El segundo es muy fácil de reconocer: una pequeña porción de los integrantes de verdad trabaja, o hace el esfuerzo por trabajar, y el resto funciona como asistentes o personal de apoyo y que cuando no tienen una tarea concreta asignada se dedican a cualquier cosa que se les antoja.

Los grupos de 5 personas para hacer una tarea en la universidad suelen estar organizados así: uno trabaja, otro prepara comida para todos, otro pone la casa, otro hace de chofer y el último no hace nada. Con ligeras variaciones esto es bastante estándar.

Y es una pena, porque la mayor parte del tiempo en la universidad o en los últimos años de colegio se la pasa uno haciendo trabajos en grupo y podría estar sacándole provecho a esa experiencia aprendiendo a trabajar en equipo.

Los verdaderos equipos se caracterizan por varios factores clave:

  • Tienen una meta en común y es bien conocida por todos. Todos saben hacia dónde van, qué ruta están siguiendo – conocen no sólo el objetivo final sino las metas intermedias – y cuál es la situación actual. Las razones por las que desean alcanzar un objetivo determinado han sido discutidas y aceptadas por todos y una vez que eso ha ocurrido no se discuten más, aunque pueden ser revisadas si la situación lo amerita.
  • Cada cual sabe qué papel desempeña y lo considera importante. En un verdadero equipo no hay tareas pequeñas o grandes, todas son importantes y valiosas.
  • Todos respetan y valoran el aporte de los demás. Esto se deriva del punto anterior. Como no hay tareas grandes o pequeñas, el aporte de cada uno es apreciado como contribución para la consecución del objetivo que se busca. De este respeto se deriva la confianza en que cada miembro realizará sus tareas de la mejor forma posible y con responsabilidad.
  • Se ejercita el liderazgo. El liderazgo se entiendo como la capacidad de guíar, conducir y motivar a un equipo. La base del liderazgo no es la autoridad impuesta por la fuerza o por el deber, sino el auténtico deseo de servir y ayudar al equipo a conseguir el objetivo. Por eso hay muchas formas de liderazgo, algunas se basan en el conocimiento, es el caso de las personas cuyo consejo y orientación se estima, en el carisma de quien ayuda al resto a adoptar una decisión difícil porque transmiten su propia seguridad, etc. El liderazgo en los verdaderos equipos no es estático, ya que puede cambiar en función de las circunstancias.
  • Comunicación. La información es la base de la coordinación de esfuerzos. Los buenos equipos acostumbran a detener su trabajo para que cada miembro informe al resto de los progresos que ha alcanzado, de los problemas que enfrenta y de los soluciones a las que ha llegado. Esta comunicación permite el enriquecimiento de las tareas de los demás.

Esta lista no pretende ser exhaustiva, y de igual forma, este artículo no es un tratado completo del trabajo en equipo. Hay muchas cosas más qué decir sobre el trabajo en equipo. De momento baste este pensamiento: el trabajo en equipo es una poderosa fuerza que podemos explotar para conseguir grandes obras de ingeniería.

, ,

1 Comment