jueves, 19 de marzo de 2009

Ingeniero o Arquitecto

Son muchas las comparaciones que se hacen entre el desarrollo de software y la arquitectura o la construcción de edificios/casas/etc., de hecho el término "Arquitecto de Software" proviene de dicha disciplina. En este post voy a tratar de explicar por qué me parece que está mal utilizado este término (como muchas otras analogías que se hacen con esa disciplina). 
Este tema me vino a la cabeza luego de la clase de ayer en la UBA cuando conversábamos sobre qué significa que un modelo sea bueno. Recuerden que desde nuestro punto de vista, el software es un "modelo computable" de un dominio de problema de la realidad, por lo tanto debe cumplir con ciertas características para ser un buen software. Por un lado, debe cumplir con las mismas características con la que se juzga cualquier modelo, no solo los computables, esto básicamente significa que pueda representar correctamente lo que modela. Pero también existen características que debe cumplir por ser computable que tienen que ver con performance, uso de recursos, etc. 
Es interesante ver que generalmente en las carreras de sistemas nos enseñan como lograr buenas características computables de los programas que realizamos como que sean performeantes, etc., pero rara vez existen materias en donde nos enseñen a crear un buen modelo. Justamente este tema es el que ataca nuestra materia.
¿Qué tiene que ver todo esto con los arquitectos?, bueno, el rol que "actualmente" vela porque un sistema tenga buenos atributos computables, es lo que llamamos "Arquitecto". Es él quien debe asegurar que el sistema sea performeante, que escale bien, etc. Es el que se encarga de los temas de infraestructura del sistema.
Analizando un poco el mundo de la construcción de edificios/casas/etc., se puede ver que el encargado de asegurar que estas construcciones "no se caigan", que las estructuras sean las correctas, etc., o sea que todo lo relacionado con la infraestructura sea correcto, no es el arquitecto si no el ingeniero civil. De hecho, los planos de estructura, vigas, etc. deben estar hechos por un ingeniero civil y no por un arquitecto! El arquitecto generalmente se ocupa de hacer que el edificio/casa/etc. sea funcional, "lindo", aproveche bien los espacios, etc., todas características que no tienen nada que ver con la infraestructura en si... (Los arquitectos son también quienes generalmente llevan el proyecto adelante, pero ese es otro tema).
Por lo tanto, si lo pensamos detenidamente y no me equivoque en las responsabilidades del arquitecto y el ingeniero civil, utilizar la palabra Arquitecto dentro de nuestra profesión para indicar el rol de la persona que se encarga de definir la infraestructura del sistema parece ser equivocado, puesto que de donde proviene, esa palabra no es utilizada para dicho rol. El nombre utilizado para nombrar a la persona que cumple ese rol es Ingeniero Civil, por lo tanto sería mejor llamar al rol similar en el desarrollo de software  "Ingeniero", pero claro, dicho término tiene otra connotación en nuestra disciplina y está más relacionado con la persona que se encarga de construir un sistema, que el sea usable y por que no, llevar adelante un proyecto... ups! pero eso es lo que hace un arquitecto en el ámbito la construcción!
¿Me estoy perdiendo algo o realmente estas palabras están mal usadas en nuestra profesión? ¿No deberíamos llamar ingeniero al arquitecto de software y viceversa? ¿qué les parece?

jueves, 12 de marzo de 2009

Jornadas Agiles

El fin de semana pasado se realizaron unas Jornadas Agiles utilizando una organización muy interesante denominada Open Space.
La idea de esta técnica es que los participantes mismos decidan como será la jornada, decidan los temas y la agenda de cómo serán tratados. Inicialmente parece medio loco no?, algo que va en contra de la idea de tener todo organizado de entrada y bien definido, una característica que buscamos quizá por una cuestión de enseñanza y no por vivencias propias.
Les comento que la organización terminó siendo buenísima. La gente propuso los temas, la agenda se armó de manera colaborativa y no llevó más de 1 hora y media hacerlo con 100 persona y con 25 temas en total (creo). Pero lo más importante aún, desde mi punto de vista, es que no hubo exposiciones (salvo algunas como la mía que intenté hacerla más colaborativa y no lo logré) sino reuniones donde todos opinaron y colaboraron, lo cual generó muchas ganas de participar y un ambiente muy motivador... esta motivación me hace acordar a cuando se realiza pair-programming o sesiones de diseño grupales.
En fin, se utilizó una técnica que tiene mucho que ver con el espíritu ágil y que tenemos ganas de utilizarla por lo menos para un día en el congreso de Smalltalks de este año... así que vayan pensando temas!

Sesiones de Diseño II - TDD en Vivo

Ya vamos por la tercer sesión de diseño y realmente ha sido muy interesante. (Un amigo, JP, suguirió que debería llamar al post "TDD en Vivo", por eso lo adjunté al nombre).
Es muy interesante ver como cada grupo fue tomando distintos caminos y concentrándose en distintos problemas. Sin embargo hubo una característica común que permitió avanzar rápidamente en todos los casos y que soluciona el error principal que se cometió en la primer sesión: se empezaron a hacer test más sencillos y cortos. Fue muy interesante ver cómo al hacer tests más cortos se lograron mejores resultados y la gente se motivó mucho más. Aunque el avance esencial haya sido poco, el hecho de haber creado muchos tests y que den verde indudablemente afectó la moral del equipo. Es algo que Kent Beck ya había comentado cuando propuso esta técnica y que nuevamente estamos confirmando.
Por otro lado es muy interesante ver que los diseños en general no varían mucho, hay diferencias de nombres pero el problema está siendo resuelto de manera similar en la mayoría de los casos por los distintos grupos. También fue muy interesante ver con un grupo, como se entendió mejor y hasta se simplificó partes de código muy complejas simplemente factorizandolas con un extract method. Nuevamente hacer extract method y estar obligado nombrar (darle un significado) a un conjunto de colaboraciones  difíciles de entender o poco declarativas, ha demostrado ser una técnica muy valiosa.
Los mantendré informados!

The real crisis? We stopped being wise (Barry Schwartz)

Hace unas semanas hubo una charla muy interesante de Barry Schwartz donde comenta lo importante de ser "inteligentes" por más de que existan "métodos" o "procesos" que nos digan cómo tenemos que trabajar o actuar. Un charla imperdible:  http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html

miércoles, 4 de marzo de 2009

Lunes 16/03, 17:00 hrs: Defensa Tesis de Satori: un Ambiente de Aprendizaje de Objetos

Invitamos a todos a la defensa de la siguiente tesis de licenciatura, que
se llevará a cabo el Lunes 16 de Marzo a las 17:00 hrs, FCEyN, aula a
confirmar:

Título: "Satori: un Ambiente de Aprendizaje de Objetos"

Alumnos: Burella, Juan y Olivero, Fernando
Director: Hernán Wilkinson
Jurados: Máximo Prieto, Gabriela Arévalo
--------------------------------------------------------------------
Resumen
El paradigma orientado a objetos es actualmente uno de los paradigmas de desarrollo más utilizados en la industria y en la educación, hecho que determina la importancia de su enseñanza. Se puede afirmar que a pesar de haber transcurrido varias décadas desde su aparición, su enseñanza aún genera desafíos pedagógicos, los cuales se ven influenciados por condiciones externas que dificultan la generación de los resultados esperados. Estos inconvenientes no son inherentes al paradigma sino que, en la mayoría de los casos, son manifestaciones de las carencias que existen en las técnicas y herramientas utilizadas para enseñarlo. 

En este trabajo se han analizado varios ambientes, entornos y herramientas utilizados actualmente para su enseñanza, documentando los beneficios y déficits que poseen para cumplir con los objetivos que, según nuestro punto de vista, deben cumplir para tener éxito en la transmisión de este paradigma. Debido a los déficits encontrados, es que vimos la necesidad de crear un nuevo ambiente de aprendizaje, lo cual nos permitió simultáneamente detectar una serie de requerimientos que entendemos estos ambientes deben satisfacer.

Satori es por lo tanto el resultado de este trabajo de investigación y desarrollo, al cual lo podemos considerar un ambiente de objetos "puro". Éste, reifica cada uno de los conceptos básicos del paradigma e intenta reflejarlos de la forma más simple y directa posible. Incorpora, desde su concepción, características que pretenden promover la exploración y manipulación como metodología de adquisición de conocimiento y su modalidad de uso expresa la metáfora más importante del paradigma: objetos que colaboran entre sí enviándose mensajes. De esta manera los usuarios del ambiente pueden llevarse un panorama global de qué es el Paradigma Orientado a Objetos, reconociendo a los objetos y los mensajes como las entidades fundamentales.

El ambiente de aprendizaje de objetos Satori, ha sido además desarrollado en un sistema tridimensional colaborativo denominado Croquet. Esto permitió la representación en tres dimensiones de los elementos básicos del paradigma, ofreciendo por lo tanto herramientas de inspección y manipulación naturales, principios básicos del modelo pedagógico constructivista. Ofrece también todas las herramientas necesarias para la colaboración virtual entre personas, facilitando y permitiendo compartir el conocimiento adquirido durante el aprendizaje.