Complejidad Innecesaria? El Infierno de Dante?

Introduccion

A ver, para que se comprenda el siguiente articulo, los que escribimos este blog, fuimos en su tiempo adherentes de correr detrás de la ultima tecnología y que a mayor complejidad, mayor placer por dominar temas complicados, por aplicar conocimientos teóricos, etc. Era además mucho más interesante plantear un sistemas de colas concurrentes usandos colas en memoria con PVM (una máquina virtual paralela que permita ejecución paralela en servidores) que resolverlo con una simple tabla en base de datos. Lo cierto es que estabamos equivocados, y nos fuimos dando cuenta a lo largo de todas las veces que complicamos soluciones de manera totalmente innecesaria y luego se nos volvió contra nosotros mismos.

Indice de Complejidad de Arquitectura

Cada tanto me gusta inventar "números Kafkianos", esto es inventar medidas de algo que no estén basados en la teoria de los grandes números, en álgebra ni en nada muy "serio" pero que provengan del sentido común y/o cierto conocimiento y que sean aplicables a temas de la vida diaria. El porque le achaco al pobre Kafka la paternidad de este tipo de números sin el menor fundamento es materia de opinión psicológica, en la que no vamos a entrar.

 Vamos a definir entonces el índice de Complejidad de la Arquitectura de una aplicación, ICA (app) como el número de componentes lógicos o de provisión de datos que necesita la aplicación para funcionar. Esto es sin contarse a ella misma, es decir al código de la aplicacion que provee la lógica princpial en si, ya que es obvio que se necesita. Asi, tenemos que una vieja aplicación Desktop (las que corrían o corren en los clientes mismos, las de antes), como, para citar un ejemplo que todavia sobrevive, una planillita excel(que no acceda a base de datos), un Paint, un Visio (versión desktop), Autocad, etc., tienen :

ICA( app desktop) = 0 (en general).

Okey, Si, es verdad que no estamos teniendo en cuenta componentes de la infraestructura de red, routers, proxys, firewalls, ni virtualización de servidores, ni siquiera componentes de los sistemas operativos. Tampoco tomamos en cuenta librerias de subcomponentes de una aplicación web como por ejemplo log4j (si tenemos log4j dependemos en cierto sentido de como este configurado, en su impacto sobre la aplicación, etc.). Pero permitanme dejarlos de lado, vamos a algo mucho más simple. Una aplicacion Cliente-servidor, que accede a una base de datos (estilo las apps basadas en Oracle forms, Java Desktop aplication, app tipicas Visual Basic version x , etc) tiene :

ICA (app client-server) ) = 1 (en general)

Además de si misma necesita una base de datos configurada "up and running", y depende de ella para proveer servicios al usuario.

Un simple y querida aplicacion web, sea en Java, .NET, PHP o Ruby on Rails, tiene:

ICA (app web) = 3 (en general)

Es decir, debe funcionar un browser o navegador en el cliente (con su correspondiente configuracion, nada trivial, de cookies, activex, etc.), una base de datos (un servidor de base de datos, más el espacio de tablas o esquemas necesarios, seguridad, etc.) y un servidor de aplicacion, de nuevo, que este funcionando y correctamente configurado. Y si, ya se que la complejidad de hacer aplicaciones varía si el lenguaje es Java, .NET o Rails.Y ni siquieta estamos considerando que la aplicacion use ajax o no. Lo se. Continuen conmigo un poco más.

Mundo HTML5 ( Appweb con Javascript en el navegador, ajax, JQuery (que simplifica enormemente el desarrollo Javascript!)), todo esto da :

ICA (app web) = 4 (IC(app) web + 1 de funcionamiento de la lógica JS en el cliente)

Llegando al mundo SOAP, la cosa se pone interesante, a ver, cuenten conmigo, para que una applicacion que accede a servicios a través de SOAP funcione tienen que funcionar a la vez y estar correctamente configurados: 1 browser (repito, la configuracion no es trivial) 1 Aplication Server ( de la app. en si) 1 Base de datos (por lo menos) 1 Enterprise Service BUS 1 Aplication Server (adonde reside el servicio) 1 registro de servicios (Service Registry)

ICA(app SOAP) = 6 !!!

y eso que estamos contando que accede a servicios residentes en un mismo aplication server, si accediera a n servicios en distintos servidores, la formula deberia ser algo asi como:

ICA(app SOAP) = 5 + n * 1, con n>=1.

Estoy viendo que bien podriamos llamarlo Indice de acoplamiento de la infraestructura de un sistema.

Al Mundo SOAP le sumo (+) BPM :

ICA (app SOAP + BPM) = 7 + n * 1 ( al ICA(SOAP) le sumamos el BPM y su base de datos)

A ver, es claro que cada aumento en la complejidad que hemos dado hasta aqui está de alguna manera justificado porque se supone que provee un beneficio, a veces más o menos tangible, para el usuario final. Una primera pregunta es: Esto, se percibe realmente así? Esto, Es realmente así? A ver, es claro que hay algunas situaciones adonde amerita aumentar la complejidad, depende siempre del contexto. No estamos diciendo que nuuunca se deban utilizar una cache distribuida, por ejemplo.

Lo que es seguro es que ese supuesto beneficio no viene sin un costo. Para que funcione una de estas aplicaciones, más alla de la complejidad inherente de su propia lógica deben funcionar correctamente TODOS y cada uno de los otros elementos a los que está acoplada, y no solo deben estar levantados y corriendo. Deben hacerlo sin errores, con buen rendimiento, deben estar correctamente configurados y sincronizados , muchas veces referenciándose entre sí de manera exacta, en un millar de archivos xml distintos, todo esto, para que el conjunto funcione.

A la vez, un error, en configuración o lógica, o un problema de escalabilidad por pequeño que sea, en cualquier eslabón de esta larga cadena hace que el todo no pueda funcionar. Se producen errores , o problemas de performance , a menudo de maneras impredecibles e indeterminadas. Esto ES asi porque la combinatoria de posibles problemas explota de manera exponencial. Y ni que hablar de tratar de encontrar problemas de concurrencia o simplemente debuggear errores.  No es de extrañar que las aplicaciones sean cada vez menos confiables.

Las aplicaciones actuales que vemos, corrijanme si me equivoco, no es raro que posean 2 o 3 datasources que acceden a diferentes fuentes de datos, servicios varios de diferentes aplicaciones, conectores con algun ERP o sistemas externos, interfaces con algún Mainframe, Caches distribuidos, y etc y etc. Traducido a dos palabras: Una Pesadilla. y no solo para la pobre gente que debe administrarlo y mantenerlo, piensen tambien en el costo extra ($$) que genera esa administración y mantenimiento.
Y no estamos hablando todavia (ahora si!) del costo y la dificultad que implica armar ambientes de tests y desarrollo que permitan soportar esta infraestructura para desarrollar nuevas aplicaciones (mocks, instancias de desarrollo, de testing, para cada uno de los componentes interdependientes, servicios, servidores varios, etc.). Todo lo cual dificulta aún más el testing de las aplicaciones, ya de por si una de las tareas más dificiles del desarrollo.

Dejamos para un siguiente articulo el siguiente "dilema", viene Cloud Computing (la computación en las Nubes) a incrementar o  disminuir la complejidad de la arquitectura de las aplicaciones? 

Ok, no soy naive y entiendo que los grandes Vendors tienen que inventar "modas" y seguir vendiendo "Enterprise Integration Aplication" servers, Parallel computing infrastructures, Aplication servers con servicios cada vez más complejos o la última moda en portales de agregacion de contenidos. También comprendo que en el afán por llegar al futuro, con ánimo de mejorar y brindar nuevos productos hay mucha gente honrada que plantea estas infraestructuras de buena fe, y con las mejores intenciones pero........

No nos estarán haciendo recorrer los 9 círculos del infierno?

Vuelta al Blog y algunos consejos para la carrera

Cambios de Empresa, Viajes a Shanghai, a Palo Alto, en el mismísimo Silicon Valley, construcción de plataformas para Cloud Computing, uso intensivo de Git, GitHub, continuous Integration (Integracion Contínua), implementacion de Continuous Deployment (Despliegue continuo), Culturas de Start Ups, etc., son algunas de las novedades de este año que ya se termina. Son demasiadas para un solo post. Vamos a ir retomando de a poco este espacio de reflexión sobre tecnología de la información, buenas practicas de Desarrollo y todo lo que hace a las metodologias ágiles y al desarrollo de software en general.

La verdad es que tuvimos un poco abandonado (tachen "un poco") a este blog gran parte del año. Hemos estado envueltos en un proyecto altamente demandante de tiempo en una empresa Start Up. Algún día con un poco mas de perspectiva escribiremos sobre esta experiencia que ha tenido de TODO menos aburrimiento. En parte es por eso que no hemos podido escribir en este blog. Estuvimos en unos de esos periodos de aprendizaje intensivo, mezclados con no-pocos-cambios y experiencias de toda índole. Y todo suceso de este estilo conllevan un ritmo que no dan mucho margen para pararse a pensar y reflexionar demasiado sobre lo que esta sucediendo.

Hoy quiero dejarles esta reflexión.

Cuando recién empezaba en esta profesión (hace poquísimos años....bueno tampoco tantos che! unos 16 añitos...) no había la diversidad de ofertas que hay en este momento. Uno elegía entre dos o tres opciones a lo sumo e iba pasando de proyecto en proyecto mas o menos como y cuando podía. Tampoco me importaba demasiado porque en ese momento pensaba (no lo pensaba, en verdad, lo "sentia" de alguna manera porque si me paraba a pensarlo es obvio que no es asi) que tenia infinitos proyectos por delante.

Habiendo ahora tantos proyectos, tantas empresas y ofertas dando vueltas por el mundo veo a un montón de gente que se conforma con lugares mediocres, con proyectos tan interesantes como palear las arenas del Sahara en verano y se aferran a trabajos malsanos o ambientes enfermos como si estuviéramos hace 30 años atrás donde un empleado entraba a una gran empresa y sabia que se iba a retirar en ella.

Por el otro lado veo tambien a chicos muy jóvenes, con mucho empuje y ganas pero que en lugar de elegir lugares adonde aprender, repito: adonde r-e-a-l-m-e-n-t-e aprender, van saltando de trabajo en trabajo como sapo perseguido porque un trabajo le ofrece 10 pesos mas que otro, sin planificar a mediano plazo. Sin planificar en que área, en que tipo de proyectos le gustaría trabajar. La gente que trabaja en IT en USA tienen muy claro esto de planificar sus carreras a mediano plazo digamos.

Muchas veces he tenido que elegir entre proyectos. A veces entre ganar mas plata y hacer algo que me interese. Elegir entre el bolsillo o el corazón. Y créanme lo que les digo, las veces que elegí con el bolsillo... nunca salieron como esperaba.

No estamos planteando acá una postura romántica o naif o a la San-Francisco-De-Asis, "Salven al mundo!! Sigan sus corazones", "Viva la pobreza", "Si a la Revolución Arabe", no (es decir, Si a la revolución Arabe pero no a Vivir en la pobreza ). Sabemos que uno trabaja principalmente por dinero y que lo que busca en general al cambiarse de trabajo es un crecimiento...en dinero.

Pero lo cierto es que si es "solo" el dinero, si el trabajo no te motiva, es aburrido o te desmotiva a cada paso, tarde o temprano terminarás odiando lo que haces, o a tus compañeros o jefes o a todos juntos... incluyendote. Y 40 horas semanales (o mas!) es demasiado tiempo para hacer algo que uno odia, verdad?.

Asi que les dejo la GRAN VERDAD NUMERO 1 de este fin de año, a modo de reflexión.

GRAN VERDAD NUMERO 1:

Hay un numero limitado de proyectos de desarrollo en los que participaremos en nuestras vidas. Elijamos aquellos que realmente nos apasionen. Somos de los poquitos profesionales en el mundo, los de IT, que podemos darnos este lujo.

Asi que, aún cuando esten recien comenzando la carrera, y sobre todo si estan en esta situacion, empiecen por pensar que quieren, que les gusta. Que les gustaria hacer los proximos años.

1. Si solo conocieron un lenguaje de programación, experimenten con otros.
2. Si solo estuvieron en consultoras de sistemas, traten de estar en el depto de sistemas de una gran empresa.
3. Si solo estuvieron en un determinado tipo de proyectos o metodología, experimenten con otros.
4. Traten de cambiar a proyectos que sean interesantes, por la tecnología o por el tema de negocio relacionado.
5. Traten de rodearse de personas que sepan mas que ustedes.
6. Empiecen un blog de sus temas favoritos, participen en foros,
7. Hagan de su CV un diamante en bruto, al cual agreguen items puliendolo asi dia a dia.

Y si hacen algún trabajo que realmente los apasiona, si son buenos y se esfuerzan cada dia por mejorar, por crecer profesionalmente, si se preocupan y toman cada nuevo comienzo como una gran oportunidad, y piden reconocimiento (noten que no dije "esperen reconocimiento"), créanme, va a suceder. Van a ganar dinero y hacer algo que les apasione.

Elijan siempre con el corazón.

El sindrome de Estocolmo II : Test para saber si te han Secuestrado

Hablabamos en el post anterior de que en la actualidad hay muchisimo trabajo y oportunidades laborales en el área de sistemas y sin embargo es frecuente encontrar a personas muy capaces e inteligentes sufrir por sus trabajos actuales, quejarse constantemente pero no encontrar una salida y quedarse en un circulo vicioso.

Las siguientes son las condiciones de contexto adonde es probable que se produzca un síndrome de Estocolmo. Agregamos algunas preguntas que tiene que ver específicamente con las situaciones que se producen al trabajar.

Si estas trabajando hace rato en un mismo trabajo, si te sentís desmotivado, aburrido, hastiado. Si te enfermas a menudo, si hay ciertas cosas que te rebelan. Si tenes miedo de expresar lo que sentis, lee las siguientes preguntas y contestalas por y para ti.

A - Debe existir la percepción de una amenaza cierta a la supervivencia o integridad física o mental del Rehén.

Los empleadores tienen el poder de decidir si lo despedirán a uno, si le darán una promoción a un cargo mayor o decidir si lo asignara a un proyecto importante o irrelevante.

La amenaza aquí, ciertamente no de vida (al menos en los casos que conozco) se produce porque el empleado ve amenazado sus ingresos, su carrera, su futuro en manos de la decisión de uno o mas de sus empleadores.

Se ha generalizado la sensación de que no se debe criticar ni se puede estar en disenso?. Hay rumores de que tal y tal personas fueron echadas por ese u otro comportamiento que la empresa desea desalentar?. Hay alguna que otra humillación privada o más o menos pública o falta de consideración total. Hay rumores de que solo acomodado o siendo amigo de alguien se consiguen ascensos? Todos tus compañeros trabajan horas y horas de más y te miran mal cuando trabajas solo 10 horas diarias?

Repetimos lo que dijimos en el post anterior: No en toda empresa simplemente por existir la posibilidad de un despido se esta en esta condición, porque entonces se cumpliría en todos lados. Estamos refiriéndonos a aquellas adonde la amenaza se cierne siempre, de manera constante, de una manera más o menos explicita o velada en conversaciones, rumores de pasillos y en la publicidad de las "ejecuciones" (cuando se despide a alguien).

B - Aislamiento del exterior y único contacto con opiniones y perspectivas de los captores.

Esta condición se cumple en general en grandes corporaciones o empresas con una cultura interna muy fuerte. Los empleados viven inmersos en ese "mundo", solo reciben la visión de sus empleadores, jefes y compañeros. Una de las características principales que se da es la creencia generalizada de que la situación en esa empresa es "especial", distinta al resto del mundo y que en ningún lugar se hacen las cosas mejor que allí. Las pequeñas bondades de la empresa se magnifican y personalizan.

La mejor y única tecnología es la que se usa en tu empresa y el resto son basuras? Casualmente los de adentro son las mejores personas y la empresa tiene los mejores resultados? No tenes idea de cuanto se paga en el mercado? Cuan buscado es tu perfil? Siquiera que tecnologías se usan en otras empresas? No te dejan ir a seminarios o cursos? Se desmerecen con comentarios despectivos reuniones de asociaciones o grupos independientes?

C - Pequeños actos de bondad y cuidado de los abusadores a las victimas.

La empresa instala Aro de Baskets y Play Station? Pone una maquina de Golosinas y gaseosas para todos? Te otorga un salario un poco por encima del promedio para el cargo? Súbitamente aparecen pequeños bonos o premios de distinta índole? Que tal ese beneficio adicional que estabas esperando? Uno siente que aun cuando el ambientes de trabajo es malo, desmotivamente, la empresa intenta ser buena con uno dándole algunas pequeñas ventajas materiales. La sensación general es "Es verdad que esto es un desastre pero...por lo menos me pagan bien".

D - La percepción de la imposibilidad de escapar del abuso.

Los empleados atrapados en estas empresas perciben "barreras de salida" alrededor de ellos que no los dejan "escaparse". En cierto sentido son excusas pero excusas bastante reales. Veamoslas.

Tu sueldo es bien alto y competitivo de manera que otras empresas en tu mismo cargo no pueden pagártelo? Los beneficios son tan intrincado de medir que no sabes realmente cuanto pedir para pasar a otra empresa? Estas desarrollando tareas no habituales para tu experiencia o encerrado en tecnologías muy puntuales que hacen que no puedas encuadrarte realmente en un perfil para salir a buscar trabajo? Vas a una y otra y otra entrevista pero siempre el aura de beneficios de tu empresa actual hacen que no termines aceptando nunca otra propuesta?

Como leer los resultados del tests?

Muy simple, si contestas que sí a algunas o varias de las preguntas en los apartados A, B, C y D podes estar viviendo un cuasi-Sindrome de Estocolmo.

Asi que ya saben, si sos programador y a pesar de ganar muy bien o tener ciertos beneficios, te sentis realmente mal en tu trabajo, si te estresas, te agarras pequeñas enfermedades frecuentemente y no te animas a buscar un nuevo trabajo (o ninguno te viene bien), recordá lo siguiente:

En el Yoga tradicional se sostiene que para que entre algo nuevo en tu vida tenes que vaciarte, tenes que eliminar todo lo viejo, sino, justamente ese aferrarse al pasado no permite que entre nada nuevo, no deja cambiar, no permite crecer.

No sera hora entonces de pulir ese CV en Linkedin ?

El sindrome de Estocolmo

En estos últimos años he estado en contacto con varios colegas de área de desarrollo de software que no están bien en sus respectivos empleos pero por algún extraño motivo se resisten a abandonarlo. Se quejan del ambiente, de algún jefe, de las herramientas que utilizan, de las horas que tienen que trabajar de más, caen enfermos con frecuencia, sufren muchas contracturas, engordan, en pocas palabras, sufren, pero aun asi no atinan a cambiar de trabajo.

No se si es algo aplicable a toda latinoamérica, pero aquí en Argentina, en estas épocas de bonanza, adonde la demanda de determinados perfiles supera amplia mente a la oferta eso es un poco... ilógico.

Aclaramos, no estamos diciendo que ante el primer pequeño problema o desmotivación hay que irse del trabajo. No, no es asi. Para ser claros, no estamos de acuerdo con el típico programador que salta de empresa en empresa, quedándose 3 A 5 meses antes de escapar a otra para evitar asumir cualquier responsabilidad o ganar dos centavos más.

Contexto laboral para el surgimiento del síndrome

Las situaciones a las que me refiero son bastante más enfermizas y de cierto maltrato. Esto no significa que los esclavicen con látigos o trabajando a destajo (eso se terminó hace algunos pocos años, jeje), no. Son maltratos mucho más sutiles.

En algunos casos se comienza por instalar una atmósfera rancia de presiones por alinearse con el proyecto en particular de una o varias personas. Surge luego un ambiente ligeramente amenazador adonde nadie se anima a decir en voz alta lo que piensa y termina con la instalación de amenazas veladas sobre que no estar de acuerdo implica despidos o degradaciones / humillaciones publicas o de cargos.

En otras empresas en cambio se da por una falta total de motivación causada por peleas políticas en las altas esferas que hace que cualquier proyecto se paralice y cambie de dirección mil veces antes de ser abandonado sin terminar, lo cual causa desmotivación, falta de interés seguido de aburrimiento y terminando en hastío.

A veces son simplemente ambientes estatales faltos totalmente de desafios e incentivos y en otras se generaliza la desmotivación cuando se premia cualquier cosa menos trabajar bien.

A quienes Afecta?

Son Programadores, Analistas, Arquitectos, personas capaces y responsables, viven quejándose, desmotivados, malhumorados, con cansancio crónico pero sin embargo no se dan cuenta que pueden irse de esas empresas. O cuando lo intenta, no alcanzan nunca a encontrar el trabajo ideal, ese que están esperando para irse.

Condiciones para la aparición del síndrome

Hace cierto tiempo había leído un articulo de Chad Fowler titulado : "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?", el cual me pareció ciertamente un tanto exagerado. No obstante, ahora releyéndolo encuentro algunas similitudes ciertamente inquietantes.

En psicología el termino "Síndrome de Estocolmo" es utilizado para describir un comportamiento psicológico paradójico adonde un rehén desarrolla empatía y sentimientos positivos hacia sus captores.

Pueden leer el post de Chad Fowler que describe, seguramente mejor de lo que yo lo haré, las condiciones que se cumplen para que esto suceda en "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?".

Fijense entonces las condiciones y después ustedes sacarán sus propias conclusiones.

A - Debe existir la percepción de una amenaza cierta a la supervivencia o integridad física o mental del Rehén.

B - Aislamiento del exterior y único contacto con opiniones y perspectivas de los captores.

C - Pequeños actos de bondad y cuidado de los abusadores a las victimas.

D - La percepción de la imposibilidad de escapar del abuso.

El punto 3 es esencial toda vez que si la conducta de un Captor hacia su victima es de violencia y agresión permanente el Rehén desarrollara odio o terror pero nunca se encariñará. Tiene que haber pequeños actos de bondad o que sean percibidos como tales para que la victima al tratar de evitar el miedo o el pánico se refugie en esos pequeños actos para protegerse mentalmente del miedo, de la perdida de control de su vida y del ataque a su autoestima.

Existen realmente los Trabajos-Captores?

Repito que a mucha gente, yo el primero, puede parecerle una exageración hasta aquí la relación entre sentirse atrapado por un trabajo y condiciones de secuestros reales adonde lo que esta en juego es la vida de la persona secuestrada. Pero si uno mira una a una las condiciones se pueden ver algunas similitudes.

Creo que es importante aclarar un poco mas sobre las condiciones que hacen que un empleo en particular tenga este efecto.

Como nos debemos a nuestra audiencia, para la proxima, prometemos desarrollar un mini-test de preguntas para ayudarnos a analizar si ese trabajo que te está haciendo pasarla mal te ha capturado, y lo peor es que no esta pidiendo mas rescate que tu salud.

Lecciones reaprendidas

Hoy tuve unas de esas peleas con el código que te hacen reconsiderar el pasarte a Management :). No fue muy sangrienta, sólo un bloqueo de media hora, pero cometí tantos errores repetidos que cuando finalmente logré hacer lo que quería no sentí satisfacción sino bronca.

Mi objetivo era hacer una subclase de una clase básica del entorno, para agregarle cierta funcionalidad. Estaba apurado porque tenía poco tiempo y quería terminar esta tarea hoy. Intenté el camino obvio: crear la subclase y utilizarla en lugar de la clase del sistema. Esto no me funcionó y como estoy en un entorno bastante nuevo (Objective-J/Cappuccino), decidí que la herencia no debía estar funcionando bien (??). Entonces me puse a buscar maneras de lograr mi objetivo de otra manera: intenté con un wrapper de la clase que quería modificar, con modificar el comportamiento de la clase que llamaba a la nueva clase y con unas cuantas maneras más, sin resultado. Busqué un rato en Google, pero no encontré ninguna referencia a mi problema. Estaba atascado. Ya perdido, volví a intentar el camino inicial, y funcionó!!. Revisé lo que había hecho en mi primer intento y por supuesto, encontré un problema en mi implementación inicial.

Los errores que cometí fueron los siguientes:

1. Asumir que la herencia no funcionaba. El compilador nunca está roto!!! Bueno, si, a veces está roto, pero en 20 años de programar sólo he descubierto 2 o 3 de esos errores y me he equivocado muchas veces. Es siempre mucho más probable que el error este entre el teclado y la silla.

2. Trabajar apurado. Quería terminar hoy y dejé que el apuro dominara mi forma de trabajar. Al final me llevó más tiempo que si lo hubiera hecho tranquilo.

3. No hacer un experimento. Si sospechaba que la herencia estaba andando mal, tendría que haber armado una clase sencilla y probar las cosas ahí. Si no lograba reproducir el problema, probablemente hubiera sospechado la verdad...

4. Insistir en arreglar el código que había hecho. Cuando uno no encuentra un error que obviamente tiene que estar ahí, lo más sencillo es borrar las modificaciones y empezar de nuevo. Tengo la costumbre de hacer commits muy frecuentes, así que volver atrás mis cambios no hubiera sido costoso. Además, estoy usando git, asi que también hubiera podido volver atrás temporariamente con un git stash.

5. Trabajar sólo. Este fue exactamente el tipo de problema que haciendo Pair Programming no me hubiera pasado.

Bueno, ahora que lo escribí se me pasó un poco la bronca... la próxima vez que sospeche del compilador espero acordarme...

Calidad III : La Relatividad del concepto

En los comentarios del post sobre la Calidad del Desarrollo de Software II tanto Walter Risi comoErnesto Kiszkurno aportaron un par definiciones distintas y muy interesantes de la calidad de software.

El concepto de la calidad de Software, en general, es decir Que hace que un software sea de calidad es uno de los temas que más discusión ha causado dentro de la comunidad de sistemas desde hace décadas.

En los 2 posts anteriores sobre Calidad del desarrollo hemos evitado justamente este tema ateniéndonos nada mas (pero nada menos) que al concepto, bastante más concreto, de que es lo que hace que un desarrollo sea de calidad. Es decir, para usar la metafora-que-odio-de-la-fabricación, que calidad tiene su construcción, su Calidad Interna.

Pero para no esquivar el bulto al problema más general, podemos plantearnos entonces , Que determina que un software sea de calidad?

El Juego

Uno de los sistemas que más utilizamos en nuestra época de estudiantes en Exactas (UBA) fue un juego (como no podía ser de otra manera) de estrategia en tiempo real llamado Dune II. Fue un juego que nos apasionó y en el cual podíamos pasarnos horas jugando hasta terminar las misiones. No obstante ese juego tenia un par de bugs molestos, uno de ellos con la Inteligencia Artificial de la maquina que justamente en determinadas situaciones no respondía bien en la defensa y el otro con el manejo del gusano de arena que ha veces se tildaba y quedaba ciclando en algún loop escondido.

Si nos hubieran preguntado allá en el tiempo pero incluso ahora que opinabamos de la Calidad de ese desarrollo, creo no exagerar en decir que era Sobresaliente, excepcional.

Hubiera agregado algo si la empresa dueña del juego arreglaba esos bugs? Probablemente hubiera sido lindo, quizás un poquito mas interesante pero....eso no hubiera cambiado la percepción de la Calidad del producto que teníamos, era sencillamente de Calidad.

Entonces, que es lo que determina que un producto de software sea de Calidad....y bueno... si no queda otra, ensayemos algunas respuestas habituales:

1) que sea utilizado por mucha gente?

Windows es el caso arquetípico de software utilizado por mucha gente que no obstante....digamos que jamás ha sido famoso por su Calidad (piensen sino en el caso cercano del Vista y ni que hablar de otros...ejem fallidos como ....alguien se acuerda del Milleniun?)

El software de Mac en general tiene asociado una fama de mucha mayor Calidad y es utilizado por muchisima menos gente.

2) que sea fácilmente usable?

El problema para determinar aquí que tal sistema es de Calidad por su usabilidad, más allá de los recientes libros y normas sobre usabilidad de Diseñadores gráficos, es que los usuarios tienden a encariñarse poderosamente con la interfaz de usuario que conocen. Siempre prefieren lo conocido por sobre lo novedoso.

Piensen sino en lo que diría un usuario de WordStar o WordPerfect si tuviera que usar el Word actual o, viceversa, si un usuario de Word tuviera que usar el Wordstar y para ambos la usabilidad de la herramienta que usan/usaban era formidable. Ni que hablar de la pelea entre los amantes de Vi versus Emacs versus editores de linea tradicionales.

Para los amantes de linux cualquier linux es totalmente fácil de usar pero si le damos una consola de comandos a una persona que siempre uso Windows...bueno...inmaginense su juicio.

3) que Tenga cero defectos?

Permitan me una sonrisa irónica, Jeje, no se conocen casos de software que se alegue que sean de Calidad por no tener Defectos sencillamente porque todavía no ha habido un software que no tenga defectos.

4) Que tenga muchísima funcionalidad y features?

Más allá de los casos conocidos como los productos de Office y para que vean que no la tenemos en contra de Microsoft ambos autores de este blog hemos utilizado un par de productos de GIS (Sistemas de Información Geográfica) de una empresa anglosajona que se podrían definir como el paraíso de la acumulación de funcionalidad y features. Uno de ellos se focalizaba en plotear mapas, el otro para hacer carga, procesamiento y consultas en sistemas de información Geográfica.

Cada uno de los productos tenia cientos de features y comandos, muchas veces con funcionalidad superpuesta que creaban una especie de frankestein gordo y pesado, un mamotreto de distintas funcionalidades mezcladas adonde nada se hacia realmente bien o perfomante porque todo era una solución de compromiso para poder hacer muchas cosas que casi nunca se necesitaban.

5) que Sea de bajo Costo y termine dentro de la planificación?

Seguramente son requisitos para el Gerente de un proyecto, el de Marketing o Ventas e incluso los interesados o StakeHolders pero...y los usuarios?

6) Que tenga buena calidad de desarrollo?

Esto justamente es lo que hablamos en el post anterior, y así como creemos profundamente que es un requisito indispensable por el mismo motivo que un edificio sin buenos cimientos se derrumbará, no es suficiente para que todo el producto, el sistema sea de Calidad. Es decir, podemos tener un sistema de una calidad de desarrollo excepcional pero que no sea útil para el o los usuarios en cuestión.

La raíz del problema

Justamente el problema que tiene cada una de las definiciones que intentamos y que han sido intentadas alguna vez, es que la CALIDAD es un término relativo. La calidad que es adecuada para una persona o tipo de persona puede ser totalmente inadecuada para otra.

Jerry Weinberg en su libro "Quality Software Management: System Thinking" habla justamente sobre este tema, y en particular como este concepto de "relatividad" se esconde incluso en

algunas de las definiciones más famosas de Calidad de Software.

Por ejemplo la de Crosby: "Calidad es el cumplimiento y satisfacción de los requerimientos", es decir que un sistema es de calidad si cumple con sus requerimientos.

El tema, o kid de la cuestión y que deberíamos preguntarnos es:

"Requerimientos de Quien o para Quien?", entonces, para ser más precisos deberíamos decir:

"Calidad es el cumplimiento y la satisfacción de los requerimientos de algunas personas"

Para cada persona el mismo producto tendrá distintas "calidades" y de hecho entonces cada sentencia que alguna vez se ha hecho o se hará acerca de la calidad del un sistema es una sentencia acerca de lo que consideran que es la calidad un determinado conjunto de personas.

Por ello, la próxima vez que estés desarrollando software, siempre, siempre preguntate:

"Quien o quienes son las personas detrás del concepto de calidad que están pidiendo para este sistema en particular"

Optimización de performance

En estas últimas semanas estuve dedicado a la optimización de la perfomance de una aplicación. Siempre es una actividad divertida, aunque muchas veces el esfuerzo invertido es demasiado en comparación con los resultados obtenidos. Por eso, armé esta lista de cosas a tener en cuenta, en base a la experiencia obtenida en esta y en otras batallas.

1. Medir antes de optimizar

Es muy difícil determinar a priori que componentes u operaciones causan que una aplicación no sea perfomante. Las intuiciones acerca de esto son casi siempre erróneas porque se corresponden con algo eminentemente subjetivo como el tiempo: el usuario o el programador recuerda que una operación le llevo "mucho tiempo" en alguna ocasión y piensa que eso es lo que hay que optimizar. Las mejoras de perfomance son también muy difíciles de ver a ojo, ya que pueden ser practicamente impercertibles.

Para evitar tener este problema, tener una métrica tomada en forma automática que nos permita tener una idea de la realidad y evite el andar adivinando. Hay muchas herramientas para escribir tests que simulen usuarios accediendo a nuestra aplicación, aunque a veces se complica su adaptación a una aplicación en particular o tienen licencias caras. En nuestro caso pudimos lograr scripts que simularan miles de usuarios utilizando simplemente Ruby y Mechanize.

2. No sirve optimizar fuera del cuello de botella

El código es siempre optimizable. Si miramos durante el tiempo suficiente cualquier método, se nos va a ocurrir alguna manera de lograr que sea más eficiente (y si no se nos ocurre nada siempre queda la opción de reescribirlo en C :)). El problema es que si optimizamos código que no es el cuello de botella de nuestra aplicación, nuestros usuarios no van a sentir ninguna mejora de perfomance. Si un proceso gasta el 95% de su tiempo de ejecución en una sola tarea, cualquier optimización en el resto del código va a ser impercertible. Nuevamente, es muy importante medir para poder determinar donde se encuentran estos cuellos de botella. Las herramientas más útiles en este sentido son los profilers, que nos permiten saber cuales de nuestros métodos utilizaron más tiempo de ejecución.

3. En vez de realizar micro optimizaciones, buscar maneras de reutilizar objetos ya calculados

En general, no es fácil encontrar optimizaciones importantes en código razonablemente bueno. Salvo casos muy particulares, el algoritmo que intuitivamente primero se nos ocurre es suficientemente bueno. Esto causa que optimizar estos algoritmos es una tarea con esperanzas de recompensas bastante bajas y al mismo tiempo bastante riesgosa. Por eso muchas veces es más conveniente guardar el resultado de un algoritmo para su posterior reutilización que buscar oportunidades de optimización; después de todo, el código que no se ejecuta siempre es el más rápido... Sin embargo, cuando decidimos utilizar estas técnicas, hay que tener en cuenta que estamos ganando velocidad de ejecución a costa de mayor utilización de memoria y que si este uso de memoria sube demasiado el uso de CPU también se va a disparar, por la mayor necesidad de ejecutar el Garbage collector. También hay que tener en cuenta que los resultados que tenemos cacheados pueden volverse obsoletos.

4. Aunque tengamos problemas de perfomance, la calidad del código es más importante que su eficiencia.

Despues de unas semanas enfocados en la perfomance de una aplicación, es fácil que confundamos las prioridades, así que vale la pena remarcar que la calidad interna del código sigue siendo la prioridad número uno. La principal característica del código de mala calidad es que es muy difícil de modificar, lo cual hace que sea peligroso implementar cambios que mejoren la perfomance.

5. Tener métricas reales de uso (o por lo menos una idea)

Muchas partes de nuestra aplicación se van a utilizar raramente o nunca. Otras partes se van a utilizar pero con muy pocos datos. Otras se van a utilizar en forma batch, sin usuarios esperando su resultado. Todas estas áreas tienen algo en común: no tiene sentido optimizarlas. Para saber en donde nos conviene enfocar nuestros esfuerzos, es necesario tener algún tipo de métrica que nos indique que módulos son los que realmente se utilizan.

6. Reglas de la optimización de código

Hacer que nuestra aplicación ande más rápido es algo que en general nos entusiasma como programadores. De todas maneras, siempre hay que tener en cuenta lo que la sabiduría de las generacion anteriores nos dice al respecto:

"Premature optimization is the root of all evil"
 DonaldKnuth

 "Rules of Optimization:

 Rule 1: Don't do it.
 Rule 2 (for experts only): Don't do it yet."

 Michael Jackson (no, no es ese, es otro Michael Jackson)