archivo

Archivos Mensuales: mayo 2010

La existencia de código duplicado en las aplicaciones es un problema más grande de lo que realmente se suele considerar.

Es importante entender que código duplicado no es exáctamente código exáctamente igual, sino que puede ser código con ligeras adaptaciones. Existen algoritmos, como el que utiliza CPD para la detección de estas duplicaciones. Es cierto que a veces puede haber falsas alarmas, pero su funcionamiento está lo suficientemente depurado como para pensar que los resultados que ofrece deben ser tenidos en cuenta, aunque sea para estudiarlos.

La existencia de código duplicado afecta a la mayoría de los ejes de los que depende la deuda técnica, ya que provocará una mayor complejidad ciclomática (ya comenté en el artículo que dediqué a esta métrica que esta es función de las líneas de código de la aplicación porque es normal que conforme crezca se incrementen el número de posibles caminos lógicos de la misma), un mayor número de pruebas unitarias (lo que afectará al % de cobertura, si no se construyen esas pruebas), una mayor cantidad de código que documentar, un posible incremento del número de reglas incumplidas, ya que todas aquellas reglas que se incumplan en un fragmento de código, se incumplirán en todos aquellas clases y métodos donde se haya duplicado el mismo, etc…

Por tanto, el código duplicado incrementará los costes de mantenimiento del software y esto es un problema.

¿Cómo se llega a la existencia de código duplicado? En primer lugar porque es prácticamente imposible conseguir un código sin duplicaciones, salvo que la cantidad de dinero que se invierta para depurar y depurar sea tan grande que al final, no merezca la pena intentar conseguir un código sin duplicados. En segundo lugar, porque en muchos casos el código duplicado se genera sin querer, generalmente porque hay diversas personas trabajando en el proyecto y existen determinadas funcionalidades comunes que cada uno termina implementándola por su cuenta (se hace más de una vez lo mismo y de la misma manera), esto resulta complicado de controlar en un proyecto con un cierto tamaño, y también porque a veces el proyecto es tan grande y tan largo que te olvidas de que ya has implementado un determinado código y lo vuelves a hacer.

Tambień pesa mucho en todo esto la experiencia y pericia del programador, ya que un técnico de estas características si decide esmerarse en ello, producirá un código con menos duplicaciones que otro que no cuente con su bagaje profesional y/o sus capacidades.

Existen otras situaciones, las típicas urgencias, que también derivan en duplicar código. Hay que resolver un problema, he visto que en esta parte de la aplicación está resuelto de tal manera, tengo poco tiempo, así que copio el código y lo adapto.

PMD a través de CPD o Sonar que a su vez puede hacer uso del mismo, permiten obtener métricas de duplicidad del código y también navegar hasta donde se encuentran esas posibles duplicidades, por lo que pueden ser herramientas de mucha utilidad para estudiar esta métrica en las aplicaciones de tu organización y para tomar medidas para mejorar los datos si se estima conveniente.

Hay muchos que dicen que la mejor negociación es aquella en la que todos ganan pero, ¿realmente lo piensan?, incluso pensándolo, ¿es posible conseguir un empate en el que todos ganan los mismo? pues lo más probable es que no.

No trataré en este artículo el análisis de aquellas negociaciones con personas con las que nos une un vínculo emocional porque en estos casos el mantenimiento de la salud del vínculo estará en muchas ocasiones por encima del resultado de la negociación, es decir, en estos casos sí me puedo creer el ganar-ganar o incluso si hiciera falta el perder-ganar.

Personalmente, me cuesta negociar con personas con las que tengo vínculo emocional porque aunque en el momento de negociar lo desconecte, cuando estoy en frío vuelvo a activarlo e independientemente del resultado que haya tenido en la negociación me siento incómodo, ya sea por el proceso, por el resultado o por ambos aspectos. Para mi es importante el vínculo emocional, porque como he dicho muchas veces, el plus en los proyectos, en la vida diaria, lo dan las personas, no los empleados, los clientes o los proveedores.

Todos nos llevamos el día negociando, en el trabajo, en la vida personal y cuando se negocia es porque se quiere algo. Se puede estar dispuesto a hacer concesiones, pero el objetivo al final es conseguir lo que se pretende. Una vez que se consigue lo que se pretende, puede dar un poco más igual si la otra parte ha conseguido todo (complicado, si uno ha ganado), parte o incluso nada. Pero incluso consiguiendo parte no se tratará de un ganar-ganar, porque realmente ganar, lo que es ganar, sólo ha ganado de verdad uno.

Por ese motivo, cuando en una negociación con alguien con el que no te une un vínculo te habla de obtener resultados en los ganen todos, cógete fuerte a la silla, porque lo que realmente está diciendo es que su objetivo es conseguir lo que quiere o la mayor parte de lo que pretende y si eso implica que tú no te lleves nada o te lleves muy poquito (o te lleves menos que lo que realmente la otra parte va a ganar), eso es lo que te llevarás.

No es la Ley de la selva, sino una guerra de intereses, es parte del trabajo y todo un arte. A veces se gana, otras se pierde. De igual manera que hay gente que destaca en el aspecto técnico, otros en la gestión o en las actividades comerciales, hay personas que destacan también sobre el resto en los procesos de negociación. Estas personas que destacan en este ámbito además de obtener buenos resultados en la mayoría de las casos, consiguen también que la otra parte crea que también ha ganado, por lo que la “victoria” es doble, ya que de esta forma, tendrá el camino allanado para una futura negociación con dicha parte, que tendrá probablemente, las defensas más bajas.

Partamos de la base que a mi también me gustaría ganar mucho más dinero del que gano, pero este artículo no va de eso, sino de hacer algunas reflexiones sobre algunos factores que pueden hacer que un salario X valga más o valga menos:

– Un factor a tener en cuenta es el tiempo. Supongamos dos trabajadores que ganan 1.200€ netos cada uno y que realizan unas tareas parecidas en la organización. Uno trabaja 40 horas a la semana, otro con el overtime que necesitan los proyectos en los que participa tiene que echar unas 50 horas a la semana. En el primer caso, lo que se cobra por hora trabajada son 30€, en el segundo caso 24€ la hora. Aplicando estas consideraciones, personas que cobran menos que otras, al final pueden tener un sueldo por hora trabajada mayor, si este sueldo es suficiente para tener un nivel de vida más que decente, lo mismo es más positivo tener un equilibrio entre el número de horas trabajadas y el sueldo, que tener simplemente un salario más alto. La clave por tanto está en definir qué cantidad es la mínima que consideramos que necesitamos ganar para tener el nivel de vida que nos gustaría, ya que una vez alcanzado ese mínimo, ¿para qué plantearse ganar más dinero trabajando más horas teniendo en cuenta que lo mismo lo que ganamos por hora es igual o menos de lo que ganamos ahora?.

No estoy diciendo que se renuncie a ganar más dinero, ¿por qué no querer cobrar más dinero haciendo el mismo trabajo o teniendo algo más de responsabilidad sin que aumente el número de horas que se trabaja o que incluso aumentando sea algo asumible por nosotros (teniendo en cuenta de que en la medida de lo posible hay que intentar que el sueldo por hora trabajada sea mayor)?. Lo que vengo a comentar es que no siempre ganar más dinero en términos absolutos se corresponde con mejoras en la calidad de vida, ya que lo mismo sí que se tiene más dinero, pero cuesta más trabajo conseguirlo y por tanto lo mismo cuesta más disfrutarlo o para ganarlo tienes que renunciar a algunos aspectos de tu día a día extralaboral que también tienen su valor para ti.

– Otro factor es el entorno aplicado al factor tiempo. Se pueden ganar 3.000€, pero si los que están a tu alrededor hacen un trabajo de características similares al tuyo (en características y responsabilidad) y con unos niveles de producción parecidos y cobran 5.000€, se vuelve a aplicar el cálculo de coste por hora y tu salario que es bueno de por sí, ya no lo es tanto.

– Otro factor es el entorno externo. Que es similar al caso anterior, pero teniendo en cuenta no a tu entorno directo sino a otras empresas del sector.

– Otro factor es la localización geográfica. No es lo mismo ganar 1.000€ al mes en España que en Londres o en países donde el coste de la vida sea mucho menor. Por tanto un sueldo que en España puede ser bajo, en otros países puede serlo todavía más y en otros permitirte llevar un nivel de vida medio o alto.

En resumen, el salario no es un valor absoluto, pese a que todos los meses en tu cuenta corriente entre la misma cantidad de dinero, ya que su verdadero valor se encuentra en el nivel de vida que pretendamos llevar, en la cantidad de tiempo que dediquemos al trabajo, en nuestros entorno y en el lugar del mundo en el que residamos.

Si se construye un producto sin tener el mercado, necesitamos poder encontrar uno para el mismo y puede pasar que no exista y nos encontremos con un producto que puede ser maravilloso pero que no tiene un mercado donde pueda venderse. También puede darse el caso de que exista mercado, pero está saturado por competidores con los cuales resulta muy complicado echar un pulso, ya sea porque están bien muy bien posicionados, porque tienen un producto bastante bueno, porque tengan una fuerte infraestructura económica o cualquier combinación de estos factores y otros que puedan darse.

La ventaja de estudiar diversos mercados antes de desarrollar un producto permite que por lo menos se elija uno en el cual se tiene posibilidad de éxito. El estudio no asegura acertar, que el producto que se desarrolle sea aceptable o que la política comercial sea adecuada, pero permite, por lo menos, iniciar un camino en el que hay menos obstáculos y existe la posibilidad de que seas tenido en cuenta.

Sin olvidar de la eficacia de la Regla de los dos minutos, la cual intento aplicar siempre que puedo, hay otra regla que estoy también intentando de poner en marcha y es la agrupación de la realización de tareas de corta duración en tandas.

Esta agrupación en tandas disminuye el overhead, ya que si por ejemplo para realizar esas tareas tienes que abrir un software específico, lo abres una vez, realizas las tareas y lo cierras, no que de la otra forma, además del coste en tiempo del cambio de contexto, está el coste de acceder al programa, buscar las pantallas que te permiten realizar esa tarea y después por último cerrarlo.

No es un concepto incompatible con la Regla de los dos minutos, ya que siempre van a surgir tareas de corta duración no susceptibles de ser agrupadas en tandas y que lo mejor es quitárselas cuanto antes de encima.

Una manera muy sencilla de empezar con la aplicación de las tandas es la creación de filtros de correo específicos de determinadas temáticas que te llegan al mismo y que suponen la realización de una tarea o bien su lectura (al tratarse de temás comunes la simple lectura de los mismos, se efectuará de manera más rápida y facilitará su comprensión y la asociación de ideas).

El problema de aplicar las tandas, sobre todo si esperamos a que se acumulen es que siempre podemos pensar que hay algo importante y urgente que podemos dejar de realizar a tiempo. Eso es posible, pero todo dependerá del tipo de tareas que elijamos tratar por tandas y de la confianza y experiencia que poco a poco vayamos cogiendo en el método, lo que permitirá por un lado seleccionar adecuadamente qué aspectos tratamos por tandas, qué cantidad de esas tareas podemos acumular con un umbral de riesgo razonable y sobre todo, darnos cuenta también, de que una buena parte de las tareas no requieren una solución inmediata o a muy corto plazo.

El software como servicio (SaaS: Software as a Service) es una aplicación más de la orientación al producto, sólo que en este caso el producto o productos se encuentran en unos servidores que el proveedor tiene en la nube (por lo que pueden ser suyos o alquilados) y el negocio se centra en arrendar el uso de las aplicaciones y herramientas a los posibles clientes.

Este alquiler puede hacerse por regla general siguiendo criterios temporales (se alquila la utilización del software durante X meses), por criterios de volumetría (se alquila por número de transacciones, almacenamiento, etc…) o una combinación de ambos. Eso sí, el cliente no sólo se asegura la utilización del software, sino que también demandará un determinado nivel de servicio. Es posible que el proveedor ponga a disposición del cliente un menú de ANS para que éste elija (y pague) en función de las necesidades que tenga.

En el software como servicio el cliente, por tanto, se limitará a hacer uso de él, debiéndose exclusivamente de preocupar porque se cumpla el nivel de servicio por el que se está pagando. Esto supone una gran ventaja sobre todo en aquellos casos donde tener una herramienta de las características de la que se va a utilizar instalada en una infraestructura propia puede ser muy costoso o imposible, en función del tamaño, líneas de negocio, facturación, etc… que tenga el cliente.

También el proveedor tiene sus ventajas, ya que su objetivo es cumplir el ANS y al cliente le dará en cierto modo igual como lo consiga. Por tanto, si se lo propone podría tener externalizado desde el alojamiento de las aplicaciones hasta la administración de los sistemas que las sustentan o la atención a usuarios (si también se ofrece este servicio de manera complementaria al producto), pudiéndose centrar en el desarrollo y evolución de los productos y en la actividad comercial y de marketing. Esta flexibilidad, permite obtener un margen razonable incluso ofreciendo los servicios a un precio muy competitivo.

También hay casos en los que el software como servicio se ofrece de forma gratuita a los clientes, este es caso por ejemplo de WordPress, que me permite publicar este blog sin que yo tenga que pagar un solo euro. ¿Qué gana Automattic con esto? Pues la posibilidad por ejemplo de que adquiera alguna de las mejoras que ofrece. También me permite ser un grano de arena dentro de la multitud de personas que utilizamos sus servicios, algo que la empresa puede explotar para vender otro tipo de servicios o para tener un mejor posicionamiento en el mercado.

Es cierto que los clientes nos dejamos llevar demasiado por conceptos funcionales, por aplicaciones que se puedan parametrizar lo máximo posible sin necesidad de recompilar, por lo atractivas y usables que resulten, etc… Lo que hace que nos olvidemos en demasiadas ocasiones de que debajo de esa alfombra puede haber muchas “cosas escondidas”.

No hay que olvidarse nunca de la parte funcional, porque de nada sirve una aplicación con una calidad excelente si no cumple los objetivos que se persiguen con la misma. Por tanto, una vez que se comprueba que la herramienta verifica completamente o casi lo que pretendemos con su adquisición, es cuando debería entrar en acción el conocimiento de su deuda técnica.

Por tanto, Sonar y su cuadro de mando de métricas y sus cálculos de las distintas variables que influyen en la deuda técnica, puede utilizarse para vender un producto concreto (no sólo te estoy ofreciendo el producto que hace lo que quieres, sino que además tiene unos niveles elevados de calidad del software) o para vender cualquier producto del catálogo (estas son las métricas de calidad de las aplicaciones que desarrollamos, sin trampa ni cartón, ya que utilizamos las reglas por defecto que trae Sonar y si te parece conveniente aplicamos las reglas que vosotros tengáis definidas y vemos que sale. Como podéis ver nuestra filosofía es hacer productos a la altura de las necesidades de los clientes y con la máxima calidad posible en el proceso de desarrollo, ya que esto es bueno para los clientes, ya que tienen productos con una deuda técnica prácticamente inexistente y para nosotros, ya que nos permite una más rápida evolución y mejora de los productos ya que el sobrecoste o sobreesfuerzo que traen consigo unas malas técnicas de codificación han desaparecido).