Cacheitis: otra enfermedad común del desarrollo software

Hoy hablamos de otra enfermedad habitual en el mundo del desarrollo software. Relacionada con las enfermedades "arquitectónicas", está especialmente relacionado con desvaríos de los arquitectos de software a la hora de implantar soluciones que por su ineficiente diseño, producen un mal rendimiento. Entonces la definición de Cacheitis vendría a ser algo así: "desorden transitorio del arquitecto o diseñador de software por el cual el uso inadecuado de la caché provoca como resultado una solución ineficiente".

¿Y cuál es la primera solución que se les ocurre? Sí señoooor: más caché. Caché por todos lados. Vamos a cachear todo lo cacheable.

En otras ocasiones, es al reves. Se parte con un exceso de caché desde el inicio del diseño, y esto deriva en un mal rendimiento. Para solucionarlo: como no...más caché.

Rodrigo corral en su blog ya hablaba de este problema, y aporta algunas buenas prácticas:

• Asume que no puedes cachearlo todo. Esto es viejísimo: ya es harto conocido por ejemplo, que en el mundo de las bases de datos es absurdo tratar de indexar todo en la búsqueda del rendimiento. Pues esa mala práctica, la cacheitis la extiende al uso de la cache.
• El cacheo temprano no es bueno. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. De nuevo, podemos establecer la comparación con el uso excesivo de índices en las bases de datos.
• Tener en cuenta las otras cachés. Hay que recordar que existen muchos niveles de caché. El motor de base de datos, el servidor web, ADO.Net, etc, etc.
• Una colección estática o global no es una caché: los desarrolladores noveles, y a veces los no tan noveles, utilizan datos estáticos o globales para simular el uso de la caché. Por desgracia, esto es una burda imitación de las múltiples características que deben incluirse en un mecanismo de caché como: acceso frecuente a los datos, políticas de refresco e invalidación, liberación de recursos de uso infrecuente, etc.

¿Qué es lo que hay que hacer? Pues recordar que somos ingenieros, y tratar de aplicar el sentido común (por desgracia, no el más común de los sentidos hoy día). Para ello, hay que relajar el usar la caché en las etapas tempranas del proyecto, y dejar para las etapas de optimización un uso combinado e inteligente de:

• Optimización mediante caché
• Optimización del acceso a datos mediante índices, su propia caché, vistas, datos calculados, etc.
• Minimizar los accesos a servicios web, WCF, y a otras capas de la aplicación, de forma que las operaciones no hagan "excesivos viajes" para obtener la misma información.

De hecho, al final, no es sino hacer uso de los más básicos principios ágiles: simplicidad desde el diseño.

5 malas prácticas en la oficina

Bueno, hoy el titular es la metáfora del auténtico titular que ha inspirado este post: "The stupid things you do at work (and how to fix them)"

En este artículo, hace una magnífica reflexión de acciones que solemos llevar a cabo y son improductivas o contraproducentes. Me ha hecho gracia por dos motivos:

• Vuelve a sacar el tema de la procrastinación en el trabajo. ¿Que no sabes lo que es?. ¿Es que no lees este blog? ;)
• El otro motivo es que para ejemplizar la procrastinación, hace referencia a un refrán:

"y como dice el refrán español: mañana probablemente es el día más ocupado de la semana". Anónimo.

Soberbio. Sin palabras. En fin, al grano. Vamos a ver resumidas, las 5 malas prácticas en la oficina:

1. Ponernos nerviosos. Cuando nos enfrentamos a tareas grandes, con alto riesgo, que nunca antes hemos hecho, o para las que no nos vemos preparados, suele ocurrar esto.
2. Aferrarse a nuestras ideas y métodos, aunque estén mal. Hemos de aceptar que nuestros métodos o ideas no han de ser siempre los mejores. Punto. Quien lo confunde con ofrecer seguridad, tiene un grave problema. La seguridad consiste en poner los medios y medir los riesgos, para que podamos ofrecer la solución más adecuada al contexto.
3. Procrastinar en lugar de hacer las cosas. El no afrontar las tareas inmediatas, y relegarlas en favor de lo que nos gusta más, o nos hace sentir más seguros, es un problema.
4. Creerte mejor de lo que realmente eres. Tenemos una tendencia exagerada a ignorar nuestros fallos y hacer públicos nuestros éxitos. Es un mecanismo de conservación innato en nuestra especie. El miedo a qué dirán. La verguenza pública. Todo esto realmente nos limita y nos hace comportarnos muy por debajo de nuestras posibilidades. Nuestro rendimiento profesional y la calidad de nuestro trabajo, se ven afectados en consecuencia.
5. Traer tu orgullo a la oficina. A la hora de negociar, mucha gente cuando obtiene un beneficio muy pequeño de la negociación, hace gala de su orgullo y prefiere no llevarse nada. Si pensamos con pura lógica, no tendría sentido este resutado. Sin embargo, la realidad nos hace ver cuán afectado puede verse nuestro comportamiento si nuestro orgullo hace acto de presencia.

Gestión de Proyectos Ágil

Se ha publicado recientemente el documento "Agile Project Management", que podéis descargar aquí.

El documento, resultado de la colaboración entre APMG-International y el consorcio DSDM, presenta un enfoque innovador en la gestión de proyectos. Ojo, no confundir con la gestión de equipos, que es el alcance que tienen muchas metodologías ágiles como SCRUM.