sábado, 4 de octubre de 2014

¿Debería Usar TDD en una Lean Startup?

El siguiente post es una traducción del artículo Should you TDD on a Lean Startup publicado por Santiago Basulto en Medium durante Febrero de 2014.

London Eye
A veces, cuando nos metemos en una conversación sobre Lean Startup, los temas de testing y TDD (Test-driven development) se nos cruzan en el camino. Como siempre, hay personas que dicen que no debemos usar TDD (o incluso escribir pruebas unitarias) en una startup porque es un desperdicio de tiempo y dinero. Por supuesto, eso suena razonable para el neófito; si pensamos que Lean Startup se trata de "no construir nada que los clientes no quieran", los tests no aportan valor directo. Pensemos en esto: ¿Los clientes tienen una mejor experiencia sólo porque tenemos muy buena calidad de código? No. Si estamos construyendo el producto equivocado pero aún así está bien testeado y tiene un porcentaje de cobertura impresionante, ¿esto impedirá que fallemos? ¡Por supuesto que NO! Pero el testing y TDD en una Lean Startup es importante por otras razones.

Es cierto que la filosofía Lean indica que el desperdicio debe ser minimizado. Lo que no aporta valor al cliente no debe ser construido. Eso es un hecho, y pertenece a la metodología Lean (las raíces de Lean Startup). Pero, ¿cómo sabemos qué es lo que da valor al cliente? Iterando y aprendiendo, la piedra angular de Lean Startup. Lean Startup se centra en el "Conocimiento Validado" y lo utiliza como unidad de progreso. Para lograr esto, tenemos que iterar a través del bucle de construir-medir-aprender:

Lean Startup: build-measure-learn loop
Como dice Eric Ries: "Las startups que tienen éxito son las que logran iterar suficientes veces antes de quedarse sin recursos". El tiempo es crucial. Cuantas más iteraciones podamos hacer, mayores son las posibilidades de encontrar un negocio sustentable. Podemos argumentar luego de que uno de los objetivos que podemos tener es reducir al mínimo el tiempo de cada iteración. Si logramos que cada iteración sea lo más corta posible, seremos capaces de ciclar más veces y las posibilidades de que nos quedemos sin recursos son menores.

Aquí es donde las pruebas (y TDD) entran en escena. Tener una base sólida de pruebas nos permitirá movernos rápido cuando experimentamos. Podemos tener una corazonada (basada en una métrica, por supuesto ;-)) que nos dice que "debemos eliminar esta cosa" o "separar esto otro en dos partes" y podemos probar. Pero, ¿qué pasa si cada vez que ejecutamos experimentos todo el sitio web explota por los aires? Nuestra velocidad a través del loop se reducirá. Nos ralentizaremos, e incluso pondremos en peligro el experimento con bugs extraños que introducen cambios al azar.

Startup = Experimento
Es por eso que las pruebas y TDD son cruciales para una Lean Startup. Los tests nos permiten iterar rápidamente a través del bucle construir-medir-aprender con un alto nivel de auto-confort y seguridad.

Menciono pruebas y TDD todo el tiempo porque no estamos obligados estrictamente a usar TDD para tener una base sólida de pruebas en el proyecto. Sin embargo, para mí (y esto es una opinión discutible) es la mejor manera de lograrlo. Encuentro muy estresante volver atrás y meterme en alguna pieza de código ya escrita para programar los tests con el fin de hacerlos pasar, basado en el código en lugar del camino contrario.

Por último, una nota sobre la calidad del código y las buenas prácticas.


Hay algunas prácticas de codificación desarrolladas en los últimos 20 años que se construyeron a partir de la experiencia de programadores. Esto significa que no fueron creadas por un grupo de académicos que sólo querían llenar un paper de 10 páginas. Fueron creadas porque eran necesarias, nacidas de necesidades reales de programadores.

La mayoría de ellas están incluidas en XP (Extreme Programming): Pair programming, integración, estándares de codificación, y por supuesto, test-first o TDD. Todas estas prácticas han existido por mucho tiempo y han demostrado su eficacia. No dudes en hacer el esfuerzo e incorporarlas. Hemos gastado bastantes grandes cantidades de tiempo en nuestro proceso de despliegue (gracias @dustinmcquay) y no me arrepiento de nada. Somos capaces de desplegar el código en cuestión de segundos, con un proceso realmente estable. También he probado (no lo suficiente, me temo) programación de a pares y es absolutamente impresionante. Una vez más, los hackers somos parte de una sabia, colaborativa e inteligente comunidad. Nuestra meta es la calidad.

¿Qué piensan ustedes?

Artículo original: Should you TDD on a Lean Startup?

jueves, 2 de octubre de 2014

Así Fue la Charla de VolKno en la UTN

Gracias a la UES y a la Secretaría de DDHH del CEIT, el martes estuvimos en la Universidad Tecnológica Nacional (UTN), sede Medrano, dando una charla sobre VolKno. Nuestro objetivo fue contar un poco las dificultades que nos fuimos encontrando en el emprendimiento, y las metodologías, tecnologías y decisiones que nos fueron ayudando a esquivar obstáculos hasta ahora.

Charla de VolKno en la UTN
La charla se dividió en dos partes: una más blanda, en la que contamos qué es VolKno y para qué nos sirve Lean Startup a la hora de encarar el proyecto; y otra más técnica, en la que nos subimos a un submarino y nos sumergimos en la arquitectura, pasando por AngularJS, APIs REST, Spring, MyBatis y llegando al corazón, a la última fortaleza, la base de datos PostgreSQL. Como yapa, el último tema fue sobre OpenShift, la PaaS de Red Hat donde estamos hosteando.

Arquitectura VolKno: Client-Centric Web Application

Fue todo un éxito. Aunque parecía demasiado contenido para una charla de 2 horas, los tiempos alcanzaron y hubo espacio para contestar preguntas e interactuar con el público. Al final, un grupo se acercó para hablar y nos quedamos un buen rato conversando sobre temas de emprendurismo y otras cuestiones.

Charla de VolKno en la UTN
Para nosotros, desde VolKno, ésta fue una experiencia única, ya que tuvimos la oportunidad de contar lo que fue un año de camino recorrido, camino que todavía continúa con todas las incertidumbres inherentes a cualquier startup.

Equipo VolKno
Para cerrar el post, les dejo las slides de la charla y les embebo el estante que compartimos con las referencias y bibliografía que fuimos mencionando en la misma.

lunes, 22 de septiembre de 2014

Ahora sí: Se Viene la Charla de VolKno en la UTN


Hemos podido reagendar la charla de VolKno en la UTN, con lo cual el próximo martes 30 de septiembre, a las 18:30, te queremos ahí, en el Aula Audiovisuales de Medrano 951.

La idea es contarte un poco nuestra experiencia recorrida hasta ahora con el emprendimiento, enfocándonos especialmente en los aspectos técnicos y de arquitectura de la aplicación web.

Los temas que trataremos serán:
  • ¿Qué es VolKno?
  • Lean Startup
  • AngularJS
  • Web Services REST con JAX-RS
  • Spring
  • OpenShift
¡La charla es Libre y Gratuita!
¡Los Esperamos!

viernes, 12 de septiembre de 2014

Se Suspende la Charla en la UTN


Lamentablemente, por problemas administrativos, nos vemos obligados a suspender momentáneamente la charla de VolKno en la UTN.

¡Estén atentos!
¡En breve anunciaremos una nueva fecha!

miércoles, 10 de septiembre de 2014

Charla en la UTN Suspendida


Para el que no conoce VolKno, puede mirar este video:

Y por supuesto registrarse en el sitio, libre y gratuitamente, y usarlo!!

Como decimos siempre, todo feedback es bienvenido.

miércoles, 30 de julio de 2014

El Desafío de un Programador: Aprendiendo 30 Tecnologías en 30 Días

Durante el mes de noviembre de 2013, Shekhar Gulati, un desarrollador de Red Hat, se tomó muy en serio un fabuloso desafío: Después del trabajo, llegaba a su casa y todos los días elegía una nueva tecnología para aprender, tomándose 1 hora para escribir lo aprendido. Los resultados los iba publicando en una serie de post en el blog de OpenShift.

De más está decir que esta serie de post es divertidísima. Hay frameworks, herramientas, librerías, servers, de todo, principalmente para JavaScript y Java. Todas las tecnologías que Shekhar usó están en la cresta de la ola y, por supuesto, todas corren en OpenShift.

Aprovecho entonces para compartir cada uno de los días de este épico desafío haciendo uso de una funcionalidad que estamos empezando a probar en VolKno, la funcionalidad de grupos y comunidades. Por ahora esta opción no está disponible en el sitio, pero si sale todo bien y gusta, la ofreceremos a todos nuestros usuarios en el futuro cercano.

¡El feedback es bienvenido! ¡Qué lo disfruten!

miércoles, 23 de julio de 2014

¿Dónde Guardé esa Página que no Encuentro?

Creemos que la información que encontrás valiosa en Internet tiene que ser fácil de organizar. Por eso creamos VolKno, una plataforma web de diseño simple, para que organices tus links y potencies tu conocimiento con la colaboración de la comunidad.


Organizá tus Links Favoritos


En un único lugar, pero en todos tus dispositivos. Creá estantes y guardá ahí tu contenido favorito de Internet. Cada estante puede tener una descripción y cada link información útil que te sea relevante. Podés acceder desde la computadora de tu casa, una tablet o un celular.

Descubrí Nuevo Contenido


¿Qué te estás perdiendo que otros ya encontraron? Con VolKno accedé a otro contenido que está subiendo ahora mismo la comunidad. Cuando algo te gusta, copialo a un estante de tu biblioteca y compartilo a través de las redes sociales. O discutilo dentro de VolKno dejando comentarios.

Tematizá Contenidos


Asociá temas a contenidos. La tematización de links es comunitaria, por lo que además de etiquetar contenido propio, podés hacerlo con contenido ajeno. Votá de forma positiva o negativa cada uno de los temas, según qué tan relevante te parezcan, para que el contenido sea más fácil de encontrar.


Queremos que VolKno sea tu Biblioteca Personal de links, y a la vez formes parte de una gran comunidad alrededor de una Biblioteca Pública, en la que todo el mundo pueda leer, guardar y compartir.

VolKno es libre y gratuito.

Internet es el lugar donde se conversa el conocimiento del mundo.
¿Qué te estás perdiendo?

miércoles, 7 de mayo de 2014

VolKno y los Primeros Pasos de una Startup

¿Qué es VolKno? Bueno, pueden leerlo en su Acerca de VolKno. ¡Léanlo y después regresen a seguir con este post!


Historia de VolKno


A mediados del año pasado, Germán, Pablo, Claudio y yo, cuatro emprendedores tecnológicos, nos asociamos para embarcarnos en esta locura. Una plataforma web gratuita, en la que los usuarios puedan subir contenido, organizarlo en estantes, tematizar. Una biblioteca en la que toda la información sea pública y que a la vez pudiera funcionar como biblioteca personal.

Lo primero que hicimos fue lo primero que hace (o que debería hacer) cualquier emprendedor con una idea: fijarse cuánto de esto ya existe en el mercado. Así conocimos marcadores sociales como Delicious o Scoop.it (otros menos sociales como Evernote), nuevas e innovadoras plataformas de blogging como Medium, páginas que encaraban el problema de traducciones y de aprender nuevos lenguajes como Duolingo.

Sin embargo no encontramos un sitio que resolviera estos tres problemas juntos: marcador social, plataforma de blogging, y traducciones manuales y/o automáticas.

Lean Startup, Prenser y EmprendING


Si bien teníamos la idea de lo que queríamos hacer y las funcionalidades que desarrollar, no sabíamos muy bien cómo íbamos a encarar semejante proyecto. Los cuatro habíamos trabajado en proyectos ágiles que usaban Scrum y Canvas, pero ahora nos enfrentábamos a un desafío superior: nosotros seríamos Product Owners, Scrum Masters, DevOps, Developers, Analistas, Arquitectos, Testers, y todos los roles que uno quiera nombrar según la metodología. Emprender es eso, ¿no? Ahora estás por tu cuenta.

Fue cuando caímos en la metodología Lean Startup y pudimos ponerle una etiqueta a nuestro emprendimiento: startup. Nos miramos y nos dijimos: ¡Estamos haciendo una startup!

Por ese tiempo nos pusimos en contacto con un ex-compañero de la facultad, Maxi, quien nos llevaba varios pasos de ventaja. Su emprendimiento se llama Prenser, y en cuanto conocí el sitio, me registré y lo empecé a usar y la verdad que quedé encantado. La filosofía de Prenser está muy alineada a la de VolKno. Prenser es una red de contenidos en la que todos los usuarios pueden tener sus propios diarios (yo tengo mi diario) y escribir notas, compartirlas y votarlas como en una red social.

Maxi me invitó a EmprendING, materia gratuita que se dicta en la UBA, que actualmente estoy cursando y recomiendo. EmprendING tiene muchísimos ayudantes, cada uno de ellos llevando adelante sus propios emprendimientos, y están muy dispuestos a ayudarte con lo que necesites para el tuyo.

Y, vaya casualidad, que la materia de EmprendING sigue la filosofía de Lean Startup.

Producto Mínimo Viable


Hace una semana que tenemos VolKno online. Eso no quiere decir que hayamos terminado con el trabajo. ¡Todo lo contrario! Significa que comenzamos a trabajar de verdad hace una semana. Lean Startup dice que hasta que no tenés usuarios/clientes, tu startup no comenzó realmente.

La aplicación que tenemos online es lo que Eric Ries llama Producto Mínimo Viable. Es un experimento que nos ayudará a encontrar un producto/servicio que la gente quiera y/o necesite. Pudimos habernos sentado y pasar dos años, tres, programando las funcionalidades que teníamos en mente. Pero de nada hubiera servido todo ese trabajo si no validábamos con usuarios reales lo que estábamos haciendo. En el fondo es lo mismo que nos enseña Scrum y todas las metodologías ágiles.

VolKno está online hace una semana. Es un MVP. Por ahora es un marcador SaaS con el agregado de Estantes para organizar la información, perfiles públicos y algún que otro sabor más. Nuestra visión es crear una red de contenidos para compartir y organizar el conocimiento, superando las barreras idiomáticas. Nuestra misión, hoy, es encontrar la forma de lograr esto.

Cultura Libre


Para terminar con este post, que ya se me hizo largo pero los lectores de este blog están acostumbrados a los post largos así que no pasa nada :-P, les cuento que en el medio del camino, mientras tratábamos de darle forma a la idea, nos cruzamos con otros dos libros bastante interesantes: Inteligencia Colectiva, de Pierre Levy, y Cultura Libre, de Lawrence Lessig. Estos dos ensayos nos sacudieron bastante la cabeza.

Lessig es además el creador de las licencias Creative Commons, inspiradas en las licencias Open Source de la Free Software Foundation. La Cultura Libre es un concepto que abarca también al Software Libre, por supuesto, como obra intelectual.

Si les interesa conocer un poco más sobre este tema, les recomiendo que se vean un documental de 20 minutos, dirigido por Carlos Escaño llamado Cultura Libre y Educación (el link los lleva a VolKno, por supuesto; para llegar al video hagan click en el título y los llevará a Vimeo).

Además, el usuario mismo de VolKno recolecta información relacionada con Cultura Libre, Software Libre, Gobierno Abierto, etc. Pueden ver más información accediendo al Perfil Público del usuario VolKno.

domingo, 23 de marzo de 2014

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 7

Y llegamos a la última parte. Parecía que este día no iba a llegar, pero llegó. Desde mitad del año pasado vengo resumiendo y publicando el conjunto de principios y buenas prácticas de este compendio portentoso que O'Reilly Media ha decidido llamar 97 Things Every Software Architect Should Know.

El libro forma parte de una familia de libros llamados 97 Things Every XXX Should Know. Y hay de Project Manager, de Arquitecto de Software y de Programador, por lo menos hasta donde yo sé. Hace poco les conté que existe un sitio que está traduciendo al español todos estos compendios de 97 Things. Este sitio es 97cosas.com y ya tiene completamente traducido el 97 Things para Programadores.

Hoy se completa mi resumen de 97 Cosas que un Arquitecto de Software Debe Conocer. 97 principios en 7 posts.

Para consultar los posts anteriores:
Pasemos a hablar de los últimos 13 principios:
  1. Crea un Caso Fuerte de Negocio: Las personas que tienen la autoridad presupuestaria para patrocinar tus ideas son casi siempre gente orientada al negocio. Por eso, a la hora de comunicar tu arquitectura es importante: 1) Establecer la propuesta de valor: el resumen ejecutivo de por qué este negocio específico garantiza una arquitectura de software en particular, 2) Construir métricas para cuantificar: que respalden con números de negocio la arquitectura propuesta, 3) Volver a las medidas tradicionales de negocio: sería ideal poder traducir tu análisis técnico en dólares, ¿no?, 4) Saber cuándo parar: prepara una hoja de ruta (roadmap) que capture una visión en cada hito (milestone) que esté directamente relacionada con los valores del negocio y deje que los interesados (stakeholders) decidan cuándo parar; si el valor de negocio de cada hito es significativo, será más probable que consigas financiamiento continuo, 5) Encontrar el momento adecuado: puedes tener el modelo de negocio más brillante entre manos, pero de nada servirá si lo presentas en un mal momento.


  2. Patología de Patrones: Es muy tentador querer mostrar nuestra destreza arquitectónica lanzando una pila de patrones de diseño. El problema está cuando quieres encajar un patrón a la fuerza a un problema que no aplica. Como todas las herramientas, los patrones de diseño pueden ser mal utilizados. ¡Ten cuidado de no caer en la sobre-ingeniería! Es nuestro trabajo identificar los problemas que resuelven cada patrón y aplicarlos adecuadamente. ¡KISS!

  3. Aprende un Nuevo Lenguaje: Sabes hablar lenguaje de programador. ¡Muy bien! Ahora aprende lo básico de lenguaje de negocios y de testing. Aprender distintos lenguajes no solucionará todos los problemas, pero ayudará a prevenir la falta de comunicación y los malentendidos que conducen a los problemas. Difícilmente puedas ser un puente entre el negocio y el desarrollo de software si no sabes hablar ambos idiomas.

  4. No seas Astuto: La inteligencia general, la creatividad, el ingenio, la amplitud y profundidad de conocimientos, son cualidades apreciadas en los arquitectos de software. Sin embargo, la astucia implica la capacidad de concebir una solución que pueda sacarte de un apuro de forma rápida, pero que implica en última instancia un truco. El software astuto es caro, difícil de mantener y quebradizo. Sé tan tonto como te sea posible para poder crear el diseño apropiado. Si la astucia parece absolutamente necesaria, probablemente el problema esté incorrectamente definido. ¡Redefínelo! Es nuestra astucia lo que nos permite lograr que software engañoso quede funcionando. Las soluciones tontas siempre serán más fáciles de implementar. Una vez más: ¡KISS!

  5. Construye Sistemas para ser Zuhanden (manejables): Construimos herramientas, y las herramientas no son más que un medio para obtener un fin. Las herramientas se experimentan directamente, sin teorización. Cuando las usamos, desaparecen, se convierten en una extensión de nuestros cuerpos; no pensamos en ellas, pensamos en lo que estamos haciendo con ellas. Como tecnólogos, experimentamos los sistemas que construimos como un fin (no como los usuarios, que para ellos es un medio). Para nosotros, el software es un objeto de estudio. Sin embargo, es crucial que los usuarios experimenten el software que hacemos como herramientas invisibles, herramientas manejables que faciliten su trabajo (zuhanden).


  6. Encuentra y Retiene a Apasionados Solucionadores de Problemas: Armar el dream team de desarrolladores y mantenerlo unido es una de las tareas más importantes del arquitecto para asegurar el éxito de un proyecto de software. Busca desarrolladores que además de los conocimientos técnicos necesarios, tengan pasión por resolver problemas. Las herramientas cambiarán con el tiempo. Necesitarás desarrolladores que diagnostiquen problemas de rendimiento, que resuelvan problemas sin depender de las herramientas. En las entrevistas, pregúntales qué cambiarían de su proyecto anterior si tuvieran que empezar de nuevo. Los buenos desarrolladores son en general motivados por el reconocimiento. No pierdas oportunidades para levantar su moral si se lo merecen. La importancia de preservar a los buenos desarrolladores nunca debe ser infravalorada.

  7. El Software no existe Realmente: No es realista asumir que puedes implementar un diseño de la misma forma en que lo hacen las ingenierías más tradicionales. El software no es tangible como un edificio. Tanto los negocios como el software son entidades vivas en movimiento. Se suele decir que las decisiones de arquitectura de software son difíciles de cambiar, pero no tanto como mover la ubicación de un puente en medio de su construcción. Esto hace que la planificación no pueda ser tan rígida y que no haya un orden único de implementación que asegure minimizar los riesgos. Recuerda que un documento de requerimientos no es un plano y que el software es una entidad cambiante e intangible.

  8. Pague su Deuda Técnica: La ruta "rápida y sucia" para solucionar bugs o implementar nuevas funcionalidades genera deuda técnica. Pagar esa deuda mañana significa volver al problema original y solucionarlo de la forma en que se debería haber solucionado si hubieras tenido el tiempo y los recursos para hacerlo bien la primera vez. Las deudas técnicas tienen costos ocultos, intereses que se materializan en inestabilidad del sistema, aumento en el costo de mantenimiento, diseño, documentación, testing. A veces tiene sentido meter un cambio ASAP, sobre todo cuando el sistema está en producción, pero debes comprometerte a pagar tu deuda una vez que pasó la urgencia. De lo contrario, los intereses terminarán destruyendo el proyecto.


  9. No Puedes Ofrecer Soluciones a Prueba de Futuros: Las soluciones de hoy son los problemas de mañana. Nadie puede predecir el futuro. Hay arquitectos que tratan de diseñar los sistemas "a prueba de futuros"; sin embargo, todas las decisiones se volverán obsoletas eventualmente. El lenguaje de programación cool que usas eventualmente se convertirá en el COBOL de mañana. Elige las mejores soluciones que se ajusten a las necesidades de hoy. No caigas en la parálisis del análisis.

  10. El Problema de la Aceptación del Usuario: Los usuarios no siempre están contentos con los nuevos sistemas o las mejoras importantes. Como arquitecto debes estar consciente de este problema y considerar las razones, que pueden ser: miedo a perder funcionalidades que tenían en el sistema anterior, miedo a perder poder en un cambio de roles, miedo a nuevas tecnologías todavía no probadas, preocupación sobre los costos del nuevo sistema, o incluso la sencilla razón de que a las personas no le gustan los cambios. Comienza temprano a mitigar estos miedos: discute con los usuarios finales sobre las ventajas y desventajas de las nuevas funcionalidades, planifica capacitaciones y demos en etapas tempranas. Hazlos parte del proyecto compartiendo el nuevo conocimiento.

  11. La Importancia del Consomé: El consomé es un caldo que, bien hecho, debería ser muy claro. Se considera todo un desafío hacer un buen consomé, bien bien claro, porque sólo hay una manera de eliminar los sólidos y es con mucho esfuerzo y refinamiento. La arquitectura de software requiere un refinamiento continuo de pensamientos: ¿qué significan estas propiedades?, ¿y estas relaciones?, ¿cómo podemos hacer más explícito este concepto? Aclaramos nuestros conceptos para que las relaciones dentro de la arquitectura sean verificables e internamente consistentes, refinamos los requerimientos con precisión quirúrgica para eliminar la redundancia, la ambigüedad, las suposiciones injustificadas. Los conceptos son pasados una y otra vez por un tamiz para clarificarlos lo más posible.


  12. Para el Usuario Final, la Interfaz es el Sistema: Existen demasiados buenos productos escondidos detrás de malas interfaces de usuario (UI). Si la calidad de la experiencia de usuario (UX) sufre, la impresión del usuario sobre el producto también va a sufrir. Debes contratar a los mejores especialistas en UI y UX desde etapas tempranas del proyecto para que acompañen durante todo el desarrollo. La usabilidad es uno de los requerimientos no funcionales que más conciernen al arquitecto de software. La interacción del usuario con el sistema debe ser un factor fundamental para las decisiones de diseño y arquitectura. Los cambios en la UI deben ser documentados de la misma forma que los cambios en el código. Sobre este tema, recomiendo leer el siguiente artículo: La Interfaz de Usuario es la Aplicación, por Jeff Atwood.

  13. El Gran Software no se Construye, se Cultiva: Arquitecturas grandes llevan a proyectos grandes, más propensos a fallar, más difíciles de probar, más frágiles, con mayor complejidad incidental, inercia y componentes innecesarios. Resiste la tentación de querer diseñar todo el sistema al comienzo. Tener una gran visión y un diseño simple te ayudará a ser flexible. Comienza con una pequeña arquitectura ejecutable, lo más simple posible, que satisfaga los requerimientos fundamentales, y luego deja que evolucione. Hazla testeable desde el día cero. Mantén bajo el nivel de acoplamiento entre componentes cada día. Despliega continuamente en producción, desde el día en que tengas esta semilla. Aprende de los errores cuando son pequeños y su solución casi trivial. En estos principios se basan los conceptos de Arquitectura Evolutiva y Diseño Emergente.
Y con esto llegamos al final de esta serie de posts. La Arquitectura de Software es una disciplina muy joven; incluso dentro del joven mundo del software. Queda mucho por debatir, mucho para aprender. Los roles en un proyecto de desarrollo de software todavía están confusos. Hay varias escuelas de pensamiento y varias generaciones viviendo en el ecosistema de las empresas, y las descripciones de los roles pueden variar de proyecto en proyecto. El año pasado escribí un poco sobre esto en el post Sobre Arquitecturas y Arquitectos, donde hablo incluso de distintos tipos de Arquitectos dentro de la disciplina de sistemas.

Si llegaron hasta aquí y les interesó esta serie de posts, probablemente también les interese leer acerca de los principios o axiomas que no entraron en el libro 97 Cosas que un Arquitecto de Software Debe Conocer pero que sí las incluyeron en su página web: Otras Cosas que un Arquitecto de Software Debe Conocer.

lunes, 3 de marzo de 2014

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 6

Este artículo forma parte de una serie de posts en los que traduzco y resumo los principios del libro 97 Cosas que un Arquitecto de Software Debe Conocer.

Los post anteriores pueden leerse en:
Continuamos con los siguientes 12 principios:
  1. El Negocio V.S. el Arquitecto Enojado: El negocio es nuestra razón de ser. Vivimos para servirlo, no al revés. Escuchar y entender el negocio que nos emplea para resolver los problemas es la habilidad más importante que poseemos. Muestra a los expertos de dominio el respeto que tú mismo esperas recibir. Cuando estás hablando, sólo puedes escuchar algo que ya sabes. Nunca pienses que eres tan inteligente que nadie más tiene algo valioso que decir. No te permitas convertirte en un genio descontento que pasa todo su tiempo tratando de impresionar a los demás, haciendo declaraciones condescendientes acerca de lo mal que está manejada la empresa.


  2. Estire Dimensiones Clave para ver Qué se Rompe: Estíralas de forma individual y luego combinadas para desentrañar los límites invisibles que podrían estar ocultos en el diseño inicial. Puedes sobrecargar el sistema para entender si la infraestructura planificada es escalable, y hasta cuánto. Puedes simular cortes de luz, interrupciones, situaciones inesperadas, incremento abrupto de la cantidad de datos a procesar. Necesitas saber si el sistema puede recuperarse. Sobre la base de estos experimentos, los elementos del diseño original pueden ser reconocidos como problemas que requieren rediseño.

  3. Antes que Nada, un Arquitecto es un Desarrollador: ¿Has visto un juez que no fue abogado, o un jefe de cirugía que no fue cirujano? Para ganarte el respeto y la confianza de tus desarrolladores, tu código es lo importante. Debes demostrarle a los programadores que tú podrías programar la arquitectura que presentas. Como arquitecto, tu principal objetivo es crear una solución viable, mantenible y, por supuesto, que resuelva el problema que debe resolver. Recuerda: lo que diseñes, debes ser capaz de codearlo.

  4. Una Rosa con Cualquier Otro Nombre Terminará como un Repollo: Si no sabes cómo debe ser llamado algo, entonces no sabes qué es. Si no sabes qué es, no puedes sentarte a escribir el código. ClientAPI, ClientBusinessObject, son nombres que se usan para no nombrar nada. Diseñar significa tratar de cumplir con intenciones y los nombres sirven para transmitir dichas intenciones. Si no puedes nombrarlo, no puedes escribirlo.

  5. Problemas Estables obtienen Soluciones de Alta Calidad: La habilidad de un arquitecto se encuentra en dibujar límites alrededor de problemas difusos y diversos, para que pasen a ser problemas estables y auto-contenidos. Un arquitecto debe poder aislar los problemas en porciones estables que tengan alta cohesión interna y estén desacopladas entre sí. Porque si el problema es estable y puede ser resuelto, entonces estará resuelto para siempre. Un problema estable permite crear un sistema con un diseño estable, y un diseño estable permitirá que te concentres en una solución de alta calidad.


  6. Se Requiere Diligencia: Diligencia en el sentido de atención, celo, cuidado. Un arquitecto es diligente con cada tarea y cada objetivo del sistema. La diligencia va de la mano de lo mundano. Los arquitectos eficaces suelen seguir checklist mundanas para recordar lo que ellos ya saben que funciona teóricamente y que suele fallar en la práctica por culpa del hábito. Sin esas checklist, el arquitecto puede caer en el tiempo del software, donde la arquitectura se escapa de los límites de lo visible, no hay progresos medibles y abundan las trampas que hacen girar en círculos a los programadores. La diligencia también requiere aceptar compromisos y disposición.

  7. Hazte Responsable de tus Decisiones: 1) No afirmes que una decisión de arquitectura fue tomada hasta que su justificación no haya sido puesta por escrito y no haya sido comunicada a las personas afectadas directa o indirectamente. 2) Revisa tus decisiones periódicamente, examina los resultados obtenidos, identifica cuáles siguen siendo válidas y cuáles no. 3) Acompaña al equipo durante el desarrollo, asegúrate que las decisiones arquitectónicas se cumplan. 4) Delega algunas tomas de decisiones en otros expertos. Los arquitectos tienen áreas en las que son muy competentes, áreas en las que están bien informados, y áreas en las que son simplemente incompetentes.

  8. No seas un Solucionador de Problemas: Los arquitectos y los desarrolladores aprenden a entrar en el modo de resolución de problemas inmediatamente, pero a veces la mejor solución no es una solución. Muchos problemas de software no tienen que ser resueltos en absoluto. Parecen problemas porque miramos sólo los síntomas. Nos olvidamos de analizar, de interrogar, a los problemas. Debemos aprender a subir y bajar por las capas de un problema, a alto y bajo nivel, para garantizar que las preguntas sean formuladas correctamente y no aceptar simplemente las que nos dan ya formuladas. No debemos ser receptores pasivos de requerimientos.


  9. Elige tus Armas con Cuidado, Renuncia a ellas de Mala Gana: Es un error renunciar a la lista de tecnologías y soluciones preferidas, que ya han demostrado funcionar, sólo por abrazar a las nuevas tendencias. A toda tecnología le llega el momento de ser reemplazada. La tecnología avanza y soluciones más efectivas están en camino. Como arquitectos tenemos que estar al tanto de las tendencias de la industria, pero no tenemos por qué ser los primeros en adoptar las tecnologías incipientes. Antes de abrazar una nueva tecnología, pregúntate cómo el negocio se beneficiará con esa decisión. Es ingenuo pensar que una nueva tecnología no vendrá con sus propias trampas y la adición de problemas que no se han resuelto antes destruirán tus estimaciones. Tratar de predecir de forma temprana las nuevas tecnologías que se impondrán es una apuesta que no deja buena recompensa. Espere a que la tecnología se vuelva mainstream y evite poner en riesgo al proyecto eligiendo algo que no tendrá futuro.

  10. Tu Cliente no es tu Cliente: Los clientes de tu cliente son tus clientes. Si estás escribiendo una aplicación de comercio electrónico, ten cuidado de las cosas que sabes que la gente que va de compras va a necesitar. Tu cliente puede no mencionar estos requerimientos. Es tu trabajo comunicárselos y explicar por qué crees que serán importantes. Si los clientes de tu cliente ganan, tu cliente ganará y tú ganarás también.

  11. Nunca se Verá Así: No importa cuánto hayas pensado, investigado y profundizado tu diseño, nunca se verá igual que en tu cabeza. Siempre un factor externo lo arruinará: información incorrecta, descuidos, suposiciones incorrectas, cambios de requerimientos, de tecnología... Estas alteraciones mínimas pronto se irán acumulando. En poco tiempo tu concepto original se hará pedazos y tendrás que sentarte a diagramar, estrenarás nuevo rediseño, una visión 2.0 más clara, radical y perfecta de la arquitectura, que los factores externos no tardarán en derribar y en poco tiempo volverás a encontrarte gritando: "¡Por supuesto que tiene bugs, nunca fue diseñado para eso!" Este escenario, tan común en proyectos de software, nos deja como moraleja que el diseño es un proceso de descubrimiento. A medida que implementamos vamos descubriendo nueva información. Al aceptar que el diseño es un proceso continuo y empírico en un mundo siempre cambiante, aprendemos que el proceso de diseño debe ser flexible y continuo también.


  12. Elige Frameworks que Jueguen Bien Entre Sí: Elije frameworks que no se solapen. Cada framework o librería de tercero debería cubrir aspectos o lógica de dominio distinta. Dibuja un diagrama de Venn para entender cuánto se solapan. Las intersecciones agregarán complejidad accidental al sistema. Elije frameworks que sean específicos, cuyas funcionalidades tengan una alta proporción de utilidad para satisfacer los requerimientos. Si un framework viene con un montón de funcionalidades, entonces debería proveer una alta cobertura de funcionalidades valiosas en el proyecto.

miércoles, 12 de febrero de 2014

97 Cosas que Todo Programador Debería Saber

Hace poco se publicó esta genial traducción en español del libro 97 Cosas que Todo Programador Debería Saber, cortesía de Esparta Palma (@esparta).

Fuente: nubelo.com

¡Un trabajo increíble! Cada uno de los 97 principios traducidos por completo.

Esto es posible gracias a que la serie de libros de "97 Things" tiene licencia Creative Commons v3, que permite obras derivadas. Un fruto más de la Cultura Libre.

Pero este trabajo no termina aquí, ya que es mucho más ambicioso. En el sitio 97cosas.com podemos ver los links a 97 Cosas que Todo Project Manager Debería Saber97 Cosas que Todo Arquitecto de Software Debería Saber (libro que yo estoy resumiendo en esta serie de posts, con algunas que otras acotaciones personales). El trabajo de traducción todavía está en progreso, como dicen sus respectivas páginas de inicio.

Lo más curioso es que el sitio 97cosas.com está hospedado en GitHub, donde Esparta Palma incentiva a una traducción compartida. Cualquiera puede hacer un fork del sitio, agregar una página o corregir una existente y después hacer un pull request para que el autor lo suba al dominio correcto.

El build system del sitio está armado con Jekyll, una de esas maravillosas herramientas hechas en Ruby. Después de forkear el repositorio, podemos clonar nuestro fork y trabajar localmente. Como Jekyll incluye un web server embebido, podemos levantar el sitio en localhost y ver al instante cómo va quedando.

Teniendo instalado Ruby, Jekyll se descarga con el siguiente comando:

gem install jekyll

Luego, si queremos levantar el servidor, en el root del repositorio clonado de 97 Cosas ejecutamos:

jekyll serve --watch

Y listo! Vamos a http://localhost:4000 y ahí está nuestro sitio!!

miércoles, 5 de febrero de 2014

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 5

Este artículo forma parte de una serie de posts en los que traduzco y resumo los principios del libro 97 Cosas que un Arquitecto de Software Debe Conocer.

Los post anteriores pueden leerse en:
Continuamos con los siguientes 12 principios:
  1. Comparte tu Conocimiento y Experiencias: Nuestra base de conocimiento fundamental es pequeña comparada con lo que necesitamos para llevar a cabo un proyecto de desarrollo de software exitoso. Todos estamos tratando de crecer para llegar a entender cómo construir sistemas más y más grandes. Para que la industria del software progrese, necesitamos compartir las lecciones aprendidas de los proyectos. No entiendes algo en profundidad hasta que no lo puedes explicar fácilmente. Trata de compartir tus ideas, tus soluciones, tus problemas; si tus ideas y creencias no soportan un debate, es mejor que te enteres lo antes posible y las corrijas.

  2. Asegúrate de que las Cosas Simples sean Simples: Lo menos que queremos es aplicar soluciones complicadas a problemas simples. Si de pronto te encuentras diseñando una solución tan ingeniosa que toma conciencia de sí misma, detente y ponte a pensar: ¿esta solución se ajusta al problema? Si la respuesta es no, reconsidera tus opciones de diseño. Mantén simple lo simple. La sobre-ingeniería a nivel de arquitectura causa los mismos problemas que a nivel de desarrollo, pero sus efectos negativos tienden a multiplicarse. Recuerda esto cuando trates de adivinar requerimientos futuros: el 50% de las veces estarás equivocado y el 49% estarás muy muy equivocado. Soluciona los problemas de hoy con la elegancia justa y necesaria.


  3. Si Tú lo Diseñaste, Debes Ser Capaz de Codearlo: Cuando diseñas la arquitectura de tu proyecto, es necesario que tengas una idea del esfuerzo necesario para implementar cada elemento de dicho diseño. No uses patrones que nunca hayas implementado. No te bases en frameworks en los que nunca hayas programado. No uses servidores que nunca hayas configurado. De lo contrario no podrás brindar buenas estimaciones, no conocerás las debilidades y trampas de tus componentes, perderás la confianza de tus desarrolladores e introducirás riesgo innecesario. Antes que nada, un arquitecto es un desarrollador.

  4. La Variable ROI (Retorno de Inversión): Cada decisión que tomamos en un proyecto puede ser considerada como una inversión. Si para nuestro proyecto el time to market es esencial para los stakeholders, quizá la arquitectura bala de plata que requiere al principio una larga fase de diseño no ofrecerá un ROI tan interesante como una versión alfa rápida. El ROI de cada elección se puede determinar mediante el análisis de sus costes y beneficios y se puede utilizar como una base para tomar decisiones. Éste es un enfoque útil para determinar qué tan pragmática o apta es cada opción.

  5. Tu Sistema es Legacy, Diséñalo para el Mantenimiento: Ten siempre en mente la claridad, la testeabilidad, la correctitud, la trazabilidad. Piensa que un equipo diferente debe abrir el código y averiguar lo que sucede ahí dentro cuando algo no funcione como se esperaba. Un buen diseño se documenta a sí mismo. Todo el software, por más moderno que sea, será legacy en poco tiempo.

  6. Si sólo hay una Opción, Consigue una Segunda Opción: Si sólo puedes pensar en una solución a un problema, estás en problemas. La arquitectura de software trata sobre encontrar la mejor solución posible dada una cantidad de restricciones. La falta de opciones en un arquitecto se puede deber a inexperiencia, en cuyo caso es aconsejable dejar el ego aparte y buscar ayuda, o a la formación mediante el hábito, por ejemplo: un arquitecto que ha aprendido con un único estilo de arquitectura y se ha convertido en su bala de plata para todo.


  7. Entiende el Impacto del Cambio: El cambio puede manifestarse de muchas formas: cambios en los requerimientos funcionales, necesidades de escalabilidad que evolucionan, interfaces que son modificadas, gente en el equipo que va y viene, etc. El papel del arquitecto no es gestionar el cambio, sino garantizar que el cambio sea manejable. Afortunadamente hay muchas herramientas y técnicas para mitigar el impacto: construir en pequeños pasos incrementales, construir casos de prueba repetibles, facilitar la ejecución de las pruebas, trackear dependencias, automatizar tareas repetitivas, etc.

  8. También Debes Entender el Hardware: Para muchos arquitectos de software, el planeamiento de capacidad de hardware es un tema que está más allá de su zona de confort. A medida que una arquitectura evoluciona, los requerimientos de hardware cambian. La mejor opción es trabajar cerca de un arquitecto de infraestructura, invitándolo a formar parte del equipo. Cuando no existe esa opción, podemos basarnos en nuestra experiencia pasada. Hoy en día está la posibilidad de ir escalando horizontalmente a demanda, es una opción, pero para ello debes diseñar tu arquitectura para que sea elástica. Así como el arquitecto de software debe servir de puente entre las demandas del negocio y las soluciones de software, también debe serlo entre el hardware y el software.

  9. Los Atajos de Hoy se Pagan con Intereses Mañana: Es importante recordar que el mantenimiento de un sistema consumirá muchísimos más recursos que su desarrollo inicial. Las malas decisiones tomadas en el inicio de un proyecto se pagarán caro a la hora de rediseñar el sistema para cumplir nuevos requerimientos. Cuando te encuentres con un problema arquitectónico o un defecto de diseño debes insistir en que se corrija ahora cuando es más barato solucionarlo. Cuanto más tiempo se deje arrastrar dicho defecto, mayor será el valor de los intereses.

  10. "Perfecto" es el Enemigo de "Suficientemente Bueno": "Suficientemente bueno" significa que quedan imperfecciones que no impactan en la funcionalidad, mantenibilidad o performance de un modo significativo. La implementación funciona y satisface los atributos de calidad. El código es limpio, conciso y bien documentado. ¿Puede ser mejor? ¡Seguro! Pero no debes caer en la tentación de hacerlo perfecto. Declara la victoria y sigue con otra tarea. ¡El desarrollo de aplicaciones no es un concurso de belleza!


  11. Evita las "Buenas Ideas": Lo peligroso de las buenas ideas es que son precisamente buenas ideas. Cambiar el framework MVC en la mitad del proyecto: ¡sí, vamos a poder usar Ajax! Subir la versión de JPA faltando dos meses para terminar: ¿por qué no?, las Criteria Query son tan cool. Como arquitecto tienes la última palabra, y cedes, porque es tan buena idea, y luego los impactos van destruyendo el sistema, las entregas se van atrasando, el equipo se queda trabajando hasta tarde, fines de semana... Pero todo el sufrimiento vale la pena, ¿no? Era tan buena idea...

  12. Grandes Contenidos Crean Grandes Sistemas: Tener grandes contenidos marca la diferencia entre un sistema hueco y uno relevante. Comparemos Facebook y Orkut, Google y Cuil, Netflix y BlockbusterOnline. Parte del proceso de diseño debería dedicarse a evaluar el inventario del contenido. ¿Hay suficiente contenido disponible? ¿Es fresco el contenido? ¿Fueron contemplados todos los canales (RSS feed, email, etc)? Evalúa el valor de los contenidos y, si los resultados son poco satisfactorios, levanta una bandera roja para advertir a las partes interesadas.

jueves, 2 de enero de 2014

Tweets para el Recuerdo

Empieza un nuevo año y vaticino un 2014 lleno de aventuras, desafíos y emprendimientos para todos. El mundo se mueve cada vez más rápido: las tecnologías, los modelos de negocio, las redes sociales, Internet de las Personas!!

La aventura humana recién comienza.

¡Qué mejor forma de comenzar el año en el blog que con una nueva entrega de Tweets para el Recuerdo! ¡Qué lo disfruten!
¡Feliz 2014 para todos!