Ajedrez - antoniomartel.com

Archivos por Etiqueta: KISS

Keep it Simple from Agile 101 book

Some time ago, I had a conversation with an IT colleague, about the sector nowadays. Something reminded me of an Andrés Diplotti cartoon I’d seen on Google+. In it you could see a client reviewing the application that the programmer had delivered. The client says : “It’s all fine, but I don’t see a Cancel button”. The programmer replies: “I don’t program for cowards who cancel at the last minute.”
I’ve been a programmer for a long time. I’m still a programmer, in part. So I can recognize this kind of arrogance (maybe not to that extent). I suppose that it’s a sin of my youth, a brashness that’s been mellowing with age and that some of us already felt in college.
Back then I had just discovered software-design patterns in the book The Gang of Four. Our applications started to be filled with design patterns, the more the better. It looked like we were in some sort of contest. We had to see who used the most obscure, complex pattern —the one that would be the hardest to understand. With this in mind, I can understand the posts and articles I read now. They discuss refactoring old code to get rid of design patterns, and about how expensive it is for some projects.
As the years have gone by, I have suffered the KISS principle (Keep it Simple, Stupid) in my own flesh.  Not just with patterns, but also with the customization of on-screen graphic components. Or with “phantom requirements.” This is a term I once heard from a fellow worker. It refers to those features that no one has requested, but that you consider important for your clients. Things that “most probably” they’ll end up needing. It’s the malady known as featuritis. It makes us think that the more features or characteristics our app has, the more valuable the client will find it.
A long time ago, a client’s project manager commented that someone on another work team had told him that a feature he wanted was impossible. I told him that practically everything can be done, provided enough time is spent on it. I wasn’t clear enough. I should have added: but is it reasonable to use all that time for that feature? You can use practically any programming language to send a rocket to the Moon. But, do you really want to go to the Moon, or do you want a finished app by the deadline?
So, you are saying that my design is too complex?


You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

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?

Suscríbete