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).
 |
| Agile 101 – Practical Project Management |
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.
