“El reto del DevOps ágil” en el Ágiles 2014 de Medellín

Del 23 al 25 de Octubre tuve la oportunidad de estar en Medellin para el Ágiles 2014, fueron unos días bastante intensos, de reencuentro con amigos y sobre todo de aprendizaje, especialmente con keynotes de la talla de Tobias Mayer, Martin Alaimo y en particular Angel Medinilla que al fin (luego del intento frustrado de Lima) hemos podido tenerlo en el Ágiles con su charla “Unicornios, Krakens, equipos autoorganizados y otras bestias mitologicas“.

IMG_0728-2

Este Ágiles también me permitió presentar una charla que tenia planeada hace tiempo, “El reto del DevOps ágil”, tema que a pesar de estar de “moda” en realidad ha sido una necesidad dentro de las empresas, por lo que me alegro mucho el debate y feedback que se genero en la sesión, un aliciente para seguir impulsando el tema y romper las barreras tradicionalmente existentes entre Desarrollo y Operaciones.

IMG_1755

Mención especial merece la visita de Javier Garzas y su charla Verdades incomodas y mentiras reconfortantes… Que aprendí después de trabajar para 80 empresas software en la que nos recordo que sin calidad (y otros elementos que estamos olvidando) no se puede ser ágil.

En definitiva una gran experiencia, y ahora solo toca esperar que los amigos uruguayos nos sorprendan en el próximo Ágiles 2015 que se realizara en Montevideo.

_DSC0171

De “recursos” y “clientes”, de como el uso del lenguaje afecta nuestra motivación

Todo esto empezó cuando publique este twitt:

71 Retwitts!!

Era una idea que me había estado dando vueltas por la cabeza desde hace tiempo, y mas cuando en reuniones con la persona a cargo de un proyecto (a la que trataba de introducir en las bases de las metodologías ágiles) hacia referencias a que “en el proyecto se necesita mas recursos de nivel X y no de nivel Y” “tenemos que estimar la capacidad de los recursos disponibles”, y claro el uso de ese lenguaje me repateaba (al margen del convencimiento de que se podría tener una estimación confiable “desde arriba” pero esa es otra historia) ya que como se ha conversado en varios sitios el llamar “recurso” a una persona equivale a cosificarlo, a ponerlo a nivel de una maquinaria o herramienta.

Y esa deshumanización del personal tiene de la mano no solo el aspecto de valorar a la persona como algo prescindible y fácilmente reemplazable, sino una visión errónea que puede a llegar a inducir que conceptos como el de “pool de programadores” son validos, que si que se nos dirá que la visión de negocio es tratar de reducir los costos fijos y moverse con costos variables, que con una adecuada metodología se puede dar una documentación que fácilmente puede ser convertida en código útil, etc, etc.. lo cual a estas alturas del partido deberíamos tener claro que es un engañamuchachos.

Entonces… ¿a que debemos tender? la respuesta nos la da el Manifiesto Agil en uno de sus items: “Individuos e interacciones sobre procesos y herramientas” (recordemos que llamar a la persona “recurso” lo pone a nivel de una herramienta), siendo asi a lo que debemos apuntar es tender a la construcción de equipos y mejorar la capacidad de estos y claro esta la colaboración entre sus miembros, así que podríamos hablar de “el equipo A tiene que ser reforzado en ….” “la performance del equipo se ha mantenido…”, y claro no olvidarse que los miembros de los equipos son personas, con sus habilidades y debilidades, no una maquinaria.

Como anécdota en cuanto a un uso del lenguaje, me acuerdo de cuando mi empleo de entonces me subcontrato a un consultora mucho mas grande, entonces la responsable de RRHH tenia que darme instrucciones para iniciar mis labores en el cliente y me dijo “tendrás que hablar con XXX del Departamento de Compras…. si.. suena fatal”, es que si, suena fatal que el trato con la gente que va a colaborar en un proyecto de responsabilidad sea caracterizador al igual que…. ¿las sillas?

Pero al pensar en este caso me acorde de otro escenario de cuando el lenguaje utilizado traslada algo detrás que podría ser contraproducente de cara a la cohesión de los equipos, no fue así el caso pero creo que se corrió un riesgo y desaprovecho una oportunidad, me explico: como ya he comentado lo usual para los informáticos es no ser considerado como core dentro de las organizaciones, siendo que la mayoría de los desarrollos se encargan a terceras empresas (con dispar resultado, la verdad sea dicha, pues bien…. cuando una vez me toco trabajar directamente para una “empresa cliente final” (el santo grial de los informáticos en España) me llamo la atención como el responsable del proyecto nos motivaba haciendo alusión al “cliente” y como había que tenerlo contento, lo cual si bien podría transmitir cierta deformación profesional, no dejaba de ser una oportunidad perdida para hacer que el equipo se sintiera mas parte de la cadena de valor del negocio y por ende mas identificado y comprometido con los resultados, motivación que puede estarse perdiendo cuando en las grandes empresas se pasa a ver que tu trabajo ya no es tu trabajo sino tu cliente.

Así que nada es casualidad, aun el uso inconsciente de ciertas formas del lenguaje tiene un significado detrás que debe valorarse para lograr lo mejor posible de los equipos.

Entrevista en la web de la PUCP

De la mano de mi regreso al Perú decidí volver a acercarme a mi universidad, y aparte de colaborar como Jefe de Practica el ciclo pasado desde hace unos meses estoy participando en el Proyecto Consejeros de Carrera de la Bolsa de Trabajo (BTPUCP), es en ese marco que soy contactado por la BTPUCP para una entrevista sobre mi experiencia profesional, mercado laboral y consejos para los jóvenes estudiantes de Ingeniería Informática, entrevista llevada a cabo por Reiner Diaz durante el mes de Agosto, la cual quiero compartir con ustedes a la espera de sus opiniones.

Mi agradecimiento a Reiner y a la Bolsa de Trabajo por esta oportunidad de compartir mis puntos de vista especialmente con las nuevas generaciones de nuestra universidad.

Cuando toca levantar la mano

En el entorno industrial existe la clásica pelea entre el área de ventas y el área de producción: “No están cumpliendo con el plazo que le hemos ofrecido al cliente” “Los de ventas ponen plazos y metas imposibles”, dilema que casi sin variantes se traslada al desarrollo de software, y muchas veces creemos que es un callejón sin salida, pero escarbar un poco lo que paso podría ayudarnos a reducir esta clase de situaciones.
Parte del problema viene de la teoría de “si a los programadores les damos la especificación bien detallada, las cosas saldrá en tiempo y reduciremos problemas” , pero claro, por mas que se  detalle, al momento de construir pasan cosas y vemos que esta idea no es tan simple como parece, y si le añades conceptos como “pool de programadores”… desastre garantizado, en ese sentido es conveniente citar a lo que afirma Rodrigo Corral:

Habitualmente, la réplica suele ser del estilo: "eh!!! Pero si el desarrollador solo tiene que ‘poner ladrillos’ nuestros analistas se lo darán mascado’. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados’. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que ‘poner ladrillos’. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Pude comprobar en carne propia cuando tuve mi primera responsabilidad de gestión técnica, el equipo de análisis nos había dejado especificaciones bien detalladas sobre la funcionalidad de las pantallas a desarrollar, y así emprendimos el camino con mi equipo de programadores, el problema llego cuando nos topamos con dos pantallas en que no nos poníamos de acuerdo sobre como implementar el flujo de acciones de usuario, así que las conversaciones fueron a mas con la analista, resultando que al final llego una contraorden, las 2 pantallas se cancelaban (teniendo que tirar todo el trabajo avanzado) y se reemplazaban por una completamente nueva, mas aun siendo que había dudas sobre lo escrito en la (nueva y detallada) especificación hubo que dedicarle tiempo de conversación de lado a lado con la analista. Así que en este caso bien podríamos haber intentado ajustarnos a la especificación y entregar “algo” que evidentemente luego seria rehecho, pero no, nos correspondía avisar que esa especificación no era consistente y alertar a tiempo (es mas, visto en retrospectiva debimos avisar días antes).

La misma sensación la tuve hace unos meses cuando en una sesión de planeamiento, la Analista/Product Owner propuso un cambio de funcionalidad que entre otras cosas involucraba hacer severos ajustes a la integridad referencial de algunas tablas, el equipo estaba dispuesto a acometer la tarea, pero preferí indicar que los cambios tenían potenciales consecuencias que debían determinarse por anticipado, por lo que cancele la sesión de planeamiento y nos derivamos a una sesión de brainstorming para ir cubriendo las posibles implicancias, para de esta manera ofrecer dos alternativas, con sus pros y sus contras. Para la siguiente semana con ese documento y el apoyo de otro analista técnico la PO pudo decidir totalmente informada y asimismo ser consciente de que el tiempo no era tan corto como ella suponía.

Es que de eso se trata, si como desarrolladores percibimos que la especificación no esta clara o tiene implicancias no previstas, no debemos callarnos, debemos avisar antes de que sea tarde, y por lo mismo reconocer que esa comunicación e interacción de ida y vuelta se va a dar, y no esperar que todo se haga siguiendo ciegamente la especificación.

¿Y tu? ¿Alertas de los riesgos de una especificación a tiempo?

Mandando el mensaje incorrecto al tecnologo

Hace muy poco me reuní con un amigo y nos pusimos al día en diversos temas y como no puede ser otro, en el tema laboral, de entre los cuales surgió una anécdota que tratare de repetir mientras aun esta fresca.

Resulta que este amigo tuvo a cargo a un colaborador al que llamaremos Fulanito, pues bien resulta que Fulanito tenia la carrera superior (5 años en contraste con la técnica) y venia con un perfil de experto en la tecnología usada, amen de dar una confianza en lo que sabia. Mi amigo decidió (por razones de agenda) asignarle un modulo no muy critico en tiempo pero si importante en funcionalidad, confiando en que los conocimientos de Fulanito serian suficientes para que saque adelante el requerimiento.

Resultado… cuando toco el plazo Fulanito no había avanzado casi nada, no dominaba realmente la tecnología ni se había buscado la vida para lograr sacar adelante el encargo, decepción total. Luego mi amigo supo que el episodio se había repetido alguna vez en otra división a la cual Fulanito fue asignado, y de ahí le perdieron el rastro… hasta hace poco, cuando se vienen a enterar que Fulanito ya era Jefe de Proyecto, por lo que en el equipo de mi amigo se preguntaron “¿que? ¿osea que hay que ser un inútil en esta empresa para que te asciendan?”.

Creo que con variantes en esta carrera, todos nos hemos encontrado con el perfil de gente con poca experiencia en la trincheras de código que termina ascendiendo profesionalmente, lo cual generalmente se debe a que uno “sabe venderse muy bien” o por la sencilla razón de de plegarse mejor a las instancias de poder organizacional.

Es lógico que para dirigir equipos se requieren habilidades adicionales a las de un tecnologo puro, así como que se puede perder a un excelente programador y ganar un mal jefe, pero tampoco se debe proceder de una manera que transmita la idea de que se premia al inútil y que el empeño por mejorar técnicamente no conduce a mejoras, percibiendose que solo se asciende si se va por el camino administrativo; así que el premiar esta clase de perfiles y no mirar mas allá de la imagen que transmite “el que sabe venderse” puede perjudicar seriamente a la organización, especialmente a la moral del personal.

Es que claro, a veces a los tecnologos se nos considera algo que funciona por si solo, cayéndose en la idea de que no es conveniente darles formación so riesgo de irse de la organización, siendo al revés: el que se va ya quería irse antes de la formación, y muy probablemente por comportamientos organizacionales como el descrito.

Muchas veces se nos reprocha el ser introvertidos y no marketearnos bien, y si bien hay algo cierto de eso, no es menos cierto que es fatal para una organización el que por no mirar mas allá quienes asciendan sean los vendedores de humo y no el que tiene habilidades reales.

¿Se lo hubieran perdonado a Microsoft?

Sabido es el control férreo que impone Apple, mediante su App Store, a quienes quieren ofrecer aplicaciones para ejecutarse en el iPhone, lo cual se evidencio hace poco cuando los de la manzanita negaron hipocritamente que hubieran bloqueado la aplicación Google Voice para iPhone, se excusaron en que no la habían rechazado sino que aun estaba pendiente de aplicación, se se se.

Ahora lo absurdo viene dado porque a una empresa llamada Bjango se le obligo a remover una funcionalidad de su aplicación iStat, la funcionalidad en cuestión permitía liberar la memoria inactiva del iPhone y de esta manera aumentar la duración de la batería así como mejorar la performance del aparato, a Bjango se le dijo que o quitaba esa característica o su aplicación (que cuesta 1.99$) seria removida del catalogo de App Store, todo esto sin mayores explicaciones de porque era necesario capar al programa de esa manera, osea sin saber que parte del contrato se había violado.

Como comenta la nota, no es la primera vez que Apple actúa de manera arbitraria, había rechazado una aplicación oficial de South Park pero si que había permitido una versión iPhone del controvertido juego Grand Theft Auto, aparte de haber rechazado una aplicación de Nine Inch Nails por contenido “cuestionable”.

Vamos, se sigue confirmando que la manzanita no es tan cool como parecía, pero de momento parece ser que se le siguen perdonando cosas (como a Google) que seguramente a Microsoft no se las hubieran perdonado ni por asomo.

Skype-eBay, la importancia de saber comprar

Semana de adquisiciones, a la controvertida compra de Marvel por parte de Disney, se suma el anuncio de la venta del 65% de las acciones Skype por parte de eBay, en una operación que da como resultado que la empresa tenga un valor un 11% mayor que cuando fue adquirida inicialmente.

Esta compra de por si ya es peculiar si nos fijamos en que eBay ya llevaba mas de un año tratando de vender a esta popular empresa, y que en el camino se había producido la salida de Meg Whitman como CEO de eBay, por lo que cabe decir que eBay ha tenido suerte en lograr el precio que ha logrado, vista su inutilidad en lograr sinergias como resultado de dicha adquisición tal como ya lo había comentado Enrique Dans en su momento:” si tu diversificación no tiene sinergias entre sí, harías mejor devolviendo su dinero a los accionistas para que diversificasen con sus propios criterios, en lugar de obligados por los tuyos. Para Skype, la cosa deja lugar a muy pocas dudas: las sinergias planteadas en su momento por Meg Whitman para razonar la adquisición no se han materializado en modo alguno. No existen complementariedades de ningún tipo al respecto, los propios vendedores no quieren recibir llamadas persistentes de compradores con dudas, ni se ha logrado explotar el efecto red. El crecimiento de Skype, muy fuerte (se ha cifrado en unos 380.000 usuarios al día) se debe exclusivamente a sus propios méritos, no a los de su empresa matriz”

Dentro de todo a eBay no le ha ido tan mal con esa operación, pero habrá que ver que es lo que pueden hacer los nuevos inversores (entre los que se encuentra Marc Andreessen creador de Netscape) en una empresa que todavía tiene mucho potencial, en todo caso este episodio hace notar la importancia de saber valorar la estrategia de expansión, no es cosa de crecer por crecer sino también saber de lo que se es capaz de hacer con la adquisición, así como de evitar los problemas inherentes a la absorción de una cultura por otra, algo que a la larga hace que se pierda el empuje y visión que motivo la compra en un primer momento.

¿Cuándo fue la última vez que mandaste o leíste un telegrama?

En mi caso, creo que fue en algún punto entre 1991 y 1993, nosotros solíamos comunicarnos con mi abuelito (que en paz descanse) mediante ese sistema cuando era urgente hacer contacto, muchas veces dichos telegramas eran para coordinar la hora en que el iba a estar en el Centro Telefónico Comunitario (de Entel Peru) y así poder conversar un buen rato.

Esto bien a propósito de que el presidente de gobierno español José Luis Rodríguez Zapatero no tuvo mejor idea que felicitar mediante un telegrama a Pau Gasol con motivo de haber logrado el anillo de la NBA con los Lakers.

Tiempo atrás, me preguntaba si los libros de texto del curso de Lenguaje habrían cambiado con respecto a cuando los lleve, en ese entonces en las secciones de “Medios de Comunicación” había secciones dedicadas a la “carta” (aun recuerdo cuando compraba papel “Vía aérea” para poder escribirle a mi tía) y otra muy detallada con respecto al telegrama en la que se indicaba que se cobraba por palabras, que era muy rápido, etc; si mal no recuerdo en una ocasión nos pidieron como tarea el conseguir los formularios de telegrama y pegar uno en el cuaderno haciendo un telegrama de ejemplo.

Yo alucinaba con que esas cosas habían quedado en la obsolescencia y que claro… no podría esperar de que en la segunda mitad de los 90s los libros de texto ya incluyeran ese cambio, pero en esta nueva década ya lo deberían haber hecho, osea… tal vez no llegar a explicar blogs y redes sociales, pero si email, Web y mensajería instantánea (que es una URL, que es un dominio), siendo en este caso que un alumno de 12 o 14 años probablemente sepa mucho mas de esto que su propio profesor.

Pero, visto esto que un presidente de un país “desarrollado”, aun usa un “protocolo” del siglo XIX pareciera que aun deben explicarse ciertas cosas, que en teoría ya no deberían usarse (tan así que hace buen tiempo en España la empresa “Correos y Telégrafos” cambio de nombre al más sencillo “Correos” a pesar de que dicho servicio aun se ofrezca).

Por cierto: ¿se acuerdan cuando en RPP decían “…. Y nuestros teletipos continúan recibiendo noticias del exterior”?, hace rato que felizmente lo cambiaron y mencionan a “la Internet”.

Placa nueva asi que a reinstalar XP

Ya habia tenido problemas con mi placa Asus P5B (la normal, no la Deluxe) pues en algun momento dado dejaba de reconocer los puertos USB ademas de que a veces simplemente se negaba a encender, pero llego un momento en que simplemente ya no prendia.

Con esos antecedentes, y dado que queria conservar lo mas posible de mi configuracion original, habia consultado en Noviembre en AsusExperts donde me recomendaron la placa que al final vine a instalar la ASUS P5E WS Professional la cual se supone esta preparada para resistir bastante tiempo continuo sin ser apagada, ademas de que como no juego mucho (casi nada) se centra en la estabilidad y acceso a los discos duros.

Ya que estabamos tambien compre una nueva fuente de poder, solo por si eso tambien era la causa de los problemas, asi pues una vez que tuve encargados los componentes toco hacer los siguientes pasos preparatorios:

Desconectar todos los conectores de la placa antigua, (los discos mantienen su posicion en la caja).

Remover la tarjeta grafica y los 4GB de memoria, guardandolos en lugar seguro.

Retirar la fuente de poder antigua asi como la placa antigua (aun con el chip y ventilador)

Retirar el ventilador de la placa antigua, y luego el chip (lo cual no supe hacer hasta que el vendedor me explico como).

Ya con las piezas en mi casa tocaba montar las cosas asi que coloque la memoria y el chip en la placa con sumo cuidado, las instrucciones decian que lo recomendable era colocar el ventilador una vez que la placa estuviera montada en el case, asi lo hice por lo que tocaba ajustar los tornillos…. oh oh … imposible, se lo comente a mi compañera de piso quien me dijo que (contrariamente al manual) mejor hubiera sido colocar el chip y ventilador primero y luego montarlos en la caja, asi que a retirar la placa y reintentar el proceso…. nada, hasta que me percate que en la parte de atras de la placa antigua habia una guia metalica en forma de “X”, misma que servia para dar agujeros de tamaño suficiente a los tornillos del ventilador (los agujeros propios de la placa eran muy anchos).

Solucionado el problema, ya todo fue cuestion de acomodar los discos, tarjeta de video y demas. Asi que luego de un intento fallido (faltaba apretar uno de los cables de poder) la compu se encendio, luego del consabido ajuste del Bios y de los discos de arranque se pudo inicial el Windows.

Como era una placa diferente procedi a desinstalar diversos drivers, asi como a instalar los propios de ella, por lo que la maquina ya estaba operativa pero…..

La placa anterior no incluia soporte oficial para los chips ICH9R, por lo cual desde Windows XP no podia sacar partido del acceso AHCI (en vez del clasico IDE) a los discos duros, bueno… en realidad se podia pero implicaba editar archivos .inf y usar diskettes, esta nueva placa permite hacerlo, pero como es logico se recomienda que dicho proceso se haga desde la instalacion del Windows, para lo cual se debe preparar un diskette con los drivers (a bajarse de la pagina de Asus) e introducirlo en las primeras etapas de la instalacion de Windows.

Siendo esa la situacion, sumada al hecho de que ya habia probado demasiados programas (los cuales dejan su huella quieras que no) y que no pensaba instalar Vista, me llevaron a la decision de reinstalar Windows (ya habian pasado casi dos años desde la ultima vez, asi que no esta mal), por lo que ya me veia preparando los diskettes para lograr el efecto, hasta que lei sobre un programa llamado nLite, el cual te permite crear discos de instalacion de Windows personalizados, con lo cual se puede agregar “de serie” los drivers especificos de tu maquina, asi como establecer diversas opciones de configuracion (como el teclado) y que no se instalen ciertos componentes de Windows.

Siendo asi decidi probar el programa, agregando de serie los drivers de el ICH9R, los de red, sonido, video y monitor, configurando entre otras cosas la opcion de que se muestren las extensiones de archivo conocidas (ya es cuestion del gusto de cada uno).

En todo caso decidi ser precavido y lo probe con maquinas virtuales, comprobando que efectivamente mis opciones de personalizacion funcionaban perfectamente a excepcion de la Zona geografica, ya que en la instalacion me veia obligado a establecerla manualmente a pesar de haberla indicado al crear mi personalizacion.

Hechas estas pruebas tocaba comprobar si efectivamente se instalaria el soporte AHCI, por lo que configure la BIOS para que funcione de dicha manera (al hacerlo mi Windows de entonces fallaria) y procedi a la instalacion de XP en una particion diferente a la principal, todo OK y muy rapido, y al arrancar lo comprobe…. el modo AHCI estaba ahi en los dispositivos del Windows, de hecho al instalar el Setup indico que usaba los drivers iAstor.sys para acceder a los discos, lo cual ya era buena señal.

En ese momento decicid ver si era posible “reparar” mi Windows para evitar la necesidad de reinstalar….. no, no se podia, asi que a falta de ganas de investigar mas decidi preparar la instalacion, sacando backup de lo existente en la particion raiz, asi como separando los instaladores a usar luego.

Como lo comente, la instalacion transcurio sin problemas, salvo el de tener que indicar la zona geografica  y el hecho de que decidi formatar la particion raiz y evitar problemas posteriores.

Ahora bien, pese a que la maquina ya estaba “fresca” y todo eso en el transcurrir de los dias descubri que era necesario instalar la suite completa de los drivers de video ATI, asi como instalar totalmente los de audio para que funcione totalmente el modo 5.1, hecho esto no ha habido mayores problemas y la maquina va a todo rendimiento.

Conclusiones:

Revisar todo lo que tenia tu fierro anterior ayudara a evitar complicaciones, en este caso lo hice al 80% sin darme cuenta y pasamos un buen rato rompiendonos la cabeza.

Usar nLite es una excelente opcion para simplificar tu instalacion, pero es preferible dejar la instalacion del sonido y el video para cuando el Windows ya este operativo. Aun asi lo recomiendo plenamente para tunear tu instalacion, el hecho de poder evitar el uso de diskettes y especificar de antemano su configuracion aun en cosas triviales como decidir que servicios esten apagados me hacen recomendarlo plenamente.

Dos lecturas recomendadas para este finde

Usualmente no suelo recomendar otros posts sin un contexto previo, pero en este caso vale la pena porque estos dos amigos mios cubren y amplian topicos que ya se han tratado aqui, pero por sobre todo por la calidad del analisis efectuado.

El Bruno se explaya muy bien sobre la necesidad de la presencia de tech-frikis en los proyectos de desarrollo, la necesidad de brindar un entorno donde se sientan comodos, y la falta de vision de algunos responsables de estos proyectos que “tampoco entienden que “sus recursos” no pueden ser tratados como simples piezas de un Lego; teniendo un poco de sentido común es imposible pensar que una persona puede salir de un proyecto y cuando entra su reemplazo, automáticamente se adapta al nuevo equipo, rinde al mismo nivel que su antecesor, etc”.

Vicente, nos trata de manera amena sobre la obsesion de establecer analogias entre los “arquitectos y albañiles” y los “ingenieros y programadores, algo de lo cual ya vimos al comentar sobre cual seria el perfil de un ingeniero informatico, me quedo con la conclusion de Vicente quien a pesar de hace años no tirar codigo nos dice: ” Sigo pensando que la mejor forma de entender un diseño o un patrón es haberlo implementado. Hoy, todavía, un buen ingeniero del software, en general, debe ser o ha tenido que ser en algún momento un buen programador.

Buen y feliz fin de semana.