archivo

Archivos Mensuales: mayo 2010

No es malo dudar ya que en muchas ocasiones no se tiene clara cuál es la mejor opción. Es mejor, a veces, pensar sobre las alternativas antes de tomar una decisión.

¿A partir de cuándo una duda deja de ser productiva? A partir del momento en el que el tiempo necesario para tomar la decisión supera un máximo tolerable (o cuando no se toma una decisión). ¿Cuál es el máximo tolerable? En muchos casos no hay un límite temporal para decidirse por una de las opciones, en otros sí. En el caso de que no se tenga un umbral de tiempo claro, ya será el instinto de cada cual el que empezará a notar cuándo se está empezando a perder demasiado tiempo (tanto a él mismo, como a las personas que dependen de sus decisiones) y lo que es peor a que se pueda llegar demasiado tarde a algo por no haber tomado la decisión en el momento en que se debería haber tomado y que ese llegar demasiado tarde suponga perder un negocio, no cumplir unos plazos o cualquier otro aspecto que tenga consecuencias negativas.

Si no se tiene el instinto para notar cuándo se está empezando a dudar demasiado o no se adquiere con la suficiente experiencia, quiere decir que esa persona no está capacitada para tomar decisiones en su ámbito de actuación, por lo que otra persona debería tomarlas por él y por tanto no está preparado para tener el puesto que tiene. Eso no quiere decir que la persona no pueda ser válida para la organización, lo mismo lo es y mucho, pero en otro puesto donde sí se le pueda sacar partido a su verdadero potencial.

La toma de decisiones están en el sueldo y por tanto en él está la posibilidad de equivocarnos y atenernos a las consecuencias. Yo considero que es peor no tomar una decisión que equivocarse por haberla tomado, aunque supongo, que opiniones sobre esto habrá muchísimas.

Si de un determinado programa no se reciben incidencias, consultas o quejas pueden pasar dos cosas: que está muy maduro o no se utiliza (o tiene un nivel de uso prácticamente marginal).

Por regla general y desde mi experiencia, cuando se dan este tipo de circunstancias, es la segunda opción la que prevalece, ya que los usuarios de un software que se utiliza siempre dejan tras de sí ruido, poco o mucho, pero ruido al fin y al cabo, y suele ser, además, directamente proporcional al número de usuarios que lo utilizan, la rotación de los mismos y la complejidad del sistema.

Por este motivo, cuando una de las aplicaciones que coordino no genera este tipo de tráfico lo tomo siempre como una señal de alarma ya que lo más probable es que haya algo que no terminase de ir bien, ya sea la aplicación, la gestión del cambio, las directrices de uso de la herramienta, la atención a usuarios, el proceso de mantenimiento correctivo y evolutivo o una combinación de esos factores y otros muchos que pueden intervenir.

La Ley de Parkinson enuncia que: “el trabajo se expande hasta llenar todo el espacio de tiempo disponible para completarlo”.

Me parece muy interesante reflexionar sobre esto porque esta forma de actuar que es muy común en todos nosotros repercute directamente sobre nuestra productividad.

Esta Ley está intimamente ligada al Principio de Pareto, pese a que no habla de proporciones entre esfuerzo y resultado, ya que viene a decir que cuando no se dispone de fecha de fin para realizar una tarea o esta es superior a la que realmente necesitaría para realizarse, ésta tiende a dilatarse buscando conseguir mejoras que realmente aportan muy poco para el esfuerzo que requieren.

Por este motivo, es muy importante plantearse plazos realistas (no sobredimensionar) para realizar las tareas, si bien no todas, sí aquellas que sean repetitivas y aquellas otras que sean más urgentes o prioritarias en cada momento, de lo contrario, como nos sobra tiempo, terminaremos perdiéndolo, sacándole brillo a algo a lo que no le hace falta, revisando aspectos que no requieren revisión y en general, realizando actividades que no suelen servir para nada y que si bien nos puede hacer sentir activos, la realidad es que hubiéramos aprovechado mejor ese tiempo con otra tarea o simplemente viendo en la tele nuestra serie de televisión favorita.

Y lo peor de todo es que nos damos cuenta de que estamos perdiendo el tiempo y no le ponemos solución (¿o no hemos tenido esa sensación cuando por ejemplo estamos revisando una presentación y empezamos a añadirle o a cambiarle imágenes, a mirar si el texto está perfectamente alineado, si es mejor dividir una diapositiva en varias (o al revés), etc…?.

Es muy importante comprender que el esfuerzo por alcanzar la perfección no merece la pena, por un lado porque nunca vamos a llegar a conseguirla y por otro porque llegado un punto, para avanzar muy poquito hay que invertir un esfuerzo que no se corresponde con los logros que se van a obtener.

LCOM4 es otra métrica que utiliza Sonar y en la cual el concepto también es independiente de la existencia del producto.

Esta métrica mide la falta de cohesión de una determinada clase (forma parte de un conjunto de métricas que cogen su nombre de las iniciales de Lack of Cohesion of Methods). Antes de entrar a analizar cómo funciona esta métrica, es de interés mencionar aunque sea en líneas generales, qué es la cohesión y para qué sirve.

La cohesión mide la especialización (o la proximidad al principio de responsabilidad única) de una determinada clase o lo que es lo mismo cómo de relacionados están los distintos elementos (atributos y métodos) que la componen. Se entiende que clases más especializadas son más mantenibles. Esto es fácil de apreciar cuando por ejemplo miramos el código de una clase cohesionada y el código de una clase Tutti Frutti, en el primer caso veremos que la clase describe un objeto y su comportamiento, considerando dicho objeto como algo “atómico”, en el segundo caso nos podremos encontrar (exagerando mucho) clases que plancharán la ropa, jugarán al fútbol, te hacen un Cola Cao y son capaces de mantener una charla contigo sobre metafísica. Evidentemente, por muy complejo que sea el primer tipo de clases, probablemente el comportamiento, inteligibilidad, mantenibilidad, etc… de la segunda se vea afectado en sentido negativo.

Existen distintos grados de cohesión, según la forma en qué estén relacionados sus elementos. En el párrafo anterior me centré en la de carácter funcional, que es la que me parece más interesante.

¿Cómo funciona LCOM4? Cálcula un valor para una determinada clase, si ese valor es mayor que uno, la clase es sospechosa de falta de cohesión (cuento mayor sea dicho valor, menos cohesión tendrá). Lo que hace Sonar es indicarte el porcentaje de clases respecto al total que tienen un LCOM4 mayor que uno, así como calcularte el LCOM4 medio. Como en el resto de métricas de Sonar, la clave está en definir umbrales, es decir, qué porcentaje de clases con LCOM4 mayor que uno se considera aceptable y cuál es el máximo valor de LCOM4 admisible para las clases. Puede haber casos donde se pueda justificar superar dichos umbrales (suponiendo que dichos umbrales se hayan depurado con la experiencia), en ese caso, el equipo de desarrollo deberá explicar los motivos y ser coherentes si quiere que se le acepte la entrega.

Para el cálculo del LCOM4 de una clase básicamente lo que hace es medir el número de relaciones diferentes que se establecen entre métodos, teniendo en cuenta que un método se considera relacionado con otro si acceden a un atributo común de la clase o si uno llama a otro. Para el cálculo hay métodos que no se tienen en cuenta como por ejemplo los constructores. Tampoco se tienen en cuenta los accesores.

A través de este enlace podréis acceder a un ejemplo bastante bueno para comprender cómo se calcula esta métrica.

Por tanto, la cohesión es un factor a tener en cuenta junto al acoplamiento (entre otros factores) ya que condiciona la mantenibilidad y deuda técnica de los proyectos de desarrollo de software.

Hay algo que es lógico, si el producto no se vende es porque existen una serie de aspectos que no funcionan, por ese motivo y llegado a este punto es necesario analizar una serie de variables:

– ¿Realmente he establecido una serie de objetivos de venta o de beneficios?, ¿cuáles de ellos se han cumplido?, ¿cuáles no?, ¿se sabe el motivo por los cuáles unos objetivos se han cumplido y otros no?, ¿tenemos resultados objetivos que avalen estas conclusiones?, ¿sabemos cómo explotarlos?, ¿sabemos sacar conclusiones a partir de ellos?.
– ¿Tiene mercado mi producto?
– ¿Existe mercado pero la competencia es muy grande?.
– ¿Se está perdiendo cuota de mercado que ya se tenía ganada?, ¿cuál es el motivo?, ¿más competencia?, ¿han surgido más y mejores productos?, ¿son además más baratos?, ¿no ha está siendo adecuada la política de evolución del producto?, ¿estamos descuidando a los clientes?, ¿el problema no es realmente el producto sino el servicio que acompaña al mismo?.
– ¿Existe alguna manera de poder ganar cuota de mercado a la competencia?, ¿qué estrategia e inversiones tengo que realizar?, ¿están a la altura de mis posibilidades?
– ¿El producto no se vende porque no llega a su público objetivo?, ¿qué políticas de marketing y comerciales he aplicado?, ¿qué resultado ha dado cada una de ellas?, ¿cómo han afectado a cada uno de los objetivos que se han establecido?, ¿cuánto me han costado?, ¿estoy aplicando los resultados de estas políticas para intentar realizar una mejora de las mismas?.
– ¿Es correcta la política de precios que estoy aplicando?, ¿influye dicha política en las ventas del producto?, ¿hasta dónde es posible reducir el margen de beneficios del producto sin ir más allá de un riesgo asumible?, ¿hasta dónde es posible disminuir los costes de producción y mantenimiento del producto?.
– ¿Es realmente el producto que estoy realizando lo suficientemente bueno como para cumplir las expectativas de sus posibles usuarios y clientes?, ¿cómo está siendo la acogida del producto entre sus usuarios reales?, ¿estoy aplicando en los procesos de mejora del producto las opiniones de los mismos?.

Decenas y decenas de preguntas más nos podemos hacer cuando un producto no funciona en el mercado en un momento dado del tiempo (puede que nunca haya llegado a funcionar o que tras un tiempo en el que iba aceptablemente o bien, las ventas se han estancado o se han reducido considerablemente). Muchas de ellas serán incómodas de contestar, ya que evidenciarán errores que hemos cometido y a nadie le gusta que mirar debajo de su alfombra, pero si de alguna manera se quiere intentar revertir la situación o de dejar de invertir en el producto (una huida a tiempo antes de seguir perdiendo más dinero) no hay otra que hacer autocrítica.

Es verdad que sin tener ningún tipo de plan puede que todo salga estupendamente y que de igual manera que un producto lo mismo hoy no se vende, mañana sí lo haga, pero todo esto es equivalente a jugar la lotería. Claro que te puede tocar, pero dejar que la suerte o aspectos que no controlamos sean los que lleven los designios de la comercialización del producto no creo que sea ningún tipo de solución.

Todos tenemos toboganes emocionales, a veces estamos tremendamente animados, otras veces nos sentimos frustrados, aburridos, en ocasiones tenemos problemas laborales y/o personales, a veces estamos mejor o peor de salud, echamos más o menos horas en el trabajo, etc…

Es difícil mirando la situación en perspectiva de cada uno de otros mantener un equilibrio, ya que el peso que llevamos sobre los hombros no siempre es el mismo.

Esa circunstancia no va a variar, lo que sí podemos controlar es cómo influye esa realidad sobre nosotros mismos y los que nos rodean, ya que estos últimos no tienen porque aguantar más peso sobre las espaldas que el de por sí llevan y sobre nosotros porque si no asumimos que la vida da muchas vueltas no podremos extraer de cada instante de nuestro presente todas lo positivo que haya en ese momento. Esas cosas positivas, esa media sonrisa que nos sale de vez en cuando, son la que nos hace levantarnos cada mañana con ganas de seguir aportando cosas, a nosotros mismos, a los que queremos y a nuestro entorno personal y profesional.

Me gusta Sonar y creo que a mis compañeros también. Para ser justo, hay que mencionar también a PMD, Checkstyle y FindBugs porque Sonar debe mucho a esos proyectos.

Las métricas de Sonar asustan porque son muchas y algunas son complicadas de entender tanto en su significado como en su cálculo. Entenderlas es importante, pero tratar de interpretar a corto plazo el significado de todas puede llegar a hacer que sea algo tan abrumador que haga que se pierda el interés en todo lo que te puede proporcionar el producto.

Siguiendo este punto de vista, yo entiendo que la integración de Sonar dentro de nuestros procedimientos de certificación de la calidad del software resulta muy importante, pero también que su incorporación debe ser gradual, consolidando diversas métricas y mediante diferentes iteraciones y con tiempo, definir lo que serán nuestros márgenes de tolerancia, una vez que consigamos esto, ya será mucho más fácil ir incorporando en nuestros análisis nuevas métricas, sin olvidar de la mejora continua de los umbrales que se definan, porque sólo el tiempo y nuestra experiencia nos permitirá definir unos límites acordes a tener una deuda técnica baja, sin que suponga necesariamente un sobrecoste no asumible en los desarrollos, porque los presupuestos que tenemos son los que son y las aplicaciones, sobre todos aquellas que llevan en producción más tiempo, están como están.

Por ese motivo, probablemente nos centremos inicialmente en las siguientes métricas: Cobertura del código por pruebas unitarias, duplicidad de código, complejidad ciclomática y los comentarios, ya que son las más fáciles de interpretar y tienen repercusión directa en la deuda técnica.

Nos tocará definir, como he comentado anteriormente, cuáles serán los umbrales a partir del cual aceptaremos un software entregado, al principio nos equivocaremos y seremos o muy injustos con el proveedor o demasiado blandos, pero eso no me preocupa porque realmente lo importante es consolidar unos umbrales cada vez más acordes con la realidad y que también los proveedores entiendan que para nosotros no sólo es importante que el producto funcione, sino que también que los costes de mantenimiento se vean afectados lo menos posible por esos intereses que genera la existencia de deuda técnica en nuestras aplicaciones.

Probablemente definamos para cada métrica diferentes umbrales, ya que como he comentado en otros artículos, en el nuevo enfoque que tenemos pensado darle en las revisiones de la calidad del software y de su proceso de desarrollo y mantenimiento, vamos a definir diferentes itinerarios de validación en función de las características de la aplicación, ya que no es lo mismo un mantenimiento que un nuevo desarrollo y además todas las aplicaciones no tienen el mismo nivel de criticidad, complejidad, etc…

Soy consciente de que cada itinerario que definamos complicará un poco todo, ya que serán más umbrales los que tenemos que ajustar, pero entiendo que este incremento de complejidad es necesaria, porque umbrales generales no darán buenos resultados porque son precisamente eso, demasiado generales.

Por tanto, tenemos que ser coherentes con el número de itinerarios ya que tampoco es cuestión de tener itinerarios a la carta (para sistemas especialmente críticos sí que puede tener justificación, pero serían excepciones), para de esta forma tanto el ajuste de los umbrales no se nos escape de las manos y para tener en general, en los procesos de verificación del software y del desarrollo una visión de lo que se hace (demasiados caminos o formas de hacer las cosas, hace que la idea de conjunto se difumine y se requiera estar muy encima de todo para saber realmente qué se está haciendo y supondrá un esfuerzo que realmente no creo que merezca la pena).

En paralelo debemos empezar a trabajar con la definición de las reglas, ya que si bien son de utilidad las que Sonar trae de serie, necesitamos algo más, ya que nos gustaría que se verificase hasta donde sea posible el cumplimiento de las directrices de nuestro libro blanco de desarrollo, creado en su día y actualizado desde entonces con el objetivo de dar uniformidad a todos los nuevos desarrollos y mantenimientos evolutivos importantes, para de esta manera acotar su diversidad tecnológica y de arquitectura, facilitando de esta forma futuros mantenimientos y simplificando, hasta donde es posible, las tareas de administración del software que sirve las mismas.

Para ello, tendremos que utilizar los mecanismos de extensión de PMD. Este tema está todavía bastante verde y tocará madurar, ya que será necesario realizar ese desarrollo, pero teniendo claro qué reglas queremos que se verifiquen, además, tenemos que elegir dentro del conjunto de reglas de PMD, Checkstyle y FindBugs con cuáles nos quedamos.

Una vez realizada la extensión, tocará definir los umbrales para las reglas, que también serán variables en función de los itinerarios que se definan. Como podéis ver, si todavía nos queda camino por recorrer con las primeras métricas, no quiero decir nada lo que nos queda por andar en lo que a las reglas se refiere. En cualquier caso es cuestión de ir avanzando, aunque sea lentamente, pero avanzando.

Sonar es un producto bastante interesante y que desde mi punto de vista, debería ser tenido en cuenta en los ecosistemas de verificación de la calidad del software. Cierto es que no te dice si un producto funciona o no (cierto es que están las pruebas unitarias, pero para ello éstas deben estar desarrolladas), ya que para eso están las pruebas funcionales y no el análisis estático de código, pero sí que es bastante útil para poder evaluar la calidad de desarrollo de las aplicaciones, su mantenibilidad y su grado de adecuación a las directrices de desarrollo que se marquen.

También Sonar debería ser un referente para los proveedores de servicios de desarrollo de software, ya que la calidad de lo que se entrega puede ser un aspecto diferencial respecto a la competencia.