archivo

Archivos diarios: diciembre 29, 2011

Nuestro deseo de implementar sistemas que deleguen funcionalidad en terceros ya implementados, que intercambien información con otros o de utilizar librerías y frameworks que ahorren tiempo de desarrollo, es razonable ya que por un lado disminuye el esfuerzo de desarrollo, lo que nos permite centrarnos en los objetivos del proyecto y por otro permite avanzar en la consecución de un ecosistema de aplicaciones interoperable en una organización, rompiendo la filosofía de sistemas estancos que está implantado en muchas.

Ahora bien este objetivo, que es razonable y deseable no puede pelearse con la realidad y con un objetivo todavía de mayor importancia.

No puede pelearse con la realidad en el sentido de que para delegar funcionalidades en terceros componentes y para interoperar de manera sostenible con otros sistemas, es necesario que los mismos sean estables, además de que los cambios que se realicen en los mismos estén controlados. De lo contrario estaremos ante una situación parecida a un sistema de cañerías de los antiguos, donde se pierda agua en las juntas de las tuberías.

En el caso de los sistemas de información, llegaremos a una situación donde estaremos apagando fuegos más de lo deseable, donde éstos aparecerán cuando menos te lo esperas (y por supuesto, cuando sean más inoportunos) y donde es posible que al final, resolviendo estos problemas terminemos gastando más dinero que el que pretendíamos ahorrarnos (sin contar con los costes tangibles e intangibles de un sistema inestable).

Tampoco puede pelearse con un objetivo mayor que es conseguir igualar o sobrepasar las expectativas del cliente y/o el usuario, no puedes poner en juego las mismas, por el deseo de implementar una dinámica entre sistemas cuando todavía no se ha alcanzado en ellos un nivel suficiente de madurez, como para evitar los problemas descritos en los párrafos anteriores.

Hard code consiste en incorporar elementos de configuración en el código fuente lo que obligaría a volver a compilarlo en el caso de ser necesaria una modificación.

Es cierto que esta mala práctica puede parecer ya superada, pero era muy común encontrarnos con ella en sistemas desarrollados hace unos diez años (y tal vez, no tengamos que remontarnos a tanto, ¿verdad?).

Encontrarnos con hard code en un desarrollo en la actualidad no solo es síntoma de la falta de experiencia y/o conocimientos del desarrollador, habla también bien a las claras de la ausencia de normas de control de calidad en el equipo y/o en la organización que ha realizado el trabajo.

Desarrollar software es muy complicado, no solo por su componente técnico y por el hecho de que errores muy pequeños en el código puedan provocar incidentes graves, sino porque el proyecto se realiza en un contexto en el que interactúan personas, equipos e incluso organizaciones diferentes, cada una con sus objetivos e intereses.

Los proyectos entran en conflicto cuando alguna de las partes decide abandonar el objetivo general del proyecto (satisfacer las expectativas del usuario) para poner por delante sus objetivos individuales (como por ejemplo ganar o no perder dinero en el proyecto, dedicar más atención a otras tareas que entiende más prioritarias, etc…).

Es cierto que a veces se llega a estas situaciones por no respetar las condiciones de partida del proyecto y que eso provoque que una de las partes quiera imponer en un momento dado sus propias reglas. También es posible que desde fuera del ámbito del proyecto, personas o departamentos con un nivel superior en la jerarquía organizativa den instrucciones para que determinados trabajos tengan una mayor prioridad que el que se está realizando en el proyecto.

Pero también lo es que muchas veces se llega a esto por no haber gestionado de manera adecuada tu rol en el proyecto y los recursos que tienes a tu disposición y se llegue a una situación donde para salvar unos resultados pongas en riesgo el propio proyecto.

Es frecuente que este tipo de situaciones de lugar a un enfrentamiento de desgaste, del tipo de la guerra de guerrillas, donde el objetivo no es tanto ganar, como no perder. Para ello, se tiene que llegar a un punto donde al resto de stakeholders no le compense seguir con la situación y tengan que buscar una vía para continuar con el trabajo. A ese extremo se llega tras mucho desgaste.

Y efectivamente, no se ha ganado aunque el resultado parezca indicar que sí, ya que la actuación que ha tenido en el proyecto ha fracasado (independientemente de que se pueda reconducir posteriormente y terminar con un cierto éxito) y el resto de implicados ha perdido su confianza.

¿Qué te queda entonces? Solo el balance económico del proyecto (visión cortoplacista), pero si levantas la vista, en ese campo solo te queda desierto.