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.