The musings and ramblings of a software craftsman

No llevo mucho tiempo trabajando en proyectos de software de forma profesional, así que es probable que me equivoque o que mi experiencia no sea lo suficientemente amplia como para dar una opinión sólida, pero ahí va.

Lo cierto, es que hasta ahora he visto una serie de fallos fundamentales en casi todos los proyectos en los que he participado, y creo que en parte, se debe a la opinión generalizada por parte del empresariado Español, de que (simplificando) “Eso de la Informática lo hace cualquiera”, cuando en realidad se trata de un proceso de ingeniería, tal como construir un camino, o un edificio. A saber, los fallos son:

  1. Tomas de requisitos escasas o cuando menos, poco detalladas. No, 4 párrafos en un folio no son suficientes para que el cliente te diga lo que necesita que haga la aplicación. Eso da pié a que tengas un equipo de desarrolladores parado por falta de información, y a que el cliente incluya funcionalidades nuevas y cambios allá donde le de la gana y cuándo le de la gana. Si se queda en hacer X, se hace X, no X y aprovechando que el Duero pasa por Valladolid, me haces X + Y + Z y te pago lo mismo que solo por X.
  2. Inexistencia total de un sistema de pruebas estandarizado. Todavía no he visto usar en ningún proyecto frameworks de pruebas unitarias (p.ej: jUnit); la mayoría de las veces, las pruebas (y por ende la comprobación de la calidad del producto) se hacen al final del desarrollo y corriendo, lo que no suele dejar al cliente final muy contento, ya que le da la sensación de que consideras que su proyecto es algo de segunda categoría que no merece la misma atención al detalle que el resto.
  3. Escasa flexibilidad frente a cambios. Cada vez que el cliente solicita un cambio, este, tarda demasiado en aplicarse, provoca nuevos fallos en código que ya funcionaba y por norma general tiene demasiadas ramificaciones. No puede ser que cambiar un pequeño proceso de tu aplicación, requiera cambiar media docena de clases, 2 archivos de configuración y probar toda la aplicación de nuevo; eso no es eficiente.
  4. Fechas de entrega poco realistas. Aún estoy por presenciar, un proyecto entregado a tiempo. No se trata de vender como sea y en el tiempo que sea, España no puede competir en tiempo y costo, eso pueden hacerlo China o India, que tienen mano de obra cuasi esclava. España ha de competir en funcionalidad y calidad. ¿Qué prefieres vender, scooters o mercedes?.

Ahora mismo no se me ocurren más, pero si alguien quiere aportar, que mande un e-mail o comente.

It has not passed many time since I began working in IT projects professionally, which means that I may be wrong or simply that my experience it’s just “not enough” to be able to make a solid opinion, but here it goes.

The truth is that , until now, I have witnessed a series of fundamental errors in almost every project in which I have been involved, and I think that at least in part, the generalized opinion of the majority of the spanish enterprises that (simplifying) “anyone can do that thing of the IT” is to be blamed; because in fact, it is a true engineering process, like building a road or a house. Now for the errors:

  1. Sparse requirements gathering, or at least not enough detailed. No, four handwritten paragraphs do not suffice for the client to tell us what he wants the application to do. That gives cause for the development team to sit idle while waiting for needed information and, for the customer to ask for new functionalities and changes wherever and whenever they see it. If you agree on developing X, you  do X and not X + Y + Z by arguing that requirements have not yet been met.
  2. Nonexistent standardized testing method. I have yet to see a unit testing framework (like jUnit) used in a project; most of the time, testing (and as such, projects quality checking) is done in the end and on the run, which does not leave the customer very satisfied, mainly because he is left with the feeling that you take their application as a second class one and thus you are not putting the same attention to detail as you do with the rest.
  3. Little flexibility towards changes. Each time the customer asks for a change, this , needs a lot of time to be implemented, introduces errors in already working code and usually has too many ramifications. Modifying a small business procedure, should not trigger changes in half a dozen classes, two configuration files and testing the whole program again, that is simply not efficient.
  4. Unrealistic deadlines. I have not yet seen a project handed on time. Seriously, it is not about selling at any cost; Spain can not compete in time or budget; China and India can because their workforce is near enslavery. Spain must compete in quality and functionality. What do you want to sell? scooters or Mercedes?.

I can not think of more errors right now,  but if anybody wants to add something, just e-mail me or post a comment.


Comments on: "Ingeniería del Software en España (Software Engineering in Spain)" (2)

  1. Caballero, lo que pasa por Valladolid es el Pisuerga.

  2. Oh! This is so true! But how difficult it is to come up with detailed requirements set – is that even possible with the IT projects where every other one is new challenging and different from the previous ones (if not for world at leas for ur team). Testing is almost always left out till the very late… Clients is not replying as fast as he should, developers needs more time… 🙂 So why are we into it so much!? 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: