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.

Plugimanía, plugiadicción, plugidependencia, pluginitis.

jQuery está buenísimo. Lo uso todos los días, lo dije una y otra vez, y no me cansaré de repetirlo.

Su mayor fortaleza, opino, no radica en su reducidísimo (como corresponde) core sino en la amplísima comunidad de desarrolladores que aportan, oficial o extraoficialmente, nuevas funcionalidades encapsuladas en forma plugins.

Yo imagino que, como en toda comunidad, se sigue la regla del 90-10: 10% aporta activamente y 90% utiliza las funcionalidades provistas “as is” o a lo sumo con un poco de manoseo. Entonces, si derivamos la cantidad de desarrolladores-usuarios a partir de la cantidad de desarrolladores-aportadores obtendremos… no sé, un montón de gente.

Los usuarios-desarrolladores son aquellos que encuentran en jQuery la forma de implementar en cinco minutos aquella funcionalidad que estaban buscando. Es decir que llegan a jQuery a partir de una necesidad concreta que usualmente satisfacen rápidamente para proseguir con su camino, habiendo sumado una herramienta más a su caja de experiencias y dispuestos a volver a utilizarla allí donde consideren que sea más apropiada que otras.

Luego tenemos a los plugimaníacos, aquellos quienes ya han utilizado intensivamente la herramienta y por ello buscan en jQuery el plugin mágico que resuelva algún nuevo problema. Son los que lo crean si es que no lo encuentran o mejoran uno ya existente si es que no cubre totalmente sus necesidades… o por simple y sana diversión. Es aquel 10% del que hablábamos.

Una porción menor de desarrolladores siente que tiene que hacer eso tan difícil en jQuery, que necesita hacerlo en jQuery. Desarrolladores que prefieren implementar un nuevo plugin aún ante la existencia de herramientas o soluciones más apropiadas para el requerimiento concreto en el que están trabajando.

Ahí donde una pequeña animación en flash o un applet de java o silverlight parezcan soluciones más razonables o naturales veremos a los adictos decir “eso puede hacerse con jQuery” y poner manos a la obra, prestos a demostrar sus (en general extraordinarias) habilidades y a defender el orgullo de su herramienta (¡hablamos de jQuery, malpensados!) ante las demás. Son, del 10% de aportantes activos, el 1% que lleva jQuery al límite y hacia nuevos horizontes.

Pero, dentro de estos últimos, otra minoría, los plugiadictos, no sólo se bandean para el lado de lo extremadamente complejo, sino que también lo hacen hacia lo extremadamente simple. Si son de buscar en el mundo jQuery se habrán encontrado con más de uno que ha creado algún plugin que encapsula la más trivial y estándar de las tareas o que ha utilizado una ferrari (del tipo jqGrid) para la más aburrida de las tablitas no paginadas.

Hasta aquí toda gente normal, simpática, o a lo sumo un tanto extravagante. Pero cuando avanzamos en la progresión exacerbando un tanto más estas conductas pasamos de castaño a oscuro y entramos en el terreno de las patologías. Citaré dos de ellas: la plugidependencia y la pluginitis. Es posible, como se verá, que un caso extremo de la primera desemboque en la segunda.

El plugidependiente no es (ni puede ser, se verá) un aportador al repositorio de jQuery. El plugidependiente, debido al uso y abuso de la herramienta (ya sea motivado por él mismo o por su entorno) ha olvidado (o nunca aprendido) que existen cosas llamadas HTML, Javascript o DOM.

Lo reconocemos por un clásico afán de probar que “eso no puede hacerse” mediante la búsqueda infructuosa de un plugin de jQuery que lo haga. En su mundo aquello que jQuery no pueda hacer no puede hacerse, y punto.

Otras características remarcables, en casos extremos, son el desconocimiento de HTML más allá de los tags más básicos (aquellos que sirven de soporte a plugins de jQuery, como DIV y TABLE) y recurrentes intentos de utilizar sintaxis de jQuery en otros contextos (Javascript, o más extremo aún: C#, Visual Basic o cualquier otro lenguaje). Intentos que suelen culminar con un asombrado “¿ah, eso es de jQuery?”.

En el extremo absoluto de esta patología el desarrollador desconoce jQuery como extensión y cree que $(“DIV”).each( function(){…} ) es la sintaxis propia de Javascript o parte de HTML.

Como sucede con todas las herramientas y cosas en general, el abuso vuelve nocivo aquello que en el uso es beneficioso. Llegamos a la pluginitis.

El primer síntoma es una página web que tiene un título y una tablita y tarda unos 5-10 segundos en descargar. ¿Qué sucede? Pues nada, que tiene referencias a jQuery, jQuery UI, jqModal (pero… ¿no hay algo parecido en jQuery UI?) y unas 10 o 20 referencias más a archivos .js externos sin minimizar que no se utilizan absolutamente para nada… tal vez la página ni siquiera tenga un script, sino que simplemente… bueno, pluginitis.

Otros síntomas son: un browser (que no es el IE) que se arrastra, puro contenido generado dinámicamente del lado del cliente, imposibilidad de seguir la generación de ese código o de averiguar siquiera cual de las 3 o 4 extensiones parecidas de las incluidas en la página es la que está dibujando ese contenido.

¿Cómo salir? El primer paso es reconocer el problema. El segundo buscar ayuda y el tercero es una dura combinación de sacrificio, paciencia y constancia.

De mi parte, espero que el pequeño esfuerzo de escribir este post se justifique por haber ayudado, aunque sea a un sólo plugidependiente o pluginoso, a abrirse a una nueva vida. Si ése es tu caso, agradeceré tu comentario.

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.

Huerfanitos.

Permítaseme un poco de humor gris tirando a negro.

En todo emprendimiento que venga pariendo software desde algún tiempo podremos encontrar desarrollos en diferentes estadíos de su camino hacia la obsolesencia: los hay desde embrionarios hasta mantenidos con vida artificialmente, pasando por recién nacidos encantadores que prácticamente no hacen nada por sí mismos, infantes con terribles rabietas que reclaman noches en vela, adolescentes indomables pero llenos de energía y posibilidades, adultos productivos e independientes y ancianos, venerables fuentes de sabiduría o mañosos insoportables cuyos achaques reclaman constante atención.

Y los hay huerfanitos, de todas las edades. Ya sea debido a que sus progrenitores hayan pasado a mejor vida o huido en estampida cual vil Frankenstein o desentendido de su cuidado o sido asesinados (o ajusticiados merecidamente), son usualmente víctimas de la indiferencia de los miembros del equipo de desarrollo.

Proliferan –me imagino, no me van a pedir rigor científico justo ahora-, más en consultoras que en empresas dedicadas a un producto o que en software factories. Supongo que porque las segundas cuidan mucho a su único hijo (o a lo sumo a sus pocos hijos) y las últimas son padres espartanos e inmisericordes que no tienen reparos en arrojar al abismo a sus vástagos más débiles, en el mejor de los casos, o madres de alquiler que paren a pedido y si te he visto no me acuerdo.

Pero si definimos como consultora a un emprendimiento que no sólo desarrolla un producto sino que también se hace cargo de su mantenimiento correctivo y mejoras funcionales (que cobra religiosamente), nos encontramos con que en este tipo de organizaciones no es tan sencillo dejar atrás las consecuencias de viejos errores… institucionalmente hablando, claro, porque sus integrantes intentarán hacerlo a toda costa (o serán eventualmente obligados a ello), y de ahí la proliferación de estos huerfanitos.

No es mi intención ser cruel inútilmente, hablo desde la experiencia: son peligrosos, créanme. Carentes y muchas veces necesitados de atención, se nos pueden pegar como garrapatas. Es así como, a través de una inocente tarea de instalación, un pequeño fix o una mejora estética nos encontramos siendo referentes, tutores, encargados, o directamente padres sustitutos de alguna de estas criaturitas de las que conocemos poco y nada.

El entorno no propicia el despegue. Si les toca transitar esta situación verán con horror como, aliviados al ver que a otro se le ha adjudicado el trasto, sus otrora solidarios compañeros de equipos evitan el tema (“y sí, alguien tenía que hacerse cargo”) o intentan naturalizarlo (“che, vos estabas con aquello de… ¿no?”), si no es que literalmente huyen despavoridos. Y no tardarán en aparecer problemas de los cuales, obviamente, nadie sabe nada y nadie nada quiere saber, salvo que tenemos que hacernos cargo.

¿Solución? Es aquí donde con un poco de demagogia podría decir que la única definitiva es adoptarlo, encauzarlo, educarlo, corregirlo, domarlo si es necesario para resolver el problema de una buena vez por todas… pero también es una posibilidad buscar a algún desprevenido, dejarle la canastita cerca, tocarle el hombro, voltear y caminar rápidamente sin mirar atrás, silbando bajito con aires distraídos.