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!