Todo lo demás.

Todavía le falta algo (dos “cositas”, en realidad) para llegar al “MVP corregido” (el “minimum viable product” redefinido después de haber subido lo que yo creía que era el minimum). Nadie me hizo llegar nada al respecto. El uso es la intersección entre la promoción y la necesidad, y uno sólo puede controlar el primer término. Sin necesidad, la gente juega un poco y listo. Si gusta se agenda el link para después. Está muy bien, pero no es “uso”.

¿Qué hubo entre esos dos MVP’s, además de esas “dos cosas”? ¿En qué cosas ni siquiera había pensado?

Le pongo Analytics y listo.

… no. Analytics está muy bien tal cual sale de la caja, pero se queda muy corto. Permite ver el impacto de un post, de facebook, de tweeter, del mail, pero nada más. ¿Y el uso? ¿Se usa el upload de esquemas? ¿El login con google? ¿El preview de datos? ¿La ayuda?

El event tracking no es difícil de implementar. Lo difícil es determinar qué trackear (qué acciones) cuando uno ya tiene todo desarrollado. Lo que no se trackea no se ve. Trackear un par de eventos y dejar por error dos o tres afuera implica tener una visión muy sesgada del uso. Si lo hubiese pensado desde el principio, agregándolo a medida que se desarrolla la funcionalidad, afinándolo desde el momento 0…

No, no es “demasiado para un MVP”. Saber hacia dónde dirigir el segundo paso es tan importante como dar el primero. Pero hay un argumento determinante por el cual no se puede dejar para después: recolectar un volumen de datos relevante lleva –con suerte- semanas.

Try-catch-mail alcanza, y por las dudas logueo todo.

Me mando un mail con la excepción y ya está bien para empezar, con eso ya sé dónde buscar en el log. No, tampoco. Cortísimo.

Ok, hubo un error. ¿Quién? ¿Haciendo qué? ¿Qué datos de entrada? ¿Qué valores de salida? Los errores que pueden corregirse mirando un stack trace se agotan rápidamente. Después… las cosas se vuelven más complicadas. El “log viewer” de la consola de GAE es por lo menos “rústico”. Excederse por más y generar 1Gb de log por día está bien cuando podemos comprimir, descargar el archivo y procesarlo tranquilamente, pero no es el caso. Una posibilidad es recolectar parámetros de entrada y valores de salida de todas las funciones pero loguearlos sólo cuando hay un error. O afinar el log para cada operación, o guardar los errores aparte, en la base… Lo que sea, pero no es tan simple como un try-catch-all.

Cada error es un usuario–casi-perdido, y usuarios no sobran.

Malditos celulares.

¿Para qué miércoles quiero dar soporte a celulares en un data generation tool? Si, que se pueda ver… pero no importa si no es usable, no es una aplicación que tenga sentido en un smartphone. Y en la primera versión ni eso, que se vea como se ve. Total foundation ya ayuda bastante sin que hagamos nada.

Error. La aplicación no se usa en un smartphone… pero el 50% (50% medido, no es un decir) de los usuarios entra por primera vez desde uno. ¿Por qué? Y… si promociono por twitter y facebook… ¿qué esperaba? No esperaba nada - señal de que estoy viejo.

No tiene que ser usable, pero es indispensable que sea “probable”, “jugable” o al menos “agendable”. Como mínimo –muy mínimo- que puedan decir “ok, avisáme después.

Lo ideal sería que se pueda jugar un poco, abrir una cuenta y grabar. Bueno… más trabajo (y esto no está incluido en “las dos cosas”).

Consola de administración.

Paráaaaa… ¿un backoffice para un data generation tool? Si.

Estoy usando objectify. Muy lindo, muy rápido el desarrollo de todo, pero… el acceso a datos desde la consola es incluso más rústico que el log. Lo que objectify graba ya es bastante difícil de leer… Si un error “rompe” la cuenta de un usuario (se graba algo y luego le da error cada vez que entra) estamos al horno: corregir esa especie de “assembler de datos” es demasiado peligroso o directamente imposible (ni lo intenté).

Guste o no hay que hacer una página de administración donde podamos ver la data en forma prolija y modificarla si es necesario. Y no podemos empezar a hacerla sobre el hecho de que ya hay alguien que no puede entrar a su cuenta. Y también va a tener sus errores.

Y todo lo demás.

Y, finalmente, las “dos cosas” de las que hablaba al principio. Esas son las únicas dos funcionalidades propias de la aplicación de toda esta lista. Pero no voy a decir cuáles son. Talvez ni hagan falta.

Una buena

Son cosas simples (aunque no “tan simples”) si se las tiene en cuenta desde el principio. Bueno, para esto era, ¿no?

The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

Mi aplicación

Casi todos (los programadores, obvio) tenemos “mi aplicación”. Ésa que, cuando haya tiempo, vamos a hacer “como se debe”.

El “como se debe” varía con cada uno, pero me arriesgo a generalizar: no es una afirmación positiva sobre ciertas herramientas y prácticas, es más bien una negación de aquellas que venimos utilizando, utilizamos o nos obligaron a utilizar, o de las que escuchamos hablar mal por ahí o… un largo etcétera.

En criollo: “mi aplicación” no va a ser como éste proyecto-huérfano-engendro-mutante del que me contaron, caí o armé (“por culpa de…”, seguro).

¿Cómo es “mi aplicación”? La mía de mi propiedad, al día de hoy, es:

-Una aplicación web hosteada en google.

-Server side: en java, pero va a devolver exclusivamente JSON. Pura data. Lo juro.

-Con alguna base de datos no relacional, porque son re-cool.

-Bootstrap.

-Pero no pienso escribir una sola regla de css. Lo juro.

-Ni tampoco mucha imagen ni iconito. Si puedo quedarme sólo con lo de bootstrap, mejor.

-Ni meterle 10.000 plugins (aunque ya empecé… pero lo voy a deshacer, y cuando lo deshaga lo juro).

-Jquery

-Jquery validation, si hace falta (imagino que sí).

-Knockout.

-Require.

-Y visjs, porque necesito algo así.

-Y NADA más.

El problema es… el de más arriba: que es cuasi-simétricamente-opuesto a todo lo que alguna vez hice: no soy diseñador ni mucho menos (estoy aprendiendo que entre “seguir la onda”, y “diseñar” hay un abismo insondable). Nunca programé en java (profesionalmente, proyectitos de prueba hicimos todos). Nunca usé bootrstrap. De íconos y gráfica o imágenes… sólo sé buscar en google, y al photoshop no me lo presentaron (ni siquiera sé usar bien el paint.Net). Visjs es genial, pero todavía estoy leyendo la documentación. Los únicos viejos conocidos son Knockout, require, jquery y compañía. Pero son herramientas, no una forma de trabajar con la que uno viene acostumbrado, y en la que “el camino para hacer tal cosa” aparece casi naturalmente.

Como todo primer intento, es… bueno, como se imaginan que es. Pero hay que seguir haciendo y rehaciendo hasta que salga. Mentalmente, claro, porque en la real realidad, uno va dedicándole horas a cuentagotas entre proyectos más rentables, con la esperanza de que en algún momento éste también lo sea.

Si bien “construir éste sistema lo antes posible” es la madre de todas las cag…, también es la madre de todas las cosas que están ahí afuera en este preciso momento, satisfaciendo necesidades de éste preciso momento, probablemente tan efímeras como la combinación de herramientas que (ahora) “me gusta”.

“Como a mí me gusta” va variando a medida que avanzamos. A veces más, a veces menos, pero siempre, con cada paso hacia adelante, surge el imperioso impulso de pasarle la guadaña a (casi) todo lo que se deja atrás… y uno va y lo hace. Porque ésta es “como a mí me gusta”. Es inevitable: la motivación parte de “armar un proyecto como a mí me gusta”, y no “construir éste sistema lo antes posible”.

Pero bueno, juntar dos o veinte librerías, copypastear un poco de código y salir con algo rápido a ver si pega es, probablemente, eficaz. O por lo menos un fracaso rápido y a otra cosa… pero no es lo que tengo ganas de hacer ahora.

Tengo ganas de seguir jugando.

Y a todo esto… ¿qué hace, exactamente, “mi aplicación”?

Por ahora, nada.

¿Qué debería hacer?

No está muy claro, ya veremos. Lo importante es que “esté como a mí me gusta”.

¿Verá la luz del sol?

Visibilidad.

Gran Proyecto (con mayúscula), muy “visible” para la gerencia de Megaempresa, vital para la subsistencia de NoTanGranPeroGranConsultoraOSoftwareFactory, y por tanto muy “visible” también para la gerencia de ésta última.

Desde nuestro punto de vista (de sistemas) no es más que otra aplicación de formularios que le pegan una y otra vez a una base de datos, más un sinfín de reportes que vienen a sacar lo que los formularios pusieron.

Otra gran, torpe, enmarañada, traicionera, e incansable generadora de un aburrido caudal de incidentes de fácil solución técnica, y que serían de fácil solución a secas si no fuera por el hecho de que más o menos la mitad de ellos contradice lo que indica la otra mitad.

Así que una horda de programadores armada con papel secante intenta contener ese río, resuelve uno y otro y alterna entre “A” y “no A” en un proceso que arroja tanta agua como recoge.

Hay otro caudal que lo alimenta, un caudal de programadores, analistas, managers y demás sacos de carne “recursos” que van pasando, pasando y pasando a ritmo creciente. Si no fuera por este otro caudal que aporta toda la energía desperdiciada en aquél ida y vuelta inútil el proceso descrito sería el santo grial del movimiento continuo.

Los gerentes, como esto es importante, están en contacto con “el equipo”, los conocen, interactúan con ellos más que con el resto. Es a esto a lo que se le llama “visibilidad” y que consiste en que, de vez en cuando, se abre un espacio en esos cielos y asciende alguno, (probablemente aquél con más habilidad para el alpinismo que para la programación) dejando al proyecto, que es realmente importante, en manos del resto que ahí queda, papel secante en mano (mientras el alpinista saluda desde lo alto).

Así es que, gracias a la “visibilidad” del proyecto los otros reman, reman y reman hasta que, hartos y sin esperanza, abandonan en busca de algún horizonte en donde sus entrenados brazos sean mejor recibidos. Aquellos en los que el entrenamiento no hace efecto y que por lo tanto carecen de otras expectativas (que los hay), esperan pacientemente su turno para el ascenso.

Unos y otros son reemplazados velozmente, así que eso que llamamos “equipo” (y que no es más que un fotograma de una película interminable) apenas puede acumular una muy vaga idea del negocio que el sistema viene a sostener, ya que el escaso conocimiento penosamente adquirido por prueba y error se va tan rápido como se acumula. Del negocio se sabe que es grande y millonario y que no es una verdulería ni un almacén de ramos generales, pero eso no alcanza para dividir las aguas y tomar la mitad de correcciones que corresponde para parar la rueda.

En fin… cualquiera que trabaje en sistemas un tiempo es expuesto a una de las más generosas fuentes de fina ironía que esta vida puede dar: el trabajo y, sobre todo, el trabajo en sistemas y, sobre todo, el trabajo “corporativo”. Si este tiempo es más o menos largo el sistémico, si sobrevive y lo sigue siendo (o mejor dicho, para sobrevivir y seguir siéndolo) habrá desarrollado un fino sentido de la ironía y del humor, o un cinismo a toda prueba, o todo eso junto. Por suerte algunos explotan genialmente esos efectos colaterales esas habilidades, y así tenemos a Dilbert (adivinen de dónde sacó Scott Adams la inspiración para sus personajes), o a Sinergia Sin Control, o al mayor repositorio de esfuerzo sin sentido y desperdicio de inteligencia jamás creado, TDWTF.

Porque lo más irónico de todo es que funciona y que buena parte de nosotros hemos vivido o viviremos de ello, y que es lo que termina financiando los juguetes (lenguajes, metodologías, herramientas, patrones, arquitectura) con los que nos entretenemos mientras, distraídamente, hacemos girar la rueda. En fin…

…que al mundo nada le importa
yira…
yira…

Visual Studio 2010: T4 Text Templates. Una introducción y recursos para empezar.

Creo que hace ya un par de semanas que ha salido Visual Studio 2010 RC. En el trabajo comenzamos a prepararnos hace ya un tiempo, utilizando la beta, y recién ayer actualizamos a esta última versión.

Mi percepción es que está sobre todo más estable. Han habido más correcciones que cambios, lo que es esperable dado el grado de madurez del producto. Por lo que hizo a mi trabajo en estas semanas (.Net MVC, mucho $(javascript), templates) noté muchas mejoras en el intellisense y la depuración en javascript -que hasta ahora era imposible de utilizar por lo limitado- aunque sigue sin ser la gran cosa comparado con FireBug, mi caballito de batalla.

Pero volvamos al tema del título. Las plantillas T4 para generación de código. De las novedades del 2010, ésta es la que más impacto real (y positivo) ha tenido en los proyectos, automatizando infinidad de pequeñas tareas tediosas y repetitivas.

Dije “pequeñas” porque, para las “grandes” tareas automáticas y repetitivas (generación de entidades, table gateways, row gateways, manejo de recursos de texto, etc.) teníamos ya infinidad de opciones, desde herramientas propias de .Net (como los recursos incrustados o los archivos .resx con sus clases asociadas), frameworks (Entity Framework, NHibernate), diseñadores (como los clásicos diseñadores de Datasets), plugins (no soy de utilizarlos, así que ni ejemplos puedo dar), hasta otros sistemas de generación automática de código, muy similares a T4 (CodeSmith).

Pero el tema con las herramientas mencionadas es que requieren mantenimiento, instalación, depuración, y una inevitable y nada despreciable curva de aprendizaje… pero sobre todo, que son pesadas y abarcativas (para utilizarlas razonablemente tenemos que seguir su paradigma, adaptando nuestro esquema desarrollo a éste en mayor o menor medida). Son muy buenas herramientas, pero nadie va a meterse con CodeSmith (sólo por dar un ejemplo), si no lo está ya utilizando para otra cosa, sólo para actualizar una lista de constantes o una enumeración de ciertos recursos.

Las ventajas de T4 en el Visual Studio 2010 tienen que ver justamente con ésto: están integradas al entorno de desarrollo y su sintaxis es muy intuitiva (a cualquier desarrollador le alcanzará con saber que “es como hacer una página .aspx” para empezar), perfectas para automatizar esas pequeñas, molestas, y usualmente numerosas tareas de copiar, pegar y modificar.

No voy a seguir con mucho detalle, ya que hay mucho (y mejor) escrito sobre el tema. Pero sí los voy a dejar con algunas recomendaciones de punto de partida:

T4: Text Template Transformation Toolkit: este post de Oleg Sych es un muy buen lugar para arrancar velozmente, y tiene además su propia (y extensa) lista de recomendaciones.

La documentación en MSDN es enrevesada y difícil de seguir, como toda la de Microsoft, pero está bueno pegarle una leída, no para empezar sino para conocer más en detalle.

Punto aparte y mención especial para este otro post de Oleg Sych, en el que hace referencia desde el template al modelo de objetos de Visual Studio (EnvDTE) que abre la puerta a posibilidades realmente interesantes.

Frases: olvidar, recordar, entender.

Díme, y olvidaré,
muéstrame, y recordaré
involúcrame, y entenderé.

Tell me, and I will forget,
show me, and I may remember,
involve me, and I will understand.

Confucio (450 a.C.).

Desafíos.

Un desafío es el deseo de alcanzar un objetivo ubicado un poco más allá (no demasiado, porque si no ya sería un sueño) de nuestras capacidades actuales. Implica mejora, autosuperación.

Para mí, lo motivador de mi trabajo es lo desafiante que puede llegar a ser. Frecuentemente se nos plantean proyectos parecidos a aquellos que enfrentamos en el pasado pero con algún matiz, algún punto oscuro, alguna particularidad especial que nunca hemos implementado. Estas particularidades representan nuevos problemas y son las que hacen al proyecto desafiante en esa medida justa que nos permite enfrentarlo con cierta confianza sin llegar al extremo de la sensación del salto al vacío.

Cuando no es así simplemente me aburro, y no tolero bien el aburrimiento. A mediados del 2009 di el salto y cambié de trabajo. En su momento actué guiado más por esos sentimientos –de aburrimiento- racionalizados que por razones objetivas. De alguna manera ese creciente aburrimiento ante los problemas y situaciones han alimentado este blog -inmejorable vía de escape- en la primera parte de este año (y a cuya ausencia se debe, en cierta medida, la poca producción bloggera de la segunda).

Finalmente el tiempo puso las cosas en perspectiva y el nuevo entorno me da un punto de comparación. Me llama la atención lo nimio, lo poco importantes que eran los problemas y situaciones que ponía como excusa del cambio. Ahora es claro que esa necesidad de cambio no estaba dada por el entorno sino que provenía de mí mismo, que su origen no era la gravedad o repetición de algún problema o situación sino el nulo desafío que éstos representaban para mí. Pareciera que “nulo desafío” implica que todo era “fácil”. Nada más lejos de lo que quiero decir, aquí vamos.

El punto central de toda esta cantinela es que uno no sólo “es parte de” sino que también construye la situación que lo rodea. Decir “no habrán nuevos desafíos” es, en realidad, una vuelta retórica por la que esquivamos la responsabilidad en la construcción de esa situación al ubicar a los desafíos en el entorno cuando en realidad están en nosotros.

Los desafíos no están allí, uno no los encuentra sino que los crea. Es decir que constantemente enfrentamos los desafíos que nos hemos creado, como Don Quijote contra los molinos de viento.

Un entorno de trabajo desafiante no es, por si queda alguna duda, algo objetivo. Lo que para unos es tierra fértil es desierto para otros, no por la dificultad o no de los problemas objetivos a resolver –finalmente el único problema objetivo lo constituyen los requerimientos de un cliente-, sino por la predisposición o no de cada uno a crear desafíos en ese entorno en un momento determinado.

Pareciera ser, entonces, que a nivel institucional hay poco que se pueda hacer para crear un entorno desafiante, dado que esta característica reside en cada persona y no en ese espacio creado grupalmente.

En alguna medida es así. No se pueden “crear” desafíos institucionalmente. Pongamos un ejemplo: se plantea “ser referencia en el uso de la tecnología X” como un “desafío en el que todos tenemos que estar comprometidos”. Esto es en realidad apenas un objetivo y una expresión de deseo que puede ser origen de un desafío motivador para algunos pero indiferente o incluso fuente de sentimientos negativos –inseguridad, presión, rechazo- para otros.

Lo que sí se puede hacer institucionalmente es ubicar a cada integrante en un puesto en donde los problemas objetivos –los requerimientos de sus clientes externos o internos- estén alineados con su predisposición a crear desafíos en torno de esos problemas y proporcionar los recursos, la libertad de acción o la guía que necesite cada uno para superarse. Esto será mucho más productivo que el vano intento de imponer desafíos a diestra y siniestra como si todos fuéramos iguales y nos interesaran las mismas cosas.

Pero esto implica un conocimiento muy personal de cada integrante del equipo por parte de la institución… mejor dicho por parte de las personas que definen los puestos en las instituciones y que –erróneamente o no- generalmente están muy alejados del resto de la empresa, si no física por lo menos profesionalmente.

La solución común, dado que a nivel institucional no puede haber un conocimiento personal profundo de cada uno, es dividir la responsabilidad entre persona e institución: la responsabilidad institucional es de abrir las puertas, proporcionar los caminos para que cada uno busque o cree ese lugar desafiante, y está en cada uno la responsabilidad y el esfuerzo de motorizar esa búsqueda. Motorizar es buscar, proponer, convencer, buscar alternativas, concretar.

Es tan común en sistemas la queja constante sobre las posibilidades de desarrollo profesional (“de encontrar nuevos desafíos”) como la inacción de quien las enuncia en cuanto a la creación o búsqueda de ese espacio fértil en desafíos profesionales.

De ser sincero el deseo, de existir esa búsqueda y de ser infructuosa, debería continuar por fuera (pero ya basta de quejarse), la posibilidad de que no haya intersección entre lo que una persona encuentre como desafiante y las necesidades de una institución en particular existe, y no hay más que hacer que seguir buscando.

Lecciones aprendidas.

En este caso no por mí sino por Sriram Krishnan en Microsoft. Las resumo aquí copiando y pegando los títulos (el resaltado es mío), algunos frases poderosas sin lugar a dudas, de esas que es bueno tener pegadas en las paredes de la oficina:

• Ask for forgiveness, not for permission
• (Most) Screw ups are OK
• Look for the line at your door
• Code is king
• Lone wolf syndrome
• Try out stuff
• New team? Pick people over products
• Get out of your comfort zone
• Ask the uncomfortable questions
• Go say ‘Hi!’
• Praise in public, pull down pants in private
• Best things are taken, not given
• Don’t be an asshole

El desarrollo en la entrada original, imperdible.

Lo que sabemos que sabemos, lo que sabemos que no sabemos, lo que no sabemos que sabemos y lo que no sabemos que no sabemos.

Hay aquí alguien a quien nunca pensé que podría citar –seriamente- en este blog: Donald Rumsfeld. Parece que el tipo se da aires de poeta, y que encima no es tan malo:

The Unknown
As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

—Feb. 12, 2002, Department of Defense news briefing

El poema fue mencionado en el recientemente muerto y resucitado Coding Horror (por cierto, qué vergüenza. Es brutalmente cierto aquello de “En casa de herrero cuchillo de palo” y “Haz lo que digo mas no lo que hago”).

Monkey Business.

Son casi humanos... somos casi monos, mejor dicho.

Visto en La Pastilla Roja

Me deja pensando, al trasladar la situación a nuestra vida laboral, en que –si bien entre otros factores- las reglas de juego tienen un peso fundamental para determinar si será la colaboración, la competición o la indiferencia la característica predominante en un entorno de trabajo.

En todo caso estoy bastante seguro de que las reglas pesan más que las características personales. Somos ante todo animales sociales –al punto en el que sólo sobrevivimos en sociedad-, mucho más influenciables por los que nos rodean que –en conjunto- ellos por nosotros.

¿Se pueden alcanzar altos niveles de calidad –esa esmeralda perdida- en el desarrollo de software sin colaboración, sin verdadero trabajo de equipo? Yo creo que sí, pero es mucho, muchísimo más difícil que en un ambiente colaborativo.

Los costos de un ambiente de “indiferencia” en el que cada uno “sólo hace lo suyo” se ven reflejados en complejas estructuras de control superpuestas que coordinan el trabajo: líderes de esto y gerentes de lo otro, supervisores de lo de más allá y más acá, capas y capas de jefes de jefes cuyo trabajo es apenas un poco más que distribuir información y controlar el correcto ensamblaje de subproductos que se construyen en la base de la pirámide aisladamente, sin visión de conjunto.

Se podría decir que parte del trabajo de esa jerarquía es, justamente, proporcionar una visión de conjunto. El problema es que, para el momento en el que el flujo de trabajo llega a ese nivel de revisión es un poco demasiado tarde para cambiar nada.

Para el momento de revisar la calidad –siguiendo las metodologías tradicionales- ésta está prácticamente determinada –sí, claro que podemos corregir desvíos funcionales… ya sabemos lo que sucede con la calidad del código durante esas correcciones-. Si el producto no cumple con las expectativas –de calidad, no sólo las de cumplimiento de requisitos funcionales- la única solución real es el retrabajo.

La solución propuesta generalmente es dividir el desarrollo en pequeñas etapas y revisar la calidad en cada una de ellas –siempre al final- con la esperanza de que la “suma de las calidades” sea provechosa –siempre al final-, y si así y todo las etapas presuponen productos demasiado amplios, las subdividimos… y luego ponemos a un responsable de cada división y de cada etapa, y ya estamos donde empezamos: jefes de jefes de jefes y poco trabajo real.

En un ambiente de colaboración las cosas son diferentes. La revisión es constante porque nadie es indiferente a lo que lo rodea. Cada corrección es mínima pero se dan constantemente. Es mucho más probable que la calidad final sea –para bien o para mal- toda la que el equipo pudo dar en un momento determinado. En esta situación el retrabajo cobra otro sentido: no es la corrección de lo que –en teoría- podría haberse hecho bien desde un principio sino la materialización del aprendizaje acumulado en el camino.

Pero son las reglas las que determinan si esa colaboración es posible. Si la ruta, -correcta o no, eso se verá al final- está predeterminada a través de un diseño milimétrico, el combustible de horas/hombre está calculado como para llegar con el tanque vacío y encima el vehículo no tiene ventanillas de poco sirve ponerse a pensar si hay o no un árbol en el camino, más vale rezar y esperar que cuando nos bajemos estemos en donde queríamos estar. ¿Parece difícil, no?

Complejo.

Hace semanas que vengo demorando una entrada sobre la complejidad. Es que hay tanto que decir sobre la complejidad que la cosa se vuelve un poco compleja… y soy poco dado a las cosas complejas.

Así que procrastinando otra vez el bendito post –que a estas alturas ya sé que nunca voy a escribir-, picando de aquí y allá en el reader, me encuentro con un -ya viejo- artículo de Joel: The Duct Tape Programmer.

Sencillamente imperdible, un compendio de frases impactantes delicadamente hilvanadas:

Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments […] and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes […]

Ya ven para donde apunta:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project.

Y básicamente eso es todo lo que hay que decir al respecto de la complejidad. Me hizo acordar a esta otra gran frase, que no recuerdo muy bien de dónde saqué:

“Los buenos programadores resuelven los problemas complejos, los grandes programadores los evitan”.

Resolver un problema es ganar una batalla. Eliminar la necesidad de resolverlo es evitar la guerra. Es como la depuración: no se trata de meter más código sino de quitar el que sobra, no se trata de conocer más patrones, frameworks, herramientas, plugins y la mar en coche, se trata de encontrar la combinación más simple que nos permita implementar la funcionalidad necesaria, y de simplificarla todavía más.

Para evitar un problema es imprescindible crear el ambiente propicio para esas preguntas que ponen incómodos a todos: “¿realmente hace falta hacer esto? ¿por qué? ¿para qué? ¿hay otras posibilidades? ¿qué pasa si no hacemos nada?” Son esas preguntas las que llevan al pensamiento lateral, y es por eso que la aparición de respuestas tautológicas nos alertan tempranamente de que estamos perdiendo el rumbo: “Porque sí”, “Porque el cliente lo pidió así” (es casi decir lo mismo), “No sé, pero hay que hacerlo”, “Esto ya está pensado”…

Lo complejo se torna complicado muy rápidamente, casualmente en el preciso momento en el que los ingeniosos desaparecen.

La influencia de la orientación al producto o al cliente en el desarrollo de software - II: La elección de la tecnología.

Esto viene a seguir la serie inciada en el post anterior: I: Los muertos se dejan atrás, que es recomendable leer primero.

---

La elección de la tecnología.

Durante la vida del desarrollo de un producto de software es inusual, aunque cíclico y fundamental, el momento en donde surge la necesidad de determinar la tecnología a utilizar.

Es el tipo de decisiones que hay que tomar en el momento de la reingeniería. Momento que se suele demorar hasta lo inevitable, por lo que los intervalos entre éstas se miden en años, si no en lustros o décadas.

Las razones son variadas y pueden ser tan técnicas como la degradación del código y la obsolescencia del hardware o software de base, o funcionales, como exigencias del mercado demasiado difíciles de implementar en la tecnología actual o la aparición del fantasma de imagen a “viejo y obsoleto”.

Para una empresa orientada al producto una reingeniería es una gran revolución, y suele venir acompañada de grandes cambios y resistencias en el equipo de desarrollo. Integrantes aferrados a la tecnología y metodología en retirada verán sus posiciones de poder o confort atacadas por aquellos familiarizados con las nuevas. La decisión, entonces, afectará inevitablemente a las relaciones de poder establecidas durante años y a las que se generen durante los próximos.

No es, en resumen, el momento de hacer experimentos. El proceso debería comenzar con la investigación de las tecnologías establecidas (nadie recomienda jugarse por aquellas más novedosas) y seguir con pruebas de factibilidad, y prototipos, y más pruebas y…

En una consultora, por otro lado, se inician pequeños o medianos proyectos todo el tiempo, y cada uno es propicio para la experimentación con nuevas metodologías, frameworks, herramientas, patrones… Un error implicará un proyecto tormentoso o (muy inusualmente) fracasado, a lo sumo un par de víctimas fatales, pero nada demasiado terrible.

Lo que degenera en… un paisano ´e cada pueblo. Y sí. Tengo que reconocer que la sensación de tener asignada una “pequeña” tarea sobre un proyecto X, bajarlo del control de código fuente y abrirlo es como la que producen esas escenas en las películas de terror en las que la mano se acerca al picaporte de la puerta… y se acerca… y se acerca… y lo gira… y la puerta se abre y… y entonces uno respira aliviado o grita (“my eyes!”). Hay de todo. Lindo, feo, malo y bueno, y muchas veces hay de todo en el mismo proyecto, en diferentes secciones o funcionalidades.

Pero también es cierto que profesionalmente uno se mantiene al día. Y las herramientas decantan. A la hora de los grandes proyectos (con suerte) las decisiones son más medidas y basadas en experiencia acumulada en proyectos reales (aunque más pequeños) y no sólo en meras pruebas o prototipos.

Al trabajar durante largo tiempo sobre el mismo producto y con la misma tecnología, los desarrolladores tienen la oportunidad de hacerse expertos en ella, con todas las ventajas (mejores resultados, menores tiempos de desarrollo, proyectos “tranquilos”, estimaciones precisas) y desventajas (obsolescencia, encasillamiento, monotonía, pocos desafíos) que esto puede conllevar (que no necesariamente se darán unas u otras).

En contrapunto, una consultora es caldo de cultivo de experimentadores casi compulsivos (el que mucho abarca poco aprieta, dicen), y proyectos cual criatura de Frankenstein, rejuntes de diferentes frameworks y tecnologías cosidos y emparchados de manera grosera…

…o cosidos prolijamente, pero en todo caso grandes contenedores de soluciones redundantes. Es por haber trabajado largo tiempo con un conjunto reducido de frameworks, patrones y tecnologías que conozco a fondo sus posibilidades y desconfío de las herramientas complementarias y complejas que vienen a solucionar problemas extremadamente simples.

Si el peligro al desarrollar un producto es la obsolescencia o el fracaso en la implementación de una reingeniería (y una dolorosa “vuelta atrás”, o un ciclo corto hasta la próxima), el peligro de la experimentación excesiva al trabajar en proyectos relativamente cortos es el desperdicio de experiencia (descubrir siempre nuevos problemas en vez de solucionar los conocidos) y una dispersión de tecnologías que desemboca en un stock de proyectos que nadie puede entender completamente (a menos que sea un experto en Silverlight, .Net, Servicios, jQuery, NHibernet, Active Record, MVC y la mar en coche) y que por tanto sólo pueden ser parchados una y otra vez.

Como siempre, la solución es huir del riesgo, de los extremos. El faro es la simplicidad, y nos alejamos de ella tanto cuando forzamos a una tecnología (tal vez ya obsoleta) a hacer cosas que no existían cuando fue pensada o cuando nos pasamos de rosca innovando y metemos en la misma bolsa (a nivel proyecto u organización) más herramientas de las que podemos nombrar en cinco minutos.

La influencia de la orientación al producto o al cliente en el desarrollo de software - I: Los muertos se dejan atrás.

Arbitrariamente (como toda clasificación) y a muy grandes rasgos, podemos dividir el mar de equipos de desarrollo de software en dos corrientes principales: enfocados al producto y enfocados al cliente.

Los equipos enfocados al producto son responsables del desarrollo de uno o varios sistemas, siempre orientados a un mercado específico (si bien puede ser definido en forma más o menos amplia): sistemas contables, para la gestión de hospitales, comercios minoristas, logística o para el control de determinados dispositivos. El producto (o la familia de productos, entiéndase de aquí en más) requiere mantenimiento y constantemente se prueban e implementan nuevas funcionalidades y cambios para justificar los lanzamientos y generar ventas.

Del otro lado tenemos desarrollos enfocados hacia el cliente: profesionales independientes y equipos de desarrollo en consultoras y software factories de todo tipo y color que luchan por armar, mantener y ampliar una cartera de clientes a los que usualmente intentan vender de todo, si es software mejor. Algunas están también especializadas en un mercado en particular, pero vale la clasificación en tanto no vendan el mismo producto a varios clientes.

Y después hay grises, pero creo que la clasificación abarca a una amplia mayoría.

Hasta ahora he sido desarrollador de productos (aunque más de uno fue acaparado por algún cliente importante). Tenía formada una imagen bastante pobre acerca de la calidad de los productos y del trabajo en consultoras (sobre todo en las grandes, pero es una experiencia que por ahora no tengo), y crucé la línea cargado con no pocos prejuicios y temores. Pero bueno, hay que alejarse de las zonas de confort, dicen.

Han pasado ya casi cuatro meses desde el salto, puedo decir que por lo menos una de las consultoras (por suerte) no es como me la esperaba. Realmente las cosas no son ni mejores ni peores, simplemente distintas, y a esto iba, a hacer un contrapunto.

Los muertos se dejan atrás (aunque hay zombies indestructible).

La huella de toda consultora es un reguero de cadáveres más o menos malolientes: proyectos cuya calidad interna deja mucho que desear, si bien hacia afuera suelen verse bastante bien (que al cliente hay que cuidarlo). El aprendizaje se da de proyecto en proyecto y los primeros en implementar determinadas herramientas o tecnologías son víctimas fatales de la inexperiencia.

En cambio, cuando trabajamos en versiones incrementales del mismo producto, siempre sobre la base de código de la versión anterior, poco a poco la experiencia se materializa en todo el proyecto a través de revisiones y refactorizaciones. El equipo (si no es testarudo) no tarda en darse cuenta de que si se mueven las lápidas y se dejan las tumbas los muertos se convierten en fantasmas que nos acecharán eternamente. La única forma de sacárselos de encima es buscar el cadáver y darle cristiana sepultura.

A cierta distancia de la línea de entrega de un proyecto que se presentará, aprobará (y si te he visto no me acuerdo), es inútil refactorizar y solucionar definitivamente determinadas cuestiones. Llega un momento en el que el sistema “es así” y punto, y aunque (por lo menos para mí) es difícil de aceptar, hay que dar media vuelta y seguir adelante.

Cuando se trabaja sobre un producto toda refactorización es provechosa y bienvenida. Incluso en las reingenierías el código “del sistema viejo” es referencia para determinar detalles de implementación, por lo que cuanto más legible mejor. Así que es sencillo cuándo determinar cuándo es conveniente hacer una refactorización o resolver un problema de fondo: siempre.

En una consultora determinar a ojo cuándo se ha llegado ese punto de no retorno es muy difícil, y los errores en este sentido son frecuentes. Muchas veces las inevitables horas fuera de presupuesto que insumen las correcciones entre presentación y aprobación superan aquellas que hubiesen sido necesarias para la refactorización, y otras veces se van horas de refactorización en funcionalidades con pocos errores y cuya prolija implementación nunca será vuelta a ver.

En todo caso, y en esto he confirmado mis prejuicios, aunque la consultora en sí no pueda desprenderse de algunos muertos devenidos en zombies, la realidad es que desde el punto de vista de un desarrollador en particular es poco probable que una vez abandonado el proyecto se lo vea volver en la misma dirección.

Suficiente, creo, para una primera entrega. Seguimos en la próxima.

El estilo, la legibilidad, los “malos” programadores y el ¿diabólico? codebehind en el Microsoft .Net MVC.

Antes que nada: si usted, querido lector-programador de .Net, no tiene y/o no quiere tener nada que ver con el .Net MVC de Microsoft siga leyendo de todas maneras, que la cuestión va mucho más allá de eso y es interesante.

Los hechos.

El hecho es que en el .Net MVC de Microsoft, las vistas no tienen codebehind. En realidad no es que no tengan o no puedan tener, sino que por defecto no lo tienen, siendo el estilo de codificación sugerido para las vistas más o menos como lo muestra esta imagen:

Es decir, utilizamos los viejos y conocidos tags <% %> para escribir código C# inline en medio del aspx, el javascript y el html. Los controles del lado del servidor (TextBox, CheckBox, DropDown) han sido reemplazados por un helper que utilizamos para no escribir un montón al implementar tareas comunes (como ponerle un valor a un input type=text) pero que es sólo eso, un helper.

Las opiniones

La verdad que es un cambio importante en la forma de pensar y escribir una página web en .Net. Personalmente a mí me ha costado muchísimo adaptarme (y, les adelanto, me he dado por vencido y vuelto al codebehind). Indagando un poco sobre este tema me encontré con que, obviamente, no soy el único.

Pero vamos a las opiniones, y primero las que están en contra (del codebehind): Steven Smith, comentando la reaparición del codebehind en las próximas versiones del framework, dice en su blog que, lisa y llanamente, Codebehind Files in ASP.NET MVC are Evil. Steven no es ningún improvisado, hay que pensar en sus razones (el resaltado es mío):

The problem with having a codebehind file for a View comes down to temptation and habit.  If it's there, anybody who's been using "classic ASP.NET" for the last 8 years or so is accustomed to putting all kinds of things into the ASP.NET codebehind files.  From click handlers to Page_Load to event wireups to changing display settings based on the value of a data item - most web forms apps have a ton of logic in their codebehind files.  And that's great - but not typically how it should be done with ASP.NET MVC.

[…] If having the codebehind file available by default is a temptation to stray from the canonical correct MVC path, then not having it there by default would help most developers do things the right way without thinking about it.

Encontré, en el mismo set de resultados en google, una respuesta de Luis Abreu posteada en su blog en una entrada titulada (obviamente) Codebehind files in ASP.NET MVC *ARE NOT* evil (el resaltado es mío).

Before going on, I understand Steve’s point of view: keeping the codebehind files might lead you to put code that belongs to the controller on the view. As I said, I understand, but I want to believe that a good developer will understand MVCs strenghts and will, after some time, have no doubts on where some behaviour (code) should go.

On the other hand, I’m not sure that removing the codebehind file will be enough for stopping a “bad” programmer […]

Luis tiene un sueño, que yo comparto:

Let me share with you a dream which makes me stick harder with the “pro-codebehind” approach […]

Imagine seeing no more of those <% %> floating everywhere on your aspx page…having a clear separation between markup and code, which doesn’t happen with the current view engine. If you want to really imagine it, just compare the old spaghetti ASP code with the elegance of the ASP.NET web forms page but don’t think about events and view state…just concentrate on the markup. Now be honest: do you preffer the spaghetti or the web form’s approach […] ?

Yo mismo no lo hubiese expresado mejor. Pero esa es mi opinión, es hora de comenzar otra sección.

Mi punto de vista 1: la estética.

Si hay algo que no me gusta en cuestiones de arquitectura (y de desarrollo de software en general) son las opiniones categóricas: “los tags <% %> son el demonio”, “el codebehind es el demonio”, “todo el sql debe estar en la base de datos”, “los parámetros opcionales son el demonio”, “los objetos no deberían tener propiedades”… un largo etcétera. Me parece que se confunden directivas de diseño con reglas inmutables escritas en piedra, tiendo a pensar que el que las pronuncia no está pensando en la situación actual y real del día de hoy sino evadiéndose hacia un mundo perfecto donde la arquitectura y las necesidades son la misma cosa.

Yo soy más del estilo de aquellos Principios de Diseño de Guido van Rossum que publiqué en uno de mis primeros posts. Voy a traer a colación los que me parecen relevantes:

• Hermoso es mejor que feo.
• La legibilidad cuenta.
• Los casos especiales no son suficientemente especiales como para romper las reglas…
• Aunque lo pragmático gana a la pureza.

No hay absolutos, hay momentos en los que hay opciones, herramientas entre las que hay que elegir, ventajas y desventajas. Con Rick Hunter (más que experimentado arquitecto) solíamos terminar este tipo de discusiones con la frase “no nos queda otra… hay que pensar”. No queríamos pensar, queríamos una regla mágica que nos solucionara la vida… si existe la verdad es que nunca la encontramos.

Volvamos al caso. Piensen en los cuatro puntos de Guido, recuerden –si es que han trabajado con él- ASP 3.0. Ahora vuelvan a mirar la imagen de arriba e imaginen esa sintaxis en la implementación de una página realmente compleja. Las interfaces de la vida real son complejas, los usuarios quieren interactividad, quieren ver lo que pasa cuando cambian valores, quieren cosas que llamen la atención sobre los errores lo antes posible, no son un formulario en el que el tipo introduce datos, aprieta un botón y se va a su casa.

Yo veo un infierno de colores en el que se mezclan C#, markup de .Net, html, javascript, y cuanta cosa se nos ocurra meter en una página web. Por cierto, Guido también dice:

• Disperso es mejor que denso.

Yo creo que sería mejor tener todos esos lenguajes separados que revueltos e interactuando juntos en el mismo lugar.

Mi punto de vista 2: los “malos” programadores.

Steven Smith le teme a los inexpertos, a los viejos y a los malos programadores (todos les tenemos miedo). Respecto de los primeros, siente que nunca abandonarán .Net “tradicional”, y que si abre esa puerta van a implementar toda la funcionalidad en la vista, dejando los controladores vacíos. A los últimos quiere obligarlos a hacer las cosas bien.

Eso es imposible. Un mal programador hará las cosas mal (no “más fácil” o “más difícil”, sino simplemente mal) independientemente de dónde esté picando código. Y eso es inevitable. Si hubiese una forma de forzar a un programador a hacer bien las cosas, entonces su trabajo sería reemplazable por una herramienta automática, y por lo tanto inútil… en general no es ése el caso.

El “malo”, ya lo dije, es incorregible y sólo podemos alejarnos de él o a él de nosotros. Al resto, a los inexpertos o a los “viejos” que vienen de otras tecnologías basta con mostrarles que es mejor separar la lógica entre vista y controlador, seguirlos, corregirlos, darles las herramientas y los criterios para elegirlas.

No creo que el objetivo un framework sea el control o la restricción. Su objetivo es estructurar, proponer un orden, facilitar el desarrollo, no impedirlo. Un buen framework no es aquél en el que no se puede programar mal, sino aquel en el que que programar bien es más fácil.

Mi personalísima conclusión

Volviendo a MVC: yo voy a cambiar los <%=Html.Input(…)%> por controles, y a agregar el codebehind para establecer sus valores e implementar la lógica de presentación en forma separada del html. Porque es más prolijo, más lindo, tal vez disperso pero mejor que denso, tal vez más complejo, pero mejor que complicado.

¿Y a uds. qué les parece?

Microsoft .Net MVC Framework 1.0 … en serio.

Silencio de radio estos días, ¿lo notaron? Tal vez sí –eso espero-, ya que corté un período de extrema verborragia que abarcó las últimas semanas, aunque –reconozco- con más relleno que ideas.

El relativo silencio tiene su origen en una sucesión de días –y noches-febriles en los que se juntaron el inicio de las clases -con su carga de revisiones, correcciones e improvisado planeamiento (tal cosa existe)- y el inicio de un nuevo proyecto en el trabajo, que es lo que quería comentar en este post, y –por fin- voy al grano.

Este proyecto es mi primera aplicación desarrollada con el ASP.Net MVC de Microsoft y es también el primero que se desarrolla con esta tecnología en la empresa para la que trabajo.

Creo que puede ser interesante ir comentando a medida que avanzo. Muchos de ustedes son programadores y seguramente han trabajado, jugado o leído algo sobre el MVC de Microsoft, y saben muy bien que el partido se juega muy diferente al entrenamiento con ejemplos y tutoriales: la funcionalidad requerida no es negociable (salvo en pequeños detalles), hay que terminar en tiempo y forma, y la presión de no saber (no saber estimar, no saber cómo se hacen tareas comunes, no saber si el framework cubre o no determinada necesidad, no saber si algo es fácil o difícil…) y tener que cumplir, pesa.

El Proyecto.

El proyecto es pequeño, dos programadores con una agenda de aproximadamente cuatro semanas de trabajo. Es una típica aplicación de gestión del estilo pantalla-contra-base-de-datos, con dos o tres complicadas y el resto ABM’s. Pero cargamos también con cierta obligación de entregar como subproducto la experiencia plasmada en herramientas puedan reutilizarse y métodos y prácticas estándar que puedan transmitirse… y errores que no vuelvan a repetirse.

Experiencia.

Somos dos programadores senior, y me toca aportar la experiencia previa de haber trabajado con el patrón MVC los últimos 3 años, si bien implementado sobre un framework desarrollado ad-hoc y mantenido, corregido y mejorado constantemente por el mismo equipo durante ese largo período de tiempo.

Herramientas: primeras decisiones.

Ya dije que trabajamos sobre C#, sobre el .Net 3.5 con el MVC 1.0, resta aclarar que la aplicación trabaja sobre Oracle. Demasiadas innovaciones para un sólo proyecto (en mi caso), así que decidí implementar entidades y acceso a datos con plantillas de CodeSmith, una herramienta de la cual no estoy enamorado pero manejo, y que para mí representa un problema menos.

De lado del cliente utilizamos el framework de javascript jQuery (algo sin lo cual ya no vale la pena vivir), con jQuery UI y el plugin jqGrid (una súper grilla que hace de todo).

Para ser sincero tengo que aclarar que robé la estética (hojas de estilo y demás) de otra aplicación ya desarrollada para el mismo cliente, así que no puedo opinar demasiado en cuanto a las facilidades para el diseño de estas herramientas, salvo que son muy fáciles de reproducir copiando y pegando archivos.

Curva de aprendizaje de MVC.

Estoy comentando aquí la curva de aprendizaje del patrón MVC en sí mismo: cuánto se tarda en aprender los conceptos, los términos, la nomenclatura y darse un par de palos contra la pared hasta llegar a ese punto en el que “vemos en MVC”, es decir cuando logramos encajar intuitivamente las funcionalidades requeridas dentro del patrón.

Así que no vale mi experiencia, sino la de mi compañero de proyecto –programador senior con buena predisposición y mucha experiencia con .Net-, que creo que luego de tres días completos de idas y vueltas (más o menos) ya le está tomando la mano (¡que comente!).

Para recomendar: comenzamos con estos videos cortos de Microsoft, un muy buen punto de partida.

Impresiones del .Net MVC 1.0.

Mi primera impresión fue “esto es buenísimo, es más o menos la misma arquitectura que venía implementando a mano, con los detalles escabrosos ya resueltos y muy bien integrada con el Visual Studio”.

Pero apenas completados los primeros tutoriales (de esos en los que armamos una aplicación -tan funcional como inútil- de punta a punta en 5 minutos) y comenzado el trabajo “en serio”, aparecieron las falencias. Lo que está está razonablemente bien implementado pero hay algunas cositas bastante desagradables, y mi impresión actualizada es que “le faltan cosas”, y que probablemente la próxima versión (2.0) represente una mejora muy significativa.

Puntos fuertes: la sobria estructura de la plantilla inicial nos ayuda a mantenernos organizados, una muy bien implementada relación entre vista y controlador, sencilla y flexible a la vez, la extensibilidad del framework en general (siempre hay dónde meter los dedos para adaptarlo a nuestra forma de trabajo). Por otro lado hay una comunidad grande y muy activa, con muchos y muy buenos recursos.

Por lo menos tengo que reconocer que el resultado final, el html, es mucho… muchísimo más razonable y manejable que el que produce como salida el .Net “sin MVC”: no más viewstate, no más update panel, no más ver una cosa del lado del servidor y otra (compleja, pesada y que encima no funciona) del lado del cliente.

Puntos débiles: el lado javascript, concretamente en lo más fundamental: carece de un método de conexión sencillo que soporte AJAX entre el cliente y el servidor. Las librerías de Microsoft… miré un poco la documentación y bien gracias, el código ni lo abrí. Como siempre, una copia berreta y muy complicada de algo que es muy fácil de implementar con herramientas ya existentes (en breve la adaptación de la serie al MVC). jQuery está ahí, viene con el paquete casi como una sugerencia, pero no vi ningún tipo de integración real (si alguien puede desasnarme éste es el momento).

Otra que no me gustó es cómo quedan –por defecto- las vistas cuando hacemos pantallas “reales” (y no formularios tontos de ejemplo)… esos “helpers” me recuerdan mucho a ASP 3.0 y la verdad que la legibilidad final, si implementamos las cosas tal como dicen los tutoriales… y… es una mezcla horrorosa de javascript, html y tags del lado del servidor. Pero, veremos en breve, eso es salvable.

La curva de aprendizaje del .Net MVC.

Así que, en resumen: si ya conocemos el patrón MVC y también el framework .Net, veremos que ésta implementación es un grandioso punto de partida que nos resuelve lo básico, un poco más, y nos da la base para armar un esquema de desarrollo realmente ágil.

Pero no está regalado, hay que hacerlo. Los detalles tras bambalinas (vistas tipadas, implementación de validaciones del lado javascript, helpers, bindeo) se vuelven un tanto complejos cuando se los quiere forzar por fuera del muy limitado uso estándar para el que están pensados pero, como dije antes, todavía no tuve un problema al que no le haya encontrado solución con un poco de ayuda de google.

Yo voy… pongámosle una semana a tiempo completo, y me considero en forma para esta pequeña primera aplicación con intenciones de sentar una base para algo mejor.

Promesas.

Mucha teoría, mucho discursito en el aire, ya lo sé. Voy a ir armando algunos posts más complejos con ejemplos y algunas soluciones implementadas. No hay mejor manera de validar la razonabilidad de un esquema que mostrarlo y prestar oído a los comentarios.

Cuando los resultados no reflejan la experiencia o el aprendizaje.

Hay veces que llama poderosamente la atención la brecha (otras veces el abismo) entre la calidad de un equipo y la del proyecto sobre el que trabaja. A veces para bien, a veces para mal.

En algunos se percibe una capacidad para la mejora que excede en mucho la capacidad técnica (inicial) de sus integrantes. La falta de experiencia hace que se reinventen muchas ruedas y se cometan muchos errores de esos que (tal vez pecando de un poco de soberbia) los desarrolladores de más experiencia catalogan de “típicos”, pero que son ampliamente compensados por la motivación a corregirlos, incluso en varias aproximaciones, intentando una y otra vez. Éste es el caso ideal en el que, en todo momento, la calidad del proyecto refleja todo el aprendizaje y la experticia del equipo.

Pero en otros se ve que el resultado, si bien funcional, no tiene la calidad que podría esperarse de acuerdo la experiencia de los participantes, o que surgen (en el peor de los momentos) problemas que derivan de errores que podrían haber sido detectados (e incluso corregidos) con relativa facilidad por los miembros de más experiencia, problemas que luego de un tiempo de incubación terminan impactando transversalmente en todo el proyecto volviéndose de difícil o imposible solución.

Mucho tiene que ver en la calidad de un proyecto la habilidad para resolver problemas de sus integrantes. Mucho más tendrá que ver la experiencia y muchísimo más la motivación.

Es la experiencia la que permite ganar tiempo aplicando soluciones ya probadas y enfocarse en aplicar la habilidad en resolver aquellos problemas que hacen único a cada producto de software. Pero es la motivación lo que lleva a utilizar la (mucha o poca) habilidad disponible y aprender (con mayor o menor velocidad) de los errores y aciertos (propios y ajenos), que es lo mismo que decir “adquirir experiencia”.

Pero una cosa es la motivación a aprender y otra la de aplicar el resultado de ese aprendizaje al proyecto en particular sobre el que se está trabajando y aprendiendo, y de ahí la brecha entre capacidades y realidades que mencionaba al principio. La mayoría aprende de los errores y ve posibilidades de mejora, pero son menos (muchos menos) los que desandan el camino para corregirlos o implementar esas mejoras en el código ya escrito. ¿Por qué?

Se me ocurren un par de factores que hacen de esa decisión (la de seguir sin mirar atrás) la más razonable:

• Si el alcance del proyecto es acotado y está próximo a entrar en una etapa de mantenimiento (¡exclusivamente!) correctivo, de poco o nada servirá mejorar lo que de todas maneras funciona (suponiendo que funciona razonablemente, ya que de no ser así no hay alternativa posible).

• Si el problema es transversal y está demasiado extendido, puede ser mejor será tratar de no cometerlo de aquí en más y corregirlo sólo en donde las modificaciones sean imprescindibles.

• En cualquier caso en el que el impacto sea menor que el esfuerzo que requiera la corrección. El problema aquí es la medición de ese impacto, para la que deberíamos considerar no sólo la situación actual sino también a futuro. Si estamos desarrollando un producto que se pretende mejorar y ampliar indefinidamente (en vez de “cerrar y entregar”) la acumulación de pequeños problemas terminarán afectando la calidad haciendo cada vez más difícil implementar nuevas funcionalidades y forzando una (mucho más riesgosa y costosa) reingeniería.

En definitiva, es cuestión de decidir en forma consciente y explícita si vale la pena el esfuerzo dada cada situación en particular. Pero hay otros factores, menos técnicos y más humanos o de organización, que bloquean las alternativas:

• Simple resistencia al cambio, el aferrarse a un estado en el que los problemas (graves o no) son conocidos.

• Una patológica actitud defensiva puede hacer que cualquier sugerencia se vea como una crítica.

• Soberbia, que impide ver los problemas y desventajas que inevitablemente están presentes en cualquier solución.

• Desinterés o el clásico “sólo hago lo que me ordenan”.

• Escaso trabajo en equipo o excesivamente compartimentado, que hace que se pasen por alto los problemas y posibles mejoras transversales.

Son estos factores son los que hay que detectar y combatir porque son los que llevan a decisiones irracionales o por defecto (aquellas que surgen de la no-decisión). El ideal es que el equipo tenga el control del proyecto, lo que implica ser consciente de los aciertos, de las cuestiones “mejorables”, de los errores que hay que corregir y de los que hay que soportar.

Curados de espanto.

No son todos malos hábitos los que adquirimos los programadores en el transcurso de nuestra vida profesional. Para nivelar un poco quiero traer a cuento varias características que casi todos compartimos, y que de seguro estarán presentes en un buen programador… tienen que estar presentes en un buen programador, ya que todas giran alrededor de un tema que es central en el desarrollo de software: los errores.

Todo software no trivial tiene errores (y como siempre digo, la mayoría de los triviales también). Y si por buena ventura un software en particular no los tiene seguro que los requerimientos que le dieron origen sí. Y si por alguna de esas casualidades cósmicas los requerimientos (y por tanto el software) son consistentes en los papeles, seguro que el usuario o el analista o el redactor o el programador se ha equivocado en su interpretación u omitido alguno de ellos con tal mala suerte que el resultado es consistente aunque, por supuesto, erróneo… y en el imposible caso de que todo esté bien… serán las necesidades del cliente las que cambien o las que cambiarán en breve.

Y hay que tener en cuenta que los innumerables errores detectados (ya sea durante el desarrollo o como defectos en el producto) son apenas una pequeña fracción de los que cometemos todos los días… y sin embargo aquí estamos.

Aunque a veces sucede, no es usual que ante un problema un programador se rasgue las vestiduras, se deprima, paralice o caiga presa de delirios apocalípticos. Esto es, básicamente, porque nuestra vida laboral es una eterna sucesión de problemas y soluciones… que generan más problemas.

¿Qué es lo que –al menos creo yo que- he aprendido?

El camino para estar a salvo de los problemas no es evitar que se produzcan (son inevitables) sino tener alternativas.  Para eso existen los resguardos, los procedimientos alternativos, las salidas de emergencia. Prevenir no es sólo prevenir el problema, sino también sus consecuencias.

Los manotazos de ahogado no sirven. La suerte existe, pero es escasa y no se puede confiar en ella. Hay que medir el costo de un intento a ciegas. ¿Podemos hacer una prueba rápida, a ver si funciona? ¿No romperemos algo más en el intento? Bueno, hagámosla. Pero no podemos perder tiempo tirando tiros al aire, la magia no existe y hay que pensar, buscar, investigar, rastrear, no queda otra.

Identificar precisamente el problema es siempre el primer esfuerzo. Tratar de arreglar “algo” que no se sabe qué es es sencillamente imposible. Trabajar sobre las consecuencias es una opción para ganar tiempo, pero nunca una solución a mediano o largo plazo.

No se puede resolver un problema de fondo sobre la emergencia. Cuando se presenta una emergencia hay que resolverla (en lo posible rápidamente) para aliviar la presión y poder pensar y resolver el problema de fondo con tranquilidad… Creo que en esto todos fallamos más de una vez, tal vez no tanto en la resolución rápida, sino en la disolución de la causa subyacente. ¿Cuántas veces dejamos parches provisorios como soluciones “definitivas” que no tardan en crear más y más graves apuros?

Presionando no se resuelve nada, por lo menos en sistemas. No es de mucha ayuda gritarle lo obvio al administrador de la red –que todas las terminales están fuera de servicio o que el mundo va a explotar-. Si encuentra la solución en un tiempo razonable será a pesar de ello y no gracias a ello. Ya habrá tiempo de repartir responsabilidades y amenazas luego, hay que concentrarse en buscar una solución.

Hay que dejar trabajar. Si nos es posible paliar las consecuencias o aliviar la presión, ésa es la forma de ayudar. Y si no está entre nuestras posibilidades hacerlo… mucho ayuda el que no estorba, dice el refrán.

Aprender por prueba y error implica resolver, aunque sea parcialmente, problemas de fondo. De cada problema, de cada situación, tenemos que quedarnos con alguna mejora. Puede ser pequeña, tal vez no una solución completa, tal vez apenas una alerta temprana para la próxima vez, algo, lo que sea. Si vivimos en un interminable devenir de emergencias, la única forma de salir de ello es de a poco, aprovechando el poco tiempo que nos queda para ganar más tiempo.

Señales de que eres un mal programador.

Más allá de los muy buenos chistes que contiene y del tono jocoso en general, Signs that you're a bad programmer es un artículo imperdible que debe tomarse en serio.

Está dividido en tres partes: “Señales de que eres un mal programador”, “Señales de que eres un programador mediocre” y “Señales de que no deberías ser un programador”. En cada una de ellas se presentan estas “señales” con sus respectivos síntomas y consejos para superarlas (carreras alternativas, para el último caso).

Aunque la gravedad de cada una en particular es discutible (yo no calificaría de “malo” a un programador con dificultades para seguir la recursión, me parece lo suficientemente complicado como para marearse sin merecer un calificativo tan extremo) es innegable su utilidad para identificar problemas y puntos débiles en uno mismo y los demás (o para decidirse a cambiar de carrera).

Más que puntear las que me parecen más importantes, voy a mencionar los síntomas que me resultan más molestos:

"voodoo (o zombie) code"

Mantener código que no hace al objetivo del programa: inicializar variables que luego no se utilizan, llamar a funciones que no hacen nada o cuyo resultado es descartado, producir información que finalmente no se muestra.

Esto hace que seguir el código sea exasperante y su corrección peligrosa, ya que uno tiene que ir separando la paja del trigo para entenderlo, corriendo el riesgo de sacar algo que sí servía. Una solución posible es no limpiar nada, lo que nos lleva a…

“no lo borres”

Con lo que me gusta borrar código… Esto me molesta sobre todo cuando aparece en la forma de cierta tendencia -que veo incluso en programadores experimentados- a llevar el control de cambios en medio del código mismo (¿costumbres de una época en la que el uso de sistemas de control de código fuente no era tan común?). Me refiero a éste tipo de comentarios:

“J.P. 25/7/2006: arreglo del incidente nro. XXX. El cálculo del total de…”

Estoy tratando de entender que hace el código ahora, y no me interesa saber qué hacía hace tres años. Para hacer investigación histórica está el historial de cambios. A la basura.

Pero… por algo debe estar ahí, ¿por qué mejor no lo dejamos?…

“por las dudas”

Código que se ejecuta “para estar seguro de…” O estamos seguros y no hay que asegurarse o no estamos seguros y hay que molestarse en entender hasta estarlo, ¿no? ¿Seguro que Trim borra los espacios a los dos lados de la cadena? Mmmm… mejor hagamos miCadena=miOtraCadena.LTrim().RTrim()… por si acaso. O escribamos (int)4, no sea cosa que… Para asegurarse está la ayuda, no el código.

Una variación sutil de lo anterior es arreglar un problema en la salida de una función manoseando el código que la consume, “por las dudas” de que “alguien más” la esté utilizando. ¿Alguien más la está utilizando? ¿Tan difícil es ir, fijarse en dónde y en todo caso corregir esos otros lugares? Esto me lleva a un punto que me parece que falta en el artículo referenciado:

“programar con ateojeras”

¿Vieron las anteojeras que se le ponen a los animales de tiro para que vayan siempre para adelante sin asustarse con lo que pasa a su alrededor? Hay gente que programa con eso puesto. Si tienen que corregir el incidente n que aparece en la pantalla x van a corregir eso y solamente eso, indiferentes a cualquier otro problema, por más grueso que sea.

Son como cirujanos que acceden al código y extirpan un tumor con precisión milimétrica… sin darse cuenta de que hace tiempo que el paciente está muerto. Finalmente el aporte de estas acciones al proyecto en general es tanto como su alcance… milimétrico.

Bueno, hay mucho más… mejor lean el artículo.

Depurar código es el mejor y más intensivo método de aprendizaje.

En esta última semana estuve librando mis primeras verdaderas batallas con jQuery, un framework de javascript que, al igual que mooTools, me parece sencillamente fabuloso.  La verdad es que me encantaría utilizar los dos al mismo tiempo, tan difícil resulta decidirme por uno u otro.

Me sorprendo ingenuamente de su efectividad porque vengo de la época en que javascript era apenas una herramienta para hacer validaciones del lado del cliente y ahorrarle un poco de tiempo y transiciones al usuario (con 56K apretar “submit” y esperar 20 segundos –con suerte- para recibir un par de mensajes de error era toda una frustración). Una época en la que cada uno armaba su propio “framework” y se conformaba con que fuera funcional para IE -y tal vez para Netscape-, le permitiera cargar dinámicamente una lista, armar una grilla básica y –para los más intrépidos- hacer unas ventanas de diálogo más elegantes que el básico alert() de javascript.

Con mucho sudor y lágrimas esos frameworks fueron creciendo y haciéndose más complejos… para luego descubrir (que frase tan típica de viejo la experiencia) que “estos mocosos de ahora la tienen regalada”, y que logran en 10 minutos lo que a uno le ha costado años.

En fin, todo eso fue ñañería y digresión. La cuestión es por primera vez en un largo rato estoy aplicando profesionalmente, a gran escala y en un sistema complejo, una tecnología totalmente nueva para mí.

¿Y cuál es la mejor manera de aprender? A esto iba: haciéndose desde abajo, revolviéndose en el fango, peleando entre la mugre… depurando código.

No me voy a hacer el humilde, lo hago porque no tengo alternativa, lo hago porque soy el nuevo y el más inútil de todos, porque me toca ocuparme de lo que me tiren y que, lógicamente, es aquello en lo que nadie quiere meterse. Porque no puedo esquivar el bulto, para resumir. Hay que pagar el derecho de piso, y el camino es resolver problemas. Simples, complejos, triviales… todos… y tratar de hacerlo bien (y ni hablar si se da el caso extremo que comentaba en Guía para perplejos: primera vista al código en un nuevo trabajo y... ¡ups!).

Sí, lo hago refunfuñando por lo bajo… hubo varias ocasiones en las que por suerte no tenía un objeto contundente cerca mío, pero tengo que reconocer que he aprendido más de jQuery en dos días que con todas las pruebas y pequeños proyectos inútiles que hice anteriormente.

Esto es porque lo que hay que hacer se aprende con los tutoriales, con los manuales, con los proyectos de prueba. Pero lo que no hay que hacer sólo se aprende corrigiendo errores o cometiéndolos.

¿Y para qué transitar el tortuoso camino de cometer todos los errores posibles para hacerlo un poco mejor la próxima vez? Es mucho mejor depurar, sacarle las pulgas a un sistema ya casi terminado y aprender no sólo de los errores que encontramos sino también de los muchos aciertos que los rodean. Es un curso intensivo, demanda el doble de paciencia y esfuerzo pero sólo una cuarta parte del tiempo que implicaría “aprender por la positiva”.

Dice el adagio que “el que se quema con leche ve una vaca y llora”. Pasarse un par de horas fracasando estrepitosamente en la búsqueda de algún lugar para validar si la sesión ha caducado para luego resignarse a implementar una solución particular en cada lugar donde se presente el problema (¡muchos lugares!) nos fijará en la memoria las bondades del encapsulamiento y la separación en capas a través de interfaces que podamos controlar (por cierto, esto último es lo que suele olvidarse).

Así que la próxima vez que se enfrenten a un mar de código al que –en principio- no le encuentren ningún sentido… no piensen que están depurando sino que están aprendiendo, aprendiendo tan rápido que en breve llegará ese “click” en donde nuestro cerebro, ya acostumbrado a la sintaxis propia del nuevo lenguaje o herramienta, deje de mirar y empiece a ver.

Ah, por cierto… todo muy lindo, he aprendido mucho en dos días y descubierto varios errores, pero todavía no he logrado corregir elegantemente ni uno de ellos. Ya lo dije, paciencia.

5 errores no técnicos que usualmente cometemos los programadores.

Un muy buen artículo de Making Good Software en el que se detallan y comentan 5 errores no técnicos que usualmente cometemos los programadores:

1. Falta de disciplina.
2. Orgullo (“big ego”).
3. Ser un mal comunicador.
4. Olvidarse del cliente.
5. No priorizar el trabajo apropiadamente.

¿Se sienten identificados con alguno? Me declaro culpable del 1 y del 5 (aunque espero que al ser consciente de ello esté logrando mitigarlo un poco)… A leer el artículo completo (en inglés). Me llegó twiteado por @programmingjoy.