archivo

Archivos diarios: enero 7, 2012

En el desarrollo de software hay que estar continuamente tomando decisiones o por lo menos así debería ser en un proceso de desarrollo que se adapte a la lógica de funcionamiento de los proyectos en los que siempre se está pisando un terreno frágil y en donde la adaptación del producto al feedback del usuario resulta esencial para llegar a cumplir sus expectativas.

Y muchas veces nos equivocaremos (nadie es infalible), otras muchas acertaremos.

Lo peor que puede pasar es la inacción por el miedo a tomar decisiones, por darle mil vueltas a un problema, por analizar y analizar diferentes alternativas. Una variante de esto la tenemos en el cambio continuo de opinión cuando ya se ha tomado una decisión (bienvenida sea la corrección a tiempo, pero siempre que sea eso, una corrección, no el resultado de cambios de opinión que no parecen guardar una cierta lógica).

Un caballero de tres cabezas es quien no toma decisiones, las toma tarde o añade mediante sus actos todavía una mayor incertidumbre a la ya de por sí que de manera inherente existe en los proyectos de desarrollo de software.

Todos aspiramos a mejorar dentro de nuestra carrera profesional, ya sea a nivel vertical o a nivel horizontal (en función de nuestros intereses) y ese es un aspecto que nos proporciona motivación para intentar hacer las cosas lo mejor posible.

Sin embargo, ¿qué pasa cuándo vemos que los posibles huecos que podrían quedar para seguir progresando en nuestra organización tienen ya nombres y apellidos?, ¿qué pasa si además sus méritos son más que discutibles?.

En muchos casos, provocará la salida de la organización en busca de otras alternativas que permitan continuar con la progresión de la carrera profesional (con la consiguiente pérdida de talento por parte de la organización), en otros, se producirá una pérdida de motivación que impactará directamente en la productividad.

Quisiera apuntar que desde mi punto de vista, todavía peor que conocer el presunto heredero es no conocerlo previamente y que su elección sea realizada por criterios no objetivos.

Otro antipatrón muy típico.

Se invierte una gran cantidad de dinero en el desarrollo de un sistema de información. Cuando está terminado o se han liberado un número significativo de módulos se cae en la cuenta de que el sistema no cumple las expectativas del usuario, no tiene un rendimiento adecuado, presenta una deuda técnica elevada y/o un gran esfuerzo en el mantenimiento (ver antipatrón “gran bola de lodo“) o una combinación de algunos o todos de los ejemplos anteriores y algunos otros más.

Cuando se llega a ese punto, lo mejor es migrar a una nueva solución, sin embargo, es tal la cantidad de dinero invertida que lo más habitual es que se decida una huida hacia adelante y se realicen parches sucesivos de la herramienta en búsqueda de satisfacer por los menos las expectivas de los usuarios, además de corregir aquellos errores más significativos.

De esta forma el sistema de información (y todos aquellos vinculados a él) ha quedado atrapado en una trampa para osos de la que resulta muy complicado salir.

La teoría de la evolución deja patente que aquellas especies que mejor y más rápido se adaptan a su entorno son las que sobreviven.

Esta teoría es aplicable también al mundo de los negocios donde el mercado provoca un ecosistema que cambia continuamente, donde la competencia es feroz y que está lleno de incertidumbre.

Supuestamente en un entorno como este solo quedarán aquellos que se hayan adaptado mejor a su funcionamiento y que más flexibilidad presenten ante el continuo cambio. Solo deberían sobrevivir los mejores (no los más grandes, si no que le pregunten a los dinosaurios) ante las circunstancias que vaya marcando el mercado.

En el desarrollo de software debería pasar lo mismo. De hecho está pasando. En la situación actual de crisis muchas organizaciones lo están pasando muy mal y otras están desapareciendo y esto ha sido provocado en gran medida porque en la época de bonanza económica y burbuja del desarrollo de software (provocada especialmente por la modernización de la administración pública) el principal interés ha sido contar el dinero que se ingresaba mensualmente y no la de establecer unas estructuras para la organización que permitiera su crecimiento y evolución.

Alguna que otra vez he hecho referencia a una cita del libro “Cimas y Valles” de Spencer Johnson (del que recomiendo su lectura) que dice lo siguiente: “Las cimas y los valles está conectados. Los errores que cometes en los buenos momentos del presente crean los malos momentos del mañana. Y tus aciertos en los malos momentos del presente crean los buenos momentos del mañana”.

No puedo estar más de acuerdo con Spencer Johnson.

Según Darwin, esas organizaciones que no han sabido adaptarse deberían desaparecer, sin embargo, no es así y eso realmente es una demostración de por qué en nuestro país no conseguimos un nivel de competitividad medianamente decente.

¿Por qué sobreviven? Factores hay muchos, pero uno de ellos es la cultura de la subvención (a lo que se suman otras medidas como la reducción de masa laboral y/o salarial, incremento de la jornada laboral, una mayor austeridad, etc…). Lo que no se logra en los negocios te lo proporcionan las administraciones públicas. Como siempre tienes esa carta bajo la manga que te va a salvar, ¿para qué voy a esforzarme por ser más competitivo? ya vendrán tiempos mejores donde vuelvan los ingresos sin necesidad de tanto esfuerzo como ahora.

La supervivencia de estas organizaciones es un ataque directo a la crisis del software porque son entidades que no han sabido y/o no han querido entender la idea de que lo realmente importante para fidelizar clientes y ganar mercado es la calidad del software, junto a la innovación, además de establecer unos procesos internos que permitan dinamizar el funcionamiento de la organización.

Pese a que en casi todo naufragio hay supervivientes, la coyuntura económica actual junto a la aparición de empresas pequeñas pero muy competitivas debería ser un toque de atención para aquellos que siguen con políticas de desarrollo de software negativas y/o con procesos internos inexistentes o inapropiados y que no terminan de cambiar: o te adaptas (y con ello ayudas a todo el sector y a ti mismo, con un enfoque del desarrollo de software orientado a la calidad que permita dar una vuelta a la consideración que tiene el resto de sectores con nosotros) o desapareces.

Una máquina de Rube Goldberg es un aparato que realiza una tarea muy simple de manera mucho más compleja y enrevesada. Estas máquinas son auténticos retos intelectuales, lo que hace que incluso se celebren concursos en diferentes lugares del mundo, donde lo que se valora precisamente, además de la originalidad, es precisamente la complejidad de los pasos que se realizan antes de alcanzar el objetivo.

Si el desarrollo de software ya es complejo de por sí, ¿por qué incorporar complejidad adicional?, a veces será por no salirnos de un patrón o forma de realizar las aplicaciones, otras por el propio ego de los desarrolladores que pretendemos dejar siempre que podemos nuestra huella en los sistemas en los que participamos, otras por no saber priorizar de manera adecuada las tareas a realizar, otras por la falta de cualificación del equipo de proyecto, en otros casos no se encuentra una solución directa y se busca alcanzar la misma mediante la concatenación de soluciones indirectas y así podemos continuar con infinidad de causas que incrementan de manera innecesaria la complejidad natural del propio sistema a desarrollar y del propio proceso de desarrollo de software.

Este antipatrón recibe el nombre de una canción infantil. Os la pongo tal cual:

Oh, The grand old Duke of York,
He had ten thousand men;
He marched them up to the top of the hill,
And he marched them down again.

And when they were up, they were up,
And when they were down, they were down,
And when they were only half-way up,
They were neither up nor down.

Como podréis ver describe simplemente la acción de subir una colina, para después volverla a bajar. Se considera como una metáfora del esfuerzo invertido de manera gratuita o innecesaria.

No obstante, este antipatrón, aunque en el fondo haga referencia a un esfuerzo de esas características, quiere hacer hincapié sobre todo en una de sus posibles causas.

De igual manera que roles de carácter funcional resultan de mucha utilidad como nexo de unión (que no intermediario) entre usuarios y equipo de proyecto, también es necesario destacar la figura de los arquitectos software y a más bajo nivel los analistas orgánicos.

En el caso de los primeros existe una visión más abstracta del comportamiento funcional del sistema de información y en el de los segundos existe una visión más abstracta de la arquitectura de la aplicación, en ambas situaciones se ve el bosque y no los árboles.

Es frecuente encontrarnos con proyectos donde alguno de los dos perfiles no interviene (cuando no los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las especificaciones del usuario.

Esto suele provocar (de ahí la analogía con la metáfora de la canción de “El gran viejo Duque de York”) que determinadas decisiones, al tener una visión demasiado a bajo nivel de la aplicación, no busquen la solución más óptima y obligue a hacer esfuerzo de más o incluso a un esfuerzo innecesario.

Por tanto, lo que viene a decir este antipatrón es que equipos de proyecto descompensados entre visiones más abstractas y más concretas pierden productividad.

Hay opiniones para todos los gustos. Una de la más extendida es que son conceptos distintos y que no tienen influencia uno sobre otro.

Yo soy de la opinión de que expresando cosas distintas son compatibles y por tanto sí que existe esa influencia.

En la programación defensiva trato de proteger secciones del producto de la volatilidad de las funcionalidades y de los errores del usuario (especificaciones incorrectas) y propios (efectos colaterales, especificaciones que no se han terminado de comprender bien, etc…).

¿Dónde entra en juego la deuda técnica? En el momento en que hay que seguir evolucionando el software (o realizar correcciones), con una deuda técnica por encima de la que el producto debería tener, el esfuerzo es mucho mayor y tardamos más en dar una respuesta. En ocasiones si el cambio es importante y la deuda técnica alta, el desarrollador se encuentra con un problema muy serio.

Una deuda técnica baja (o al menos proporcional a las características del producto y del contexto en que se ha desarrollado) nos permite reaccionar mejor al cambio (sea cual sea su origen) por lo que tener en cuenta esta características supone, al menos para mi, una importante estrategia de programación defensiva (de hecho hay parámetros que se utilizan para medir la deuda técnica como es la cobertura mediante pruebas unitarias que suponen técnicas directas de programación defensiva).