Chess - antoniomartel.com

Archivos de Categoría: Blog

Keep it Simple, Stupid

Recently, after a conversation with a professional colleague on the current IT world, something reminded me of a Andres Diplotti cartoon I saw first time in Google+:

As a programmer I have been for a long time, and partly still I am, acknowledge that I have had this kind of arrogance (without going to these extremes) I guess it is a sin of youth that has been mitigated with age and that some of us already had since college.
By that time I remember to have discovered the software design patterns book from The Gang of Four. Our applications began to fill with design patterns, the more you used the better, in a kind of competition won by the one who used the more complex and difficult pattern. I guess this helps me to understand the posts and articles I see now on refactoring to eliminate design patterns and the cost of all these changes in some projects.
Over the years I learned firsthand the KISS principle (Keep it Simple , Stupid) not only with patterns, but also when customizing graphical components on screen or with the ‘ghost requirement’, a name that I heard on a rise to a co-worker to refer to those features that nobody asked but one believes important to the customer and that ‘for sure’ he would end up needing.
Long ago, a project manager on a client told me that someone in another team had indicated that it was impossible to get the functionality he asked. I replied that practically everything could be achieved by investing the necessary time. I was not clear enough . I should have added, Is it reasonable to use all that time on that functionality? With almost any programming language one can send a rocket to the moon but do you really want to go to the moon or do you want a working application on time?

Keep it Simple, Stupid

Hace poco tiempo, después una conversación con un colega de profesión sobre el mundo IT actual, algo me recordó una viñeta de Andrés Diplotti que vi por primera vez en Google+:

Como programador que he sido durante mucho tiempo, y que en parte sigo siendo, reconozco haber tenido este tipo de soberbia (sin llegar a estos extremos) Supongo que un pecado de juventud que se ha ido mitigando con la edad y que algunos ya teníamos desde la universidad.
Por aquella época recuerdo haber descubierto los patrones de diseño software con el libro de The Gang of Four. Nuestras aplicaciones comenzaron a llenarse de patrones de diseño, cuantos más usabas mejor, en una especie de competición ganada por aquél que usaba el patrón más complejo y difícil de entender. Supongo que esto me ayuda a entender los posts y artículos que veo ahora sobre refactorizar para eliminar patrones de diseño y los costes que esto tiene en algunos proyectos.
Con los años he aprendido en carne propia el principio KISS (Keep it Simple, Stupid) no solo con los patrones, sino también con la personalización de los componentes gráficos que aparecen en pantalla o con los ‘requisitos fantasma’, denominación que oí en una ocasión a un compañero de trabajo para referirse a esas funcionalidades que nadie te ha pedido pero uno cree importante para el cliente y que ‘seguramente’ que él terminará necesitando.
Hace mucho tiempo, un director de proyecto en un cliente me comentó que alguien en otro equipo de trabajo le había indicado que era imposible conseguir la funcionalidad que él pedía. Le contesté que prácticamente todo podía conseguirse invirtiendo el tiempo necesario. No fui lo suficientemente claro. Debí haber añadido: ¿es razonable usar todo ese tiempo en ese funcionalidad?  Con casi cualquier lenguaje de programación uno puede enviar un cohete a la Luna pero ¿de verdad se quiere ir a la Luna o se quiere una aplicación terminada en el tiempo previsto?

Mi ponencia en las V Jornadas de Sostenibilidad

Hace unas semanas la Viceconsejería de Medio Ambiente del Gobierno de Canarias tuvo la amabilidad de invitarme a dar una ponencia en las V Jornadas de Sostenibilidad en Canarias que tuvieron lugar el pasado jueves 3 de octubre. Mi ponencia trató sobre el Sistema de Información de Residuos de Canarias y otros sistemas software que ayudan al Servicio de Residuos a controlar los residuos producidos en las islas. ¡Espero no haber aburrido mucho a los no versados en sistemas de información sobre residuos peligrosos!

Les dejo aquí un enlace a mi presentación del jueves

Las V Jornadas sobre Sostenibilidad en Canarias estaban presididas por la Viceconsejera de Medio Ambiente y tenían como lema los retos en la gestión de residuos en territorios insulares por lo que varios representantes de Cabo Verde asistieron para poder compartir experiencias sobre la gestión de residuos en ambos archipiélagos.
Las ponencias trataron sobre:

  • [Sal, una isla sin plástico] por una representante de la Cámara Municipal de la Isla de Sal en Cabo Verde.
  • [Modelos y plan de residuos en Cabo Verde] por D. Gilberto Silva, Concejal de Medio Ambiente de la Cámara Municipal de Praia.
  • [El Hierro 100% reciclable] por Dña. Fabiola Ávila, Técnico de Medio Ambiente del Cabildo de El Hierro.
  • [El impacto de los residuos en el Cambio Climático] por D. Fernando Herrera, Jefe del Servicio de Prevención y Control de la Contaminación del Gobierno de Canarias.
  • Buenas prácticas en la gestión de residuos a cargo de representantes del Grupo Lopesan y Martínez Cano Canarias.

Podrán encontrar toda la información y algunas fotos del evento en la siguiente dirección: Guacimara Medina inaugura en Las Palmas las V Jornadas de Sostenibilidad en Canarias.

Por último, les dejo un enlace a una entrada en este blog sobre una ponencia previa en las Jornadas sobre Sostenibilidad que tuvieron lugar el pasado mes junio: Gestión avanzada de residuos – Sistema de Información de residuos de Canarias (GUIRRE)

¿Qué significa ser ágil?

Debido a mi trabajo, por el blog o por lo que sea, estoy usando cada vez con más frecuencia muchas de esas palabras de moda como Ágil, Sprint, Historia de usuario, velocidad de la iteración o backlog del producto. He repasado algunas de mis entradas en este blog y lo veo lleno de expresiones un tanto huecas como ‘ser ágil’ o no serlo, aportar valor al producto o aceptar el cambio.

¿Qué significa realmente todo esto? ¿Qué es eso de ser ágil y por qué iba nadie a querer ser ágil? Esto de la agilidad es más una filosofía que un concepto claro y bien definido. Supongo que es una forma de ahorrar palabras y evitar tener que dar una definición completa de cada concepto cada vez que hablamos pero quien nos escuche debe estar pensando ¿qué diablos dice?

No sé si será suficiente pero quizás pueda aportar algo de luz utilizando la presentación de Henrik Kniberg en el Paris Scrum Gathering (échenle un vistazo, no tiene desperdicio) Pongo aquí un par de puntos que me parecen muy destacados:
Esta imagen de la torre Eiffel es bastante descriptiva por sí misma. Representa bien este balance entre el caos y la burocracia (exceso de documentación, formalismos o rigidez del contrato) Uno nunca se puede mantener un equilibrio perfecto, algunas veces te quemarás un poco y otras uno recibirá un pinchazo. Mientras se esté intentando no caer en la burocracia sin abrasarse mucho no iremos por muy mal camino.
Estas dos imágenes de arriba explican también de forma muy clara lo que significa ser ágil: ¿Alguien tiene una idea? Vamos a probarla, ¿son aburridas esas reuniones? ¿Probamos a quitarlas y vemos qué tal nos va?
Y por último, la idea que a mí más me gusta y la que, al mismo tiempo, me parece más divertida (aunque aún me falta para llegar a esto):

Ágil en todos los sentidos

Hace algunas semanas, una persona cercana a mí me pidió que le ayudara con la revisión de un trabajo académico que debía presentar a comienzos de septiembre.

Cuando le eché un vistazo, vi que había un gran trabajo hecho, se había leído muchísima documentación, notas y referencias a libros, artículos, ponencias y otra bibliografía estaban por todos lados y las hipótesis y las conclusiones eran claras. Sin embargo, aún era necesario dar cuerpo a todo el documento, revisar que se cumplían las normas de citación para cada elemento de la bibliografía y cumplir muchos otros aspectos.

Lo primero que hicimos fue tratar de saber qué quedaba por hacer para dar por concluido el trabajo. Elaboramos una lista de los puntos pendientes: revisión de citas, síntesis, abstract en inglés, palabras clave, relectura del documento para comprobar los errores gramaticales o de expresión, cumplir con los estilos de la institución académica, incluir mapas de localización, etc. Mucho por hacer y sólo quedaban unas semanas para entregar.

Después de preparada la lista, la priorizamos, colocando siempre en los primeros puestos aquellas tareas que eran imprescindibles para poder entregar el trabajo, seguidas luego de aquellas otras que sólo darían puntos extra o no eran imprescindibles para el aprobado.

Cuando la lista estaba avanzada nos dábamos cuenta de que necesitábamos añadir nuevos elementos a la lista. Preparábamos una nueva lista y volvíamos a priorizar siempre con la idea en mente de ‘Si tuviéramos que entregar mañana ¿qué tendríamos que tener hecho?’ A medida que íbamos eliminando elementos de la lista comprobábamos que las tareas eran cada vez de menor importancia y dificultad y la desesperanza del principio daba paso a las ganas de dar los últimos remates al trabajo.

Finalmente se completó el trabajo dos días antes de la fecha tope de entrega. El día anterior se dedicó a una última lectura y revisión entregándolo solo unas horas después.

Podemos llamarlo Ágil, GTD o simple sentido común pero ¡yo prefiero trabajar así!