Que quiero ser cuando sea grande profesionalmente hablando

Definitivamente estoy en crisis (cambio) llegando a los 30, un segundo hijo (luz), all boys en primera y profesionalmente aturdido. Muchas veces dije lo que quiero ser o adonde apunto, y estoy seguro que lo tengo claro, al menos la visión la tengo.
Y no se si lo puedo describir en tan solo una palabra, pero lo más que se le parece es a lo que en IBM, Oracle, Sun, Microsoft llaman Fellow, es un puesto de mucha categoría que se la otorgan a técnicos reconocidos en la industria que poseen un gran liderazgo y han aportado con técnicas, productos o metodologías para la mejora. Y sobre todo poseen una visión del futuro tanto del negocio como de la tecnología.
Obviamente para llegar a eso tengo que crecer muchísimo, vivir nuevas experiencias e involucrarme en otro tipos de actividades que no estoy haciendo actualmente. En mi todo list tengo lo siguiente, se aceptan consejos:
1) Hacer un Doctorado - Esto lo vengo pateando y analizando, definitivamente no quiero hacer un master, considero que investigar y tratar de unir el gap entre lo académico y la industria podría ser muy interesante. Definitivamente la ciencia/academia solo no me interesa por el momento, al menos no en Argentina.
2) Relacionarme más con el negocio (client facing). Participar más en ciclos de venta, pre-venta, entender los diferentes contextos de las empresas y ver como ofrecer soluciones. Realizar consultorías, evaluaciones y recomendaciones en diferentes empresas.
3) Tener un puesto de Arquitecto Empresarial. Este es uno de los objetivos de largo plazo, me interesaría muchísimo formar parte de un equipo de arquitectura empresarial para tomar decisiones de alto nivel y ver como IT puede bajar costos alineándola con el negocio de la manera más ordenada.
4) Enseñar, enseñar, enseñar. Amo la educación, compartir mis conocimientos y ayudar a pensar. Pararte adelante de un grupo de profesionales y transmitir un mensaje tiene un desafío muy grande día a día.. Como siempre digo, los conocimientos van y viene el criterio no.
5) Reconocimiento de la industria a través del aporte. Escribiendo artículos y libros, dando presentaciones, teniendo un blog (bueno, no como este) haciendo networking, contribuyendo en el open source y publicando patentes creo que va a ser la manera en la cual voy a lograr esto.

En fin, vamos a ver como salgo de esta crisis y veo de que manera estoy parado de un tiempo aca. Aclaro que el plan es de acá a 20 años o más, voy a estar ocupado, no?

Buscando la certificación de IT Architect

Como comenté en un post anterior, a principio de año submití un paquete de 40 páginas sobre mi experiencia, conocimientos, skills, educación y otras cosas más para certificar en la carrera de arquitecto en IBM donde tuve que describir mis 10 años de experiencia en IT y con más detalle los últimos 4 años como arquitecto. La primera revisión pasó sin problemas, pero cuando tuve las 3 entrevistas con otros 3 "colegas" no me fue tambien, y terminaron declinando mi certificación. Era esperable, el proceso es muy tedioso y como toda certificación, en algunos aspectos tiene temas muy "fordistas" y "metodológicos" que si no usas los nombres correctos para ciertos elementos te penan muchísimo. En fin, el proceso es bastante transparente y sigo creyendo y es por eso que el més que viene vuelvo a presentarme. Ahora bien, que fue lo que determinaron que no sabia? bueno aca les dejo un detalle:
1) No tengo experiencia aplicando una metodología de diseño para crear arquitecturas.
2) No trabajé con muchos tipos de arquitectuas y plataformas.
3) No conozco los "key trend" de las industrias en las que trabaje.
Estos son tres puntos de veintipico de otros requerimientos. Obviamente estoy de acuerdo con el último punto, el 3, que la verdad no le di ni bola cuando armé mi paquete y ni lo charlé con mi mentor, sabía que ese punto no lo tenia claro.
Con respecto a los otros dos, me sorprendí muchísimo, debido a que en IBM doy cursos explicando la metodología de diseño de arquitectura y a su vez apliqué y conozco otros como Agile Modeling y ADD. Y el 2do punto, tambien de pareció ridículo, pero luego vi que mi paquete no estaba taaaaan claro que tengo experiencia en varias plataformas y tipos de arquitectura (batch, fat client, thin client, 3 tier, client-server), en fin, fue un golpe muy duro cuando recibí el resultado y 2 de los 3 puntos que no pasé eran incorrectos y fallé en la comunicación. Ahora bien, el 2 de Julio arranco el proceso nuevamente con el objetivo de obtener la certificación junto a mi mentor Kenn Roberson que me ayuda, cochea y contiene en mis momentos de catarsis desde Dallas.

Y que hace un líder técnico?

A los largo de mis casi 11 años trabajando en IT, los roles que forman mayor parte de mi CV y que realmente tengo formación, están relacionados como Líder Técnico y Arquitecto. Por un tiempo los hice al mismo tiempo pero finalmente me terminé quedando con el de Arquitecto, que realmente es muy diferentes al de liderazgo, y aunque creo que ambos necesitan skills duros que se pueden formar, creo que los factores fundamental para tener el rol es el sentido común y la pasión por lo que haces, de nada sirve ser un referente sin poder transmitirlo en los aspectos y decisiones del día a día, es algo que no puede ser forzado.
Por otro lado, hay algo que podes hacer como líder que no podes hacer como arquitecto. Para ser arquitecto necesitás calle, experiencia, años de vuelo trabajando en diferentes momentos (en la industria), diferentes metodologías, tecnologías... aunque como líder, para hacerlo bien, tenes que tener la vocación y el don para hacerlo. Cuando uno es un líder natural todo es más simple y no fuerza sus decisiones diarias, le salen naturalmente y busca el bien común, no el propio.
En mi caso particular me costó/cuesta mucho más ser Arquitecto que lo que me costó ser líder técnico, quizá por mi inclinación democrática socialista que me hacer ser transparente y realmente creer en lo importante del equipo y no de las individualidades. Día a día yo me esfuerzo para ser arquitecto, pensando mis decisiones en todo momento del día, capacitándose, dando clases, etc. Pero cuando era líder todo me iba más natural.
Ahora bien, hace unos años debí tomar una decisión en la cual tuve que tomar un camino, si el del liderazgo puro/management o arquitecto (técnico), me costó, pero me fui por el del Arquitecto, ya que siendo líder el techo del crecimiento en lo técnico (por algo soy ingeniero) es muy bajo, rápidamente se convertís en un burócrata siguiendo procesos y donde la creatividad se deja de una lado, cosa que no pasa con el arquitecto, o lo que quiero ser en un futuro (ya voy a hablar en otro post).
En fin, hasta acá vengo aburrido con mi vida que no es ejemplo para nadie, pero más de una vez he recibido la pregunta, y que hace un líder técnico? bueno, aca traté de recopilar las actividades y responsabilidades que yo considero importante para este rol. Con respecto a las responsabilidades:

1. Formar el equipo. Creo que es actividad más importante de un líder es contar con personas capaces de hacer su trabajo y buscar complemente entre las fortalezas y debilidades de cada integrante.
2. Proveer guía y soporte técnica al equipo. No concibo tener un líder que no sepan lo que hacen los integrantes, tampoco creo que el líder debe ser el mejor técnico, pero si debe tener el conocimiento para destrabar y resolver problemas impartiendo prácticas que mejoren la calidad del trabajo. Repito, no debe ser el mejor técnico, pero si de la media para arriba.
3. Estimar, Asignar y planificar tareas. Muchos líderes creen que esto es lo único que tienen que hacer, aparte de controlar que se hagan. Definitivamente creo que esta es una de las tareas menos importantes del líder. Un equipo bien configurado no necesita a un pelmazo que lo único que haga es asignar y controlar. Acá es importante emplear sus conocimientos para poder estimar y tener la grandeza para consultar a sus integrantes y generar comprometimiento de grupo.
4. Coordinar (no controlar) las tareas. Aca hay otro punto escabroso, y es una de las cosas que más odio del liderazgo, el control. Se supone que en software la gente que trabaja es profesional y responsable de su tarea y no debería ser controlada y ser preguntada por el progreso, cualquier desvío que ocurra debería ser notificado en el momento justo para tomar acción. Obviamente no siempre es así, la gente es jodida y no siempre tira a un mismo lado, con lo cual creo hay que ser muy cuidadoso con el punto 1. Acá puedo escribir mucho más, pero no tengo ganas... quizá en otro post :)
   
5. Peer Review. Si bien esto es un tema delicado para los agilistas, yo considero que los peer reviews son necesarios y la frecuencia debería varias de acuerdo al nivel del proyecto con el uso de herramientas de análisis de código. Los beneficios de las revisiones de código o trabajo, son buenas desde muchos puntos de vista, no solo mejorar el deliverable sino transferir conocimiento y buscar consistencia, como arquitecto participo y me gusta mucho.
   
6. Definición de las normas de convivencia. Cada equipo tiene sus normas, reglas y procesos a seguir, el líder debe coordinar las tareas necesarias para generarlo y asegurarse que sea beneficioso para el equipo. Acá entran temas de la organización, y el ecosistema en el que está inmerso el equipo. Un equipo en donde se pueda generar un ambiente sano de aprendizaje constante donde nadie es penado por equivocarse es difícil de lograr, esa armonía es muy importante y no se puede escribir en un wiki con el resto de las reglas. Pero va a depender mucho del líder y los detalles propios del equipo.
   
7. Preocuparse por el crecimiento profesional de los miembros del equipo. Esta es una de las responsabilidades que más me gustaba como líder y donde estoy seguro que di lo mejor de mi por muchos años. Es muy importante como líder saber las aspiraciones de los integrantes del equipo y tratar de unir las actividades diarias con dichas aspiraciones. Obviamente no siempre los integrantes saben sus aspiraciones, con lo cual es importante ayudar a definirla, hablar de visión acá es un poco apresurado, pero importante. Aca también entras técnicas como el coaching, de acuerdo a la urgencia muchas veces es mejor dar la caña de pescar y no el pescado .
   

En fin, estas son las actividades que todo líder técnico tiene que hacer y precuparse por mejorar, los que estén trabajando con dicho rol, los invito a realizar una auto-evaluación y ver que tan bien están en cada uno de los aspectos listados. Por supuesto si tienen otras responsabilidades para agregar, no duden en comentar.

Arquitectura de Software, ciencia? ingenieria? arte? o alquimia?

Siempre es un tema que sale con birras de por medio y nunca llegamos a la conclusión, digamos que:
1. Es ciencia? La verdad que no, sin entrar en detalle en la definición, la arquitectura de software está claramente lejos de la formalización, gracias adiós, jamás podría pensar un modelo formal para manejar las variables que se consideran para crear una arquitectura, y menos que eso poder validarla. Aunque hay ciertos aspectos de la ciencia que si son interesantes y se usan para tomar decisiones, se me ocurren temas de disponibilidad.
2. Es una ingeniería? Aca creo que nos vamos acercando un poco, aunque todavía no creo que el software haya llegado a la ingeniería todavía, siendo ingeniero (de sistemas, no de software) podría decir que nos falta mucha madurez para tener un un método que me permita obtener el mismo resultado (o parecido) y asegurar la completitud de las necesidades. Obviamente esa es la manera conservadora de ver la ingeniería.
3. Es un arte? Aca estamos un poco más cerca, definitivamente... el proceso de creación de arquitectura está más cerca de la creatividad que de los metodos formales de diseño. En que cabeza cabe que el diseño puede ser "formalizado" y definido en un proceso? Está claro que pueden haber guias, experiencias documentadas, ejemplos, maneras de comunicar un diseño, pero ahora tener un proceso (input-X-output) repetitivo en diferentes contextos y situaciones, yo no creo. Ahora tampoco creo que es puramente artístico la creación de la arquitectura, se supone que debemos que elegir la solución más simple, con mayor reuso (assets, patterns, estilos, etc) y restringidos por tiemos y costos, esta ultima parte destruye (felizmente) la fumatina de los arquitectos. Que según Esteban Lorenzano "Arquitecto con tiempo es más peligroso que mono con navaja"

Ahora bien, si bien creo que la arquitectura de software tiene algunos componentes de la ciencia, se podría decir que está muy cerca de la ingeniería y tiene mucho del arte, he llegado a la conclusión que yo a la arquitectura de software encasillaría dentro de lo que es una alquimia, por que? bueno.... algunos puntos:

• La alquimia se basa en algunos aspectos de la ciencia, sobre todo las bases
  
• La experiencia y sabiduría de quien la practica es el elemento fundamental de la alquimia
• Arte, que más decir aca la alquimia definitivamente está muy influenciado por la creatividad y la constante expresión
• El aprendizaje constante de nuevas técnicas
• La búsqueda del resultado/transformación más apropiado
  
• La amplitud recibir y compartir experiencias místicas dentro del proceso

Bueno, este es mi aporte del mes :) opiniones/insultos más que bien recibidos/as

Terminando el año 2009 en MDQ

No quería dejar de escribir un post a este pobre y desconocido blog con las cositas que estoy cerrando y planificando para el año que viene, si esperan leer algo técnico, olvidenlo es más bien personal.
En lo que queda del 2009, estoy con un par de cosas:

1. El más importante, estoy terminando mi paquete de certificación de arquitecto en IBM que la verdad es una goma (cansador) ya lo tengo a un 70% y me quedan 4 días. Básicamente es un grán CV en donde tengo que demostrar que tengo los skills, cursos, experiencias diseñando soluciones con diferentes tecnologías, entornos, metodologías y todo lo que se les pueda ocurrir. Lo interesante es que si luego de 3 entrevistas, revisiones y otras cosas más me certifican, automáticamente me convierto en Master Certified IT Architect del Open Group, que digamos no sería poca cosa (si bien descreo de las certificaciones) creo es de lo más serio que vi de certificaciones.
2. El el proyecto en el que estoy, estamos dentro de 3ra iteración de la release y viene todo tranquilo, que se puede esperar de una iteración de 2 semanas con 6 días laborales, ahora estoy trabajando en los diseños preliminares (o estratégicos o arquitecturales) de la próxima iteración.
3. Finalmente estamos implementando TDD en un proyecto bastante grande, con alrededor de 16 desarrolladores, ya voy a contar como lo encaramos pero armamos un modelo con capacitación, mentores e implementación gradual de TDD que puede andar.
4. Personalmente, lo mejor VOY A SER PAPA otra vez :) calculamos para fines de de Julio tener un pirata o princesa (así le dice andrés)

Para el 2010, si bien no lo tengo bien definido, pero voy a tener cambios, mi plan B original era comenzar un doctorado, y seguir la materia más de costado, pero por el momento lo voy a tener que atrasar un poco, seguramente siga buscando mi plan A que es vivir en el exterior un tiempo, idealmente USA pero si no sale como se viene postergando, intentaremos con Europa.
Seguramente siga molestando con Ruby (junto con Damian y Marcia) y por que no comenzar a dar cursos por fuera de IBM, pero de cosas que me gustan como Ruby, Metodologías Agiles, TDD y Arquitectura, y obviamente me tengo que poner un poco a tono e investigar un poco más, creo que estamos en un parate, donde temas que me interesaban ya los aprendí e implementé, ahora no veo nada que me despierte interes, lo cual me pone un poco mal pero por otro lado me desafía a pensar al desde cero, en fin... ya tendré tiempo de delirar un poco.

Les dejo un gran abrazo a todos y que tengan un lindo año nuevo.

Pensando Arquitecturalmente

Es así como se llama (en inglés) el curso que voy a dar esta semana por tres días, en catalinas, arrancando el Lunes 14 de Diciembre. Básicamente es un extracto de APIT en 24 horas pero con muy alineado a los procesos, frameworks de arquitectura y metodologías de IBM. Realmente este es un curso que a mi me abrió la cabeza allá por el 2005 y mañana lo voy a dar por 4ta vez.
Es un curso que combina teoría, practica y discusión muy muy interesante, es el mismo que fui a dar a Perú en Septiembre.
Lo interesante de esta vez es que al 60% de los arquitectos y futuros arquitectos que voy a tener como participantes los conozco y los vi crecer en IBM... la verdad que me siento muy bien en poder compartir mis conocimientos y experiencias a los largo de 5 años pensando como arquitecto y obvio haciendo algo que me fascina.
El curso consta de 10 módulos donde más o menos:
1) Se introduce a la arquitectura de IT
2) Requerimientos Funcionales
3) Componentes Funcionales
4) Diagramas de Arquitectura
5) Componentes Operacionales
6) Requerimientos no Funcionales
7) Evaluación y Verificación de Arquitecturas
8) Proceso de Arquitectura
9) Herramientas para construir y comunicar arquitecturas
10) Rol del Arquitecto
Así que ahora estoy un poco repasando los módulos que me tocan y tratando de estar a tono para poder dar un buen curso y sobre todo disfrutarlo ya que van a ir mentes brillantes al curso que me van a hacer pensar mucho, cosa que a esta altura del año me cuesta :)
Bueno, esto es todo.... quería compartir lo que estaba pensando por mi cabeza en este momento.

Panel: Frameworks MVC - UBA SIS

El Viernes 28, a las 15hs vamos a estar en la UBA (AULA E24, PABELLÓN I de CIUDAD UNIVERSITARIA) con Esteban Lorenzano, charlando nuevamente de Ruby on Rails y Seaside, esta vez vamos a compartir un panel con otras personas que van a hablar de .NET y Seam. Acá hay mas información del Evento.
La verdad que puede llegar a resultar interesante, sobre todo si se llega entender que es lo mejor que ofrece cada framework y llegar a la conclusión de las buenas prácticas a seguir a la hora de desarrollar Web App y que el MVC no sirve para nada :) jeje, solo para molestar.
Con respecto a Rails, la implementación de MVC tampoco me cierra del todo, creo que la idea de Wicket es un poco más interesante, en fin, veremos que sale de este panel.
La otra duda que tengo es que se entiendo por MVC, pero eso lo veremos discutiendo calculo, yo por lo pronto voy a presentar el modelo de MVC de Rails (bien Struturado) y los principios del framework que me parece que es lo más interesante, seguramente me pelearé con Esteban por el uso o no de Templates (que los banco a bastante) y lo molestaré un poco con lo importante de tener urls RESTful :P
Los espero!

Por que existen los Arquitectos de Software?

Luego de dos semanas de mucho trabajo (por suerte lindo) llegué a una conclusión hablando con un colega....

"Yo creo que el rol del arquitecto se creo por la ineptitud de los PMs que dejaron de interesarse en los Sistemas (Solución que están construyendo) y el overhead metodológico causado por la poca confianza entre el cliente y el team del proyecto.... creo que si las metodologías agiles toman fuerza, los dos roles se pueden volver a unificar al mejor estilo Brooks"

ehhhhh dicho :) perdón pero estoy quemado

Cerrando el año - Lo bueno

Estamos terminando el año y si bien no me gustan los balances pero tengo el blog un poco descuidado, voy a compartir mis buenos y malos momentos resumidamente.
Primero las buenas:

• Como Padre este año siento que crecí muchísimo, ya Andrés comenzó a depender mucho más de mi y yo logre pasar muchos de los miedos de que la madre no esté. Ya dice que es hincha de All Boys (aloy), pide jugar el Futbol (ubol), juega a la play (apei), me llama a la noche cuando no se puede dormir (bue, eso no es tan bueno). Creo que lo que queda ahora en más va a ser genial, todavía tengo mucho por mejorar pero creo que estoy mucho mejor que antes.
  
• Tuve mi primera release como Arquitecto formalmente nombrado y se pudo cumplir con el objetivo de la versión que llevamos a producción. Realmente no fue nada fácil, mucha política, gente nueva, revisiones de arquitecturas, presentaciones a más de 50 personas de todo el mundo por teléfono, desarrolladores alrededor del mundo, etc, etc, etc a veces es muy dificil ser arquitecto y buscar el tiempo para bajar a tierra y escribirse un par de test cases, pero de vez en cuando me dí el lujo de hacerlo :)
• Ruby2Real, este año me pude dar el lujo de llevar a la realidad a Ruby, hicimos varias cosas en IBM y ya forma parte de la estrategia como para comenzar a vender servicios en dicha plataforma. Junto con Damian Garcia y Leandro Godon armamos planes de capacitación, capacitamos, creamos dos aplicaciones internas que todavía no se usan y un pequeño componente de autenticación interno que ya tiene varios downloads. La verdad que formar parte de un equipo de gente tan grosa como hay en IBM es genial.
  
• Uno de los aspectos que más me involucré este año fue con el aprendizaje, evangelización e implementación de las metodologías ágiles. Ya saben que hace años que vengo molestando con el tema. Ya el año pasado tuve algunas experiencias dando cursos y implementandolas en sistemas pequeños internos. Pero este año, en el proyecto que estoy como Arquitecto, pude ir un paso más in convencer al Cliente de utilizarlas, ahora estamos a puntos de darle un moñito y trabajando muy duro para tener todo listo, ya voy a postear sobre esto.
  
• Con respecto a las charlas que di/escuché que había propuesto a principio de año, en balance más del 70% se hicieron realidad, escuché charlas de rails, javascript, grails, etc Y tambien di charlas de continuations, ruby, rails, tdd, arquitectura, etc. Obviamente faltaron temas como earlang, SOA que ya me viene irritando un poco, pero bue.
• Creo que APIT está impecable, se mejoró mucho en varios aspectos de la materia, los últimos aportes fueron de lo mejor, Esteban Lorenzano y Santiago Blanco, creo que si seguimos reclutando los cereblos de los alumnos van a explotar. Creo que en cuanto a transmitir los conceptos de Arquitectura yo tambien he mejorado, este año también di un curso de tres días muy importante de la carrera de Arquitectos en IBM y obviamente me sirve mucho para hacer sinergia con lo que damos en la UTN.
• Comencé a tratar de stress!!! Creo que eso me permitió llegar vivo a fin de año :) Igualmente no estoy del todo bien, sigo el tratamiento que por sierto todavía tengo que llamar al doctor para coordinar la proxima sesión del MDS. Pero en conclusión pude seguir conociéndo, entender como funciona el stress (y muchas veces afectando mi salud) y pude tomar acción para evitar la parte negativa de este, haciendo deporte, saliendo más con mecha, etc, etc.
  

Creo que esto es todo por ahora, en breve se viene el post de lo malo :P

TDD desde una perspectiva arquitectural

La semana pasada di una conferencia por teléfono para todos los arquitectos que trabajan para proyectos internos de IBM y que con planes de utilizar metodologías ágile y/o ya están utilizando. Fue una linda y desafiante experiencia debido a que había gente de muchas partes del mundo (USA, Francia, India, Sudamerica, etc), nunca había dado una charla técnica en inglés (sacando las presentaciones de arquitectura de la aplicación) y yo pongo un 4, creo que aprobé, pero tengo mucho que mejorar. Independientemente de esto, creo que lo más interesante que quiero comentar en el post es sobre las influencias que tiene TDD en lo arquitectural, esto es el resultado a una pequeña investigación que vengo haciendo para APIT sobre Arquitecturas y Metodologías Agiles. El contenido básicamente fue el siguiente.

Facts acerca de TDD

• TDD se compone de, Unit Test, Test Automation, Test First y Enfoque iterativo con refactoring
• TDD es una técnica de diseño y es utilizada por Desarrolladores (Código).
• TDD incrementa la calidad en el código facilitando el cambio en el software
• TDD reduce defectos y permite tener un testeo de regresion constante
• El manejo de dependencias es la parte más dificil de TDD

Requerimientos no funcionales impactados por TDD
Como siempre digo, las decisiones arquitecturales habilitan los atributos de calidad, pero obviamente no siempre los garantizan, hay otros aspectos y decisiones que entran en juego y el arquitecto no siempre puede manejar. Pero inevitablemente, la Arquitectura es la principal responsable de garantizarlos, y como arquitectos debemos buscar las formas, y TDD es una de ellas, con lo cual considero que TDD permite lograr los siguientes atributos de calidad:
Maintainability: Siguiendo las guías de Feathers, primero haciendo fallar el test case y luego corregirlo, la mantenibilidad se vuelve un detalle, lo mismo pasa con lo simple que queda el código y con la no necesidad de perder tiempo en un debugger. No nos olvidemos del regression test aca.
Extensibility / Modifiability: Esto es básico, como excelente técnica de diseño, al tiempo de aplicarla la productividad aumenta y el código queda mucho mas simple.
Reliability: Tiene que ver con la robustez en lo que respecta a las reestructuraciones o cambios en la arquitectura, un codigo que se construyo utilizando TDD, difícilmente sea complicado de modificar a cambios inesperados
Geographic (including Localization): TDD es una excelente técnica de comunicación, para equipos distribuidos es fundamental, tener bien claro y definido cual es el comportamiento esperado, no se paga con mastercard
Time: Ya hablé de la Productividad que trae aparejada el Test First, aca hay un paper que habla de los estudios que aumenta la productividad, hasta que lo leí fue solo un feeling mio y personal, ahora se ve que está probado.

Decisiones Arquitectónicas para Soportar TDD
Ahora, como (re) diseñamos nuestra arquitectura para soportar el uso de TDD, bueno, lo encaré desde el punto de vista de "Tácticas y Principios de Diseño" y "Estilos Arquitectónicos y Diseño Estratégico":
Tácticas y Principios de Diseño

• Separation of Concerns.
  Una correcta separación de módulos, permite un mejor manejo de la complejidad y también permite el reuso del lado de los Test Cases (que no es poco)
  
• Separación de la interface de la implementación.
  Hace falta explicar esto? Bueno, principalmente es para el manejo de dependencias y el trabajo en paralelo
  
• Design by Contract
  Dos técnicas complementarias en el bajo nivel, desde un punto de vista arquitectural, definir los pre/post conditions entre módulos es básico
  
• Informacion hiding
  Previene cambios no deseados
  
• Prevent Ripple Effects
  Con 8 tipos de dependencias entre módulos, nos ayuda a no tener dependencias ocultas entre módulos, esto es muy importante, muchas veces hay modulos que dependen en variables de contexto y está oculta, TDD ayuda a evitarlo.
  

Estilos Arquitectónicos y Diseño Estratégico
Mas allá de cosas específicas, hay estilos arquitectónicos que ayudan muchísimo al uso de TDD en aplicaciones empresariales, estos son algunos:

• Inversion of Control/Dependency Injection
  Aca no hay nada que discutir, por excelencia permite permite el uso de TDD, sumado a esto la separación de interface de la implementación.
• Hierarchical Layers
  Estilo super conocido, con un modelo sencillo de dependencias, permite el coverage de una layer solo mockeando una layer inferior. Obviamente este patrón tiene cosas malas aparejadas, como la dificultad por encontrar las abstracciones y la modificabilidad.
• Domain Driven Design
  Un estilo muy interesante para dominios complejos, se lleva muy bien con el Dependency Injections y la Iteratividad.
  
• Transaction Scripts
  Modelo sencillo, en donde se puede lograr una completa de cada servicios a testear.

Acá estuve hablando como 30 minutos, es un poco difícil plasmarlo en un post, pero obviamente es la parte más interesante de la charla (al menos para mi)

Quejas de otros profesionales para implementar TDD y como solucionarla
No siempre es fácil convencer el uso del TDD, hay muchas quejas que hay que afrontar, aca puse las que fui recolectando, en algún otro post voy a poner lo que dije verbalmente, así que por ahora se lo dejo a uds para que piensen :)
Project Managers

• Toma mucho tiempo para escribir test y termina impactando en la productividad.
• Me siento mal por dejar afuera del proyecto a Testers y gente de QA
  

Architects

• No me importa TDD, es una técnica de bajo nivel para programadores
  
• No es necesario to test drive el código, la arquitectura cubre todas las posibilidades

Application Developers

• Toma mucho tiempo en correr los test cases
  
• No es mi trabajo testear mi código
  
• Pero compila!
  
• A mi me pagan por escribir código, no para escribir tests
  
• Las dependencias son difíciles de manejar y toman mucho tiempo
  

Esto es todo, espero que les guste y espero feedback! realmente quiero escribir un paper con esto

Visión Visión Visión

Y si, según mechi cada 3 palabras que digo, menciono la palabra "visión"4 veces, al igual que "abstracción" o sus derivadas. En fin, son dos palabras que me sientan muy bien y creo que son básicas en los dos laburos que más me gusta hacer, "Liderar" y "Arquitecturar".
Hace un tiempo en IBM, vengo cumpliendo un nuevo rol de liderazgo desde un aspecto técnico como líder de la práctica Web (Java, .NET, Notes, etc) con implicancias en todos los proyectos que usen dichas tecnologías, y esta semana estoy teniendo una serie de reuniones con todos los profesionales, son como 80. Lo que quiero compartir en este Blog es la visión que tengo sobre la organización que quiero armar. Está claro que se aceptan críticas, insultos, etc...

• Quiero convertir a Argentina en un Centro de Excelencia para IBM de todo el mundo en lo que el desarrollo Web respecta. Le explico el contexto, IBM tiene 8 centros de desarrollo globales, uno de ellos es Argentina, y un poco la idea es de que cada uno se especialice en una o más plataformas como para que cualquier IBM mundial (USA, España, Francia, etc) pueda requerir servicios de desarrollo de software y poder particionar de acuerdo a la especialidad. Con lo cual si Argentina se especializa en Web, cualquier proyecto que IBM (en todo el mundo) venda a sus clientes, Argentina sería el principal referente, esto posibilidad tener una estructura paralela de investigación, innovación y generación de conocimientos financiada por IBM Mundial que podría ser más que interesaante. Osea un area de investigación para la generación de metodologías, frameworks, componentes, buenas prácticas, etc que permitirían diferenciarse en calidad y en productividad. Está claro que Argentina está muy bien parado en cuando a skills en RIA (JS/AJAX o FLEX) creo que por ahi debería venir la mano.
• Quiero formar una "Organización que Aprende", obviamente focalizándome en los profesionales que la componen. No quiero hacer un post sobre esto, pero realmente estoy muy alineado con la idea de Peter Sengue, y sus 5 disciplinas. Sobre todo en el desarrollo de software que es una actividad que depende 80&% en la gente y 20 en vaya a saber quien. No concibo pensar en una organización con gente que realice tareas automáticas, prefiero tener menos personas y más programas. La capacidad y los procesos de selección de personal son claves, y realmente no importa el volumen sino la calidad de los profesionales.
• Quiero fomentar el Ease @ Work. La idea es buscar un ambiente confortable de trabajo para generar los resultados deseados. No quiero perjuicios, quiero que los profesionales se sientan libres de hablar, sin perjuicios, sin pensar en el "que diran" cuando expresamos nuestras ideas. Es fundamental intentar concebir un ambiente de trabajo que fomente la creatividad, soy un apasionado de eso, cuando uno se siente confortable, sabiendo que solo se tiene que preocupar de su trabajo y los objetivos del equipo las posibilidades de fracasos son mínimas, como así tambien la capacidad de innovar es infita. Este es un concepto que vengo ideando y fue llevado a la practiva por Kent Beck, please google it.
• Sigo insistiendo, el diferenciador de Argentina es la Calidad, y no el Costo. No podemos depender en la economía con picos tan bajos cada 10 años. Lamentablemente es asi, el costo es una variable ajena al software y la tenemos que dejar fluctuar, nunca depender del costo. Tenemos que focalizarnos en vender soluciones/servicios que dependan totalmente en la calidad, y que generen un valor agregado al negocio. Si logramos brindar servicios con calidad, vamos a ser siempre una potencia en el desarrollo de software, pero si solo pensamos en la paridad cambiaria, es muy "cortoplacista", hay que entender que por más que pensemos en el cambio, la inflación termina impactando tambien.
• Y por último, el 5to item de visión que tengo para mi organización es en la innovación constante. La innovación a esta altura no se discute, obviamente esto es un cambio de mentalidad y dejar de pensar un poco en el corto plazo, pero esta claro que los proyectos son finitos y siempre se piensa a corto plazo, y es por eso que quiero pensar en formas de fomentar la innovación y que eso sirva como retroalimentación a los proyectos.

En fin, esa es la visión que quiero para la organización que estoy liderando... todavía estoy en proceso de comunicación y delineamiento de como llegar a cumplirla, pero estoy seguro que voy a ser muy feliz cuando lo haga y muchas personas van a verse beneficiadas.

Estimaciones de Software, algunos pensamientos

Ahora que se me rompió la laptop de IBM, tengo un tiempito libre setupeando mi laptop personal (una Dell Latitud D610, viejita pero se la banca) hasta que el soporte técnico se digne a arreglarla. Quería de hablar de un tema bastante heavy del software y siempre trae lindas discusiones en la materia.
El Viernes, con Esteban Lorenzano, antes de dar la charla en Cafelug, nos colgamos hablando del tema y vimos que hay dos cosas totalmente equivocadas o mitos sobre las estimaciones que no estamos de acuerdo para nada, y son:

1. Querer establecer un modelo matemático para poder justificar un metodo de estimación. Si bien sería algo ideal, es algo imposible (desde nuestro punto de vista) y principalmente por que la unidad de trabajo (ya sea, LoC, UCP, FP, CocomoFuckingFactors) es inmedible, recuerden que la construcción de software es un proceso creativo y no repetible!!! y no solo eso las personas importan y no hay proceso que pueda hacer repetible ninguna tarea de construcción de software.
2. Los profesionales del software no entienden que quiere decir una Estimación. No quieren entender que es un Pronóstico, una simple (o compleja, de acuerdo a que método uses) predicción del esfuerzo (tiempo, costo y scope) que puede tomar la construcción. Nunca debe tomarse como un hecho, ni tampoco se puede planificar detalladamente y menos que menos controlar en base a una planificación errónea asumiendo estimación... o sea, todo mal. Con lo cual, tomemos el resultado de una estimación como debe ser, algo que nos permita tener una idea y tengamos en cuenta que es errónea desde un principio.

Luego de haber leído un libro muy interesante, les dejo una serie de tips que me gustaron:

• Separar lo que es un restricción del negocio (para cuando se quiere el software) de una estimación de esfuerzos, son cosas diferentes... no hay que confundirlas.
• Muchas veces, la estimación es un problema de ineptitud del Equipo que la ejecuta el proyecto. Esto puede ser por falta de comunicación de la estimación y los fundamentos de esa estimación, falta de recursos en tiempo, mal manejo de requerimientos, etc, etc.
• Hay que tener muy en cuenta el nivel de in/certidumbre por falta de información u otros temas, y eso no solo se mitiga agregando más tiempo a la estimación, sino poniendo el % de desvío correspondiente.
• Tener en cuenta que el software es algo creativo y depende muuuuuuucho de las personas, y aca se te va la estimación a la mierda, aca es donde hay que estimar "constantemente" por cada iteración para generar un compromiso del team para lograr algo, y eso va ajustando el estimación original que nunca es precisa.
• Segun McConnel, (opino lo mismo) siempre está mejor sobre estimar que estimar menos de lo que es, ya que estar siempre atras de lo que se estimó genera más ruido, más comunicación, mas reuniones de tracking, mal ambiente que sigue atrasando el proyecto... pero obviamente hay que tener cuidado con la ley de parkinson.
• No solo se estima tiempo, sino que se estima esfuerzo y costo, ojo aca
• Las factores son un excelente medio de ir perfeccionando una estimación, pero cuidado con los pesos que se le ponen a dichos factores por que pueden ser comienzo del problema, creo que definir una serie de factores que ajusten la estimación es correcto (no más de 10/15) ya después entra la subjetividad.
• Está claro que Wideband Delphi es el método que puede tener mejores resultados, pero es muy costoso hacerlo. Y lo que te queda es irte a las estadísticas de la organización para buscar proyectos similares, con tecnologías iguales y dominios similares.

Que lindo sería una materia de esto, no? Aunque prefiero antes que la gente aprenda a construir software como la gente, luego aprender a estimar, asi que todavía tenemos un largo camino que transitar.

Que cosas no ayudan al TDD - Revisited

La semana pasada encontré una herramienta muy interesante que mide la testeabilidad de un programa Java y me pareció muy interesante desde el punto de vista arquitectural y seguramente fue esta la que me hizo pensar que evitar a la hora del TDD que dió origen al post anterior. Todavía no la probé, pero en breve seguramente la incluya a mi lista de herramientas que ayudan a sacar métricas interesantes para un arquitectos sobre el código (buen título para un post).

Bueno, la idea de este post era la de contar que el autor (Miško Hevery) de la herramienta tiene un blog super interesante y ya hizo el post un poco más completo que el mio y lo que agregó Pablo (BTW Gracias!).

Me cayó muy bien el tipo de posts, evidentemente odia más el Singleton que yo :)
Bueno era eso, el post van a encontrar otras cosas que no ayudan.

Que cosas no ayudan al TDD

Hoy tuve un viaje bastante pesadito de MDQ a BA, 8 horitas, se rompió el auto, llegamos BA a las 19 (o sea todos volviendo del trabajo) y que se yo... en fin estuve pensando en que cosas molestan y mucho al la hora hacer TDD, obviamente tienen más que ver con el el buen diseño y la programación también, estas fueron mis ideas:
Métodos Estáticos
Esta es una de las cosas que más me molesta y sobre todo se vuelve un problema cuando los desarrolladores no utilizan los conceptos de OO y siguen trabajando o pensando en Estructurado. Los métodos estáticos son una mala práctica, realmente no justifico su utilización. Para los que no los notaron, los métodos estáticos son un problema a la hora de querer modificar su comportamiento para poder ejecutar cierto escenario del comportamiento unitesteado, existe varias técnicas para poder evitarlos.
Singletons.
Hay algo para decir aca? Realmente yo a los Singleton los veo como un Anti Pattern, raramente justifico el uso. No solo son dificiles de mokear sino que tambien son muy complicados para unitestear, siempre tenes que caer en agregar un método solo para la hora del testeo.
Service Locators
Piensen lo siguiente, como se implementa un Service Locator, Singleton + Métodos Estáticos, o sea que más puedo decir :) y si, algo más tengo para decir, si bien está claro que IoC es muy superior en terminos de manejo de dependencia y el 60% de los problemas del TDD tienen que ver con el manejo de dependencias, la implementación incorrecta de un Service Locator puede obligarte a no testear absolutamente nada de tu código. Está claro que si se implementa correctamente (no métodos estaticos y no singleton) puede no ser tan malo en terminos de TDD, igualmente dudo que decida utilizar TDD utilice un Service Locator en vez de IoC y DI.

Hasta aquí son las tres cosas que más podrían molestar o en algunos casos fracasar el uso de TDD, y ahora que estoy terminando el post veo que todos tienen que ver con el manejo de la dependencia de objetos... en conclusión, si queres usar TDD y tenes posibilidades de tomar decisiones sobre como se está construyendo un sistema, sinceramente te recomiendo que evites estas tres cosas y trates de focalizarte en como vas a hacer el manejo de dependencias, no estoy diciendo que tengas que usar si o si un IoC framework (cosa que tiene mucha onda en muchos casos) pero si que lo tengas muy en cuenta.

Está claro que lo que acabo de decir puedo asegurar que aplica principalmente con java, todavía quiero ver que pasa con lenguajes dinámicos como Ruby o Smalltalk, creo que no debería cambiar mucho, pero por algo DI no es algo que se usa en Smalltalk, quizá sea o por que son cerrados o realmente no lo necesitan por las características del lenguaje. Es una charla que me debo con Esteban Lorenzano, siempre que intenté tenerla nos fuimos por la tangente. En el caso de Ruby, lo poco que hice la injección de dependencia fue bastante sucia redefiniendo en runtime el comportamiento de las clases, cosa que no está del todo mal, pero prefiero el DI.

Parcial de Arquitectura (APIT) esta vez le tocó al Broker

El martes pasado tomamos el parcial de la materia. A diferencias de casi todas las materias de la UTN, nuestro parcial apunta a que los alumnos piensen como Arquitectos dada ciertas restricciones y puedan tomar las decisiones justificando correctamente, realmente cada una de las pregunta tiene infinitas respuestas como así también sus justificaciones. Estamos muy conformes (al igual que los alumnos de años anteriores) con esta metodología, ya que estudies lo que estudies, si no conceptualizaron los elementos de la Arquitectura de Software que enseñamos en la materia, es dificil que aprueben, es más permitimos apuntes, presentas... o sea carpeta abierta que realmente no sirve para mucho si no estás dispuesto a pensar.
Aca les dejo una copia y ojala yo hubiese tenido más parciales de estos en aquellos años felices como estudiante :)

Voy a ver si a lo largo del finde escribo algunas respuestas que podrían haber sido correctas :) todavía estoy corrigiendo los parciales.

Fin de semana de descanso

Bueno, llegó el segundo fin de semana y me llegó el cansancio todo de una. Una semana bastante agitada pero con muy buenos resultados.
Por un lado estamos tratando de entender funcionalmente que es lo que hace la aplicación, y se me ocurrió la idea de ir definiendo los casos de uso y que el Arquitecto que creó la aplicación nos explique que es lo que la aplicación hace, obviamente esto no solo va a dejar la aplicación documentada desde el punto de vista funcional, sino que también me va a servir a mi para poder evaluar los futuros cambios, tanto para corrección como para mejoras, también va a servir a los desarrolladores para entender como lo funcional termina impactando el estado de la aplicación por cada interacción con el usuario.
Creo que haber tomado esa decisión fue muy acertada y bien recibida, ya que la gente que nos tiene que contar la aplicación no tiene mucho tiempo para dedicarnos ni tampoco algo documentado, entonces este tipo de especificación sirve muchísimo para organizar las ideas. Antes de que alguno me diga "pero si tenes el código, por que no mirás ahi que es la mejor documentación de lo que hace la aplicación", bueno, si... comparto, tengo el código que veo como la aplicación resolvió un problema, pero no tengo que es lo que la aplicación tiene que hacer, o sea el "que". Aparte de que el código, lamentablemente, no está muy programmer-friendly, hay mucho codigo de presentación y negocio muy pegoteado y sin mucha reutilización y uso extremo de ifs.
Por otro lado, como la aplicación requiere nuevas versiones cada mes y en producción, con eso me bastó como para proponer el uso de alguna metodología ágil y como en IBM USA, por fin, le están dando algo de bola, picaron... por suerte tengo al Chief Architect (un arquitecto bastante cross) y al Arquitecto de Build bastante al tanto del tema, podría decir que en breve finalmente voy a poder poner en practica todo lo que vengo investigando (desde el 2004), implementando pequeños approachs y enseñando... todo en práctica, con lo cual de aca a Julio, voy a estar, junto con la Project Manager (que es una grande y muy abierta) y otros roles del proyectos tratando de adaptar alguna de las metodologías ágiles disponibles.
En fin, profesionalmente creo que nos está yendo bastante bien, aunque calculo que los resultados se verán en un tiempo. Lo lindo de este viaje, es que conocí gente muy copada de India, USA, Singapore y se pudo trabajar muy muy bien.

Primeros 4 días en Raleigh

Ya van 4 días en North Carolina y la verdad que muchas cosas pasaron, mucha copada tanto en lo profesional como en lo personal. Una cosa que me impresionó totalmente es la organización, es increíble, todo, desde el aeropuerto, las rutas, el alquiler del auto, el hotel... fue increíble llegar y tener prácticamente todo servido. Excepto por a valija que nunca llegó a tiempo, así que tuve que hacer el reporte pero el mismo domingo a las 11:30 ya estaba en la puerta del Hotel.
Mas o menos la cosa vino así, el viaje fue Bs As->Miami, Miami->Raleigh/Durham. Llegamos al rededor de las 12 del mediodía y lo primero que hicimos fue buscar el auto, también hubo una pequeña equivocación y ligué un Corolla negro, podría decir que es el auto que deseo tener de aca a un tiempo, asi que con eso pasó el mal gusto de no tener la valija en mi poder :)
El tema es así con la zona, hay dos ciudades muy cercas, una es Raleigh y la otra es Durham, ambas están muy cercas, alrededor de 20 mintos por autopista. En el medio de ellas se encuentra el Aeropuerto y el RTP (Research Triangle Park), nosotros estamos parando en el centro de Raleigh, bastante lejos de la oficina que está en el RTP... más o menos tardamos 30 minutos para llegar de un lado al otro. Las oficinas de IBM son increíbles, son las más grande que tiene en todo el mundo, son más de 30 edificios, de uno a otro es probable que tengas que ir en auto, hay varios comedores y starbucks.
El Hotel, la verdad que bastante bueno (de la cadena Hilton) me sorprendió bastante, tiene un pub muy muy copado con 12 tipos cervezas tiradas, 40 tvs ydos LCDs (los más grandes que existen) transmitiendo en HDV, la verda que increible. Tambien tiene una linda pileta climatizada y las habitaciones son bastantes agradables, mañana o pasado voy a postear un par de fotos.
Con respecto al trabajo, la verdad que venimos bastante bien, estamos de a poco tratando de cumplir los objetivos pero se me complica un poco ya que tengo mucho trabajo del día a día atrasado. La gente con la que estoy es muy copada y de distintos países, como India, Singapore e Inglaterra y obviamente estadounidenses. Somos alrededor de 22 personas en diferentes salas, trabajando e intercambiando ideas y conocimiento constantemente.
Realmente me impresionó muchísimo como todas las decisiones que venimos tomando y comunicando por telefono y ppts fueron excelentemente entendidas y muy bien trabajadas, ahora estamos de alguna manera uniendo todas las patas y la verdad que van encajando perfectamente. Estos días estuvimos trabajando muy cerca del Arquitecto de Build, Tony Marcotte, realmente me sorprendió tanto personalmente como profesionalmente, es una persona con la que tuve muy poca comunicación (pero efectiva) por teléfono y f2f fue genial, es increible como pudo desde mis diagramas de Componentes, Unidades de Deploy y Diagrama de Zonas de Red/Nodos armar y automatizar todo el proceso de Build and Deploy y dejar las cosas preparadas para comenzar a usar el Continuous Integration Server con Rational Build Forge. Estamos prepearando una agilización para este proyecto y creo que vamos a tener que innovar bastante ya que los procesos de mi organización son bastante tradicionales y waterfall (más de esto en el futuro).
La onda en general es muy buena, la PM, que es de Dallas es una fenómena, nos dá mucha flexibilidad y soporte en cuanto a las decisiones que tomemos, así que no me puedo quejar.
El día a día es bastante agitado, los levantamos a las 7:30 y volvemos a las 12:30, tratamos de salir de la oficina a las 17, nos quedamos un rato "hanging out", una nueva frase que aprendí, en criollo es "boludeando", luego vamos a comer o tomar algo y luego nos quedamos hasta tarde charlando y tomando alguna cervezas, ayer vimos en un plasma de 42 el partido de los spurs contra phenix.
Bueno, son las 1:20 AM aca y me estoy cayendo del sueño, en cuanto tenga algo más para contar lo voy a hacer, es probable que este fin de nos vayamos a Washington y tenga que cerrar algunas presentaciones de la Arquitectura para el Martes, así que hasta ese día dudo que pueda postear algo, pero voy a intentarlo.

Tipos de Arquitecturas de IT

Uno de las primeras cosas que hay que entender sobre la Arquitectura es que existen diferentes tipos en el ámbito de IT, con lo cual es muy importante tener claro que rama o especialización de la arquitectura uno quiere desarrollarse y obviamente el alcance de cada una. Esta es la clasificación que más me gusta y es la damos en APIT:

Enterprise Architecture (EA) : Es la arquitectura toma las decisiones necesarias para que Organizació de IT de la compañia esté alineada y permita cumplir con visión/misión de la organización en cuestiones de negocio , definiendo guías y políticas para que el conjuntos componentes de IT (redes, hardware, software, aplicaciones, etc) crezca de manera ordenada siguiendo un objetivo bien definido.

System architecture: Relaciona los requerimientos y el mundo externo con las estructuras del sistema, incluyendo el hardware y el software. Vendría a ser la Infraestructura.

Software architecture (o Application Architecture): Está relacionada con una aplicación en particular, o sea con el desarrollo de un software en particular, son las decisiones que se toman pero acotadas a un proyecto o aplicación en particular y no cross a la organización como la EA. Esta es el tipo de Arquitectura en la que trabajo y está focalizada la materia.
Integration Architecture: Está relacionada con las decisiones tomadas desde el punto de vista de la integración de las diferentes aplicaciones y los procesos de negocio asociados. Como para dar un mejor entendimiento, temas como SOA o EAI, estarían en este tipo de Arquitecturas.

Existen otro tipo de Arquitecturas pero en mi opinión ya con la clasificación planteada alcanza, como por ejemplo, Data Architect, Business Architect, etc.

Alguno creo que se puede mejorar esa clasificación?

Comentario: How to spot the dreaded non-coding architect

Me encantó este post... sore todo me recuerda hace un par de años cuando el termino de Arquitecto se estaba poniendo de moda y todo se hacia en java y los "arquitectos" lo unico que hacien eran leer ariculos de SUN y Patrones.
Igualmente quiero hacer una salvedad.. si bien se puden detectar estos dos tipos de arquitectos, pero que nadie se olvide de la tercera categoría de arquitectos.... que esos si son los peores que ni se gastan en leer ni estandares, patrones,
buenas practicas.

Este es el link: http://softarc.blogspot.com/2007/06/how-to-spot-dreaded-non-coding.html

Resumen: (Could this be flamebait - probably! But here goes anyway)

By Architect here I'm not talking Enterprise level folk who pretty much don't cod

APIT en el SEI!

La semana pasada tuvimos un intercambio de mails con Paul Clements y uno de los primeros resultados de esto fue incluir, en la lista de (http://www.sei.cmu.edu/architecture/educators.html) Universidades que enseñan Arquitectura de Software, nuestra materia (APIT).

El segundo resultado estará por venir, pero les puedo adelantar que Paul se encontró interesado en el contenido de una de nuestras clases, la de "Rol del Arquitecto de Software", si bien el 40% del material no es nuestro el resto si lo es, por lo tanto creo que puede haber mucho fruto en el futuro.