lunes, 27 de junio de 2011

Patronitis


Al final no me he podido resistir. No podía dejarlo para mucho más adelante. Si ayer lo nombraba, hoy me apetecía hablar de una de las enfermedades más comunes de los desarrolladores de software: "la patronitis".

No os molestéis. Este término no aparece en ningún diccionario oficial. Sin embargo, sí puede encontrarse en diversos blogs y libros editados ya hace algunos años. Pero es estos días cuando parece estar más de moda.

En algún blog podemos ver una  definición como:
Patronitis: N. fem. Dícese de la enfermedad propia de programadores que consiste en querer aplicar patrones de diseño a todo.

Sin embargo, no considero esta definición del todo exacta. He podido observar esta enfermedad también en analistas, arquitectos, y otras categorías supuestamente más experimentadas.

Normalmente el problema se debe a nuestra naturaleza friki innata, que nos reclama el uso de todo aquello que hemos aprendido, independientemente de su adecuación al caso. ¿Que no aplica? Pues da igual, se mete, aunque sea con calzador. Y así nos van las cosas. ¿Que se pone de moda la arquitectura de 14 capas? Pues se usa. Luego ya iremos eliminando cosas que realmente sobren. Y el problema es que siempre encontramos un uso para algo.

Una vez me enseñaron una regla de oro, de las que no se deberían olvidar nunca: "Un software no está completo cuando ya no se pueden añadir más funcionalidades, sino cuando no se puede eliminar ni una sola más".

Y es que al final, no es la experiencia en el desarrollo de aplicaciones mediante patrones y la aplicación de las diversas tecnologías lo que nos da la experiencia suficiente para saber dónde está el límite en el uso de los patrones. Es al tener que mantener esas aplicaciones, bien desarrolladas por nosotros mismos, o bien por otros, cuando vemos cuán complicadas son las cosas. Un buen artículo (con algunos añitos a sus espaldas ya), está en: http://www.javahispano.org/contenidos/es/el_peligro_de_los_patrones/
Este artículo es bastante conocido por internet, y tiene muchos seguidores y detractores. Allá cada cual.

Finalmente, para los que os gusta visualizar y ejemplizar las cosas, ahí va una perla: (extraída de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx):

Design Patterns: A Love Story

Richard tilted his head to watch the waves push flotsam against the boat hull below. Up and down, the flotsam moved. Up and down.
Richard had an idea.
“Virginia, my dear”, he said to the blond woman beside him. “We’ve been singletons on this ship for a long time”.
“I know, Richard”, she replied. “My mean step-mother, the intercepting filter that she is, denies me time with others.”
Richard paused for a moment, to contemplate strategy. Her father, with his pipes and filters, would return soon, and force them to communicate over his message bus. He glanced aft, and saw no one else around. Richard turned his front controller to face Virginia, and looked her in the eyes. She was close now, and Richard could feel his active record rising.
“Virginia”, he whispered. “There is no observer in sight. Let us run below deck. I want to peel away your façade, and tightly couple.”
“Oh yes, Richard”, she blushed, and leaned towards him. “I want you to give me a dependency injection”.

[Actualizado el 19/02/2015:]
Acabo de ver en el blog de Javier Garzás, un artículo que me ha recordado éste mío. Javier incide en la idea que intento hacer ver en este post, y es que no hay balas de plata, y que las herramientas sólo deben aplicarse cuando aplica. Pero incluso cosas que parecen tan básicas que las tenemos como los cimientos de todo (véase la orientación a objetos, uso de patrones, etc). Si no nos replanteásemos las cosas de vez en cuando...seguiríamos en la prehistoria.

domingo, 26 de junio de 2011

Técnicas ágiles: Principio KISS

El principio KISS, es uno de esos acrónimos que quedan bien en cualquier presentación. Es una palabra conocida en inglés, y al mismo tiempo, es una frase simple y útil en el desarrollo de software.

"Keep It Simple, Stupid"

Supongo que alguien tuvo que añadir la palabrita final para conseguir doblar la S, y que así tengamos la palabra en inglés.

Básicamente, esta técnica general, se basa en que en cada una de las actividades del desarrollo software, debemos valorar si estamos realmente adoptando la solución más simple o no. Esta técnica ha sido abanderada por las metodologías ágiles, que rápidamente la han adoptado como suya.

Al mismo tiempo, es una afirmación correcta en cualquier desarrollo. No siempre se tiene la entereza de mantener la simplicidad. Más cuando uno es novato en alguna tecnología y quiere demostrar que tiene la suficiente destreza, o bien simplemente quiere utilizar el último patrón o framework de moda.

Hay un término de moda, y es la "deuda técnica". Este término está relacionado con el principio KISS. Si sabemos mantener la simplicidad en cada una de las facetas del desarrollo, estaremos disminuyendo la deuda técnica. Es curioso, pero en Wikipedia encontramos la definición siguiente de deuda técnica: "La deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware." (http://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica)

Si ahondamos en la definición, veremos que la deuda técnica no siempre estaría originada por un "desarrollo apresurado". Podemos hacer un exhaustivo análisis, diseño técnico, definición arquitectónica, etc. Y sin embargo, eso no asegura que no vaya a existir una deuda técnica en un futuro inmediato. Puede ser una arquitectura demasiado rimbombante, un complejo diseño técnico que no se vea actualizado...o una implementación desviada del diseño...o un uso indiscriminado de patrones ("patronitis", algún día os hablaré de ello).

Y para terminar, un ejemplo que me ha gustado y que he leído en más de un sitio (con ligeras variaciones). Éste en concreto, está extraído de un blog (http://www.gedpro.com/Comunidad/Blogs/tabid/69/EntryId/465/Principio-KISS-en-la-gestion-de-proyectos.aspx) en el que hablan del término KISS para temas de gestión de proyectos. Pero como el mismo autor reconoce, es un término válido para cualquier faceta del desarrollo:

Cuenta la leyenda que cuando la NASA inició el lanzamiento de astronautas, se dieron cuenta enseguida de que los bolígrafos no funcionarían con gravedad cero. Para resolver este problema, la NASA contrató a Accenture (la antigua Andersen Consulting). Una década y 12 millones de dólares después, la NASA disponía de un innovador bolígrafo que escribía con gravedad cero, hacia arriba y hacia abajo, bajo el agua, en prácticamente cualquier superficie, incluido el cristal y en un rango de temperatura desde -30ºC hasta más de 300ºC. Los Rusos utilizaron un Lápiz.

sábado, 25 de junio de 2011

Evaluación de madurez CMMi nivel 3

Recientemente me he visto involucrado en un proceso de evaluación de madurez CMMi Dev Nivel 3. He sido al mismo tiempo:
  • Desarrollador de la metodología compatible CMMI
  • Auditor de proyectos
  • Parte del equipo evaluador CMMI
  • Preparador de base de datos de evidencias

Tras un SCAMPI A, se adquiere una nueva experiencia, y se amplía la visión del mundo de la calidad y del desarrollo del software.

En el mundo del desarrollo software, hay muchas menos novedades de las que nos quieren vender, y de las que sin embargo los neófitos se hacen eco constantemente, abrazándolas como el nuevo mantra que nos sacará de la crisis y permitirá que los proyectos por fin tengan éxito (¿alguien tiene claro el concepto de éxito?).

CMMi lleva muchos años en el mercado (e incluso ha ido cambiando su nombre). Sin embargo, en muchos ámbitos se percibe como un dinosaurio. Leo en blogs a gente que habla (supuestamente por experiencia o conocimiento directo) de que CMMi es esto o aquello, que no resuelve la problemática, y que los proyectos siguen fallando.

El caso es que yo sigo observando proyectos que a pesar de usar metodologías y técnicas ágiles, fallan igualmente. ¿Dónde está el problema? ¿No era XP la solución? ¿No era Scrum la solución?

Un vistazo atrás

Ya son unos cuantos años en este mundillo del desarrollo software. Unos cuantos proyectos, unas cuantas tecnologías, lenguajes y frameworks. También unas cuantas modas (y con ellas, las consabidas promesas incumplidas).

Este blog pretende recoger experiencias y conocimientos que he ido recabando estos años, relativos a la ingeniería del software, y a la calidad (tema en que últimamente estoy mucho más ligado).