Grimpi IT Blog

junio 11, 2011

La subjetividad en el desarrollo del software

Filed under: Arquitectura, Opinion — grimpi @ 11:08 pm

Muchas veces tenemos que decidir a la hora de desarrollar la arquitectura de una aplicación, que tecnología, que frameworks, que patrones vamos a utilizar. Muchas veces se generan discusiones en el grupo, porque uno quiere usar algún ORM y otro prefiere ADO.NET directo, o se generan peleas por si usar mocking o no, por alguna metodología sobre otra metodología, etc.
Todas estas discusiones se argumentan del lado técnico y racional. Uno intenta demostrar que el uso de un ORM es mejor por tal y tal motivo. Que este framework es más productivo que tal otro. Que este patrón es más prolijo o no y un largo etcétera.
Y es verdad que muchas veces, no cabe dudas, para escenarios específicos, una tecnología es mejor que la otra. Sin embargo, hay muchas situaciones, donde la elección de una determina forma de hacer software no se debe a un análisis racional de las opciones existentes, sino simplemente a un gusto. Gusto que se debe porque uno tiene más experiencia en esa tecnología, o todo lo contrario, porque no la conoce y le gusta jugar con cosas nuevas, o simplemente gusto porque sí.
Y ahí es donde voy. El elegir una arquitectura de desarrollo porque sí. Jamás, never de los never, un arquitecto, un programador, un líder técnico puede argumentar que es preferible usar una tecnología sobre porque simplemente le gusta más. La subjetividad en el mundo de desarrollo está terminantemente prohibida. Se supone que es una ciencia exacta y que por tal motivo, no podemos dar lugar a la irracionalidad. El sentido común epistemológico de un programador en general es bastante ingenuo en ese aspecto. Sin embargo, la subjetividad está presente en las ciencias exactas. Fue Thomas Kuhn en su tesis sobre los paradigmas y las revoluciones científicas, el primero en sostener que los elementos subjetivos tienen un papel fundamental en la elección entre teorías científicas rivales.
Muchas teorías científicas se imponen simplemente por consenso entre un panel de científicos influenciado por el contexto político e ideológico del momento.
Ejemplo: El feto es un ser humano? Y la realidad es que un científico ateo va a dar una respuesta y un científico católico, va a dar otra respuesta completamente distinta. Ambos argumentaran desde lo racional y técnico. Pero en el fondo, esto no es más que una manera de “racionalizar” una posición política.
Un intento de objetivar la subjetividad.

Y en el mundo de software pasa lo mismo. Acaso un “militante” del software libre diría que tecnológicamente, .NET es superior a Java? Muy difícil.
Muchos podrán sincerar su pensamiento político y decir que prefieren Java porque es open source y punto. Pero otros se enroscaran en una larga
“flame war” para demostrar que tienen razón.
Ahora que pasa cuando la elección de una tecnología ni siquiera obedece a una posición política visible? A nadie se le ocurriría decir que el uso store procedures sobre queries representa una postura ideológica… Y la realidad es que así como muchos prefieren a las rubias sobre las morochas o viceversa, muchos prefieren store procedures sobre querys.
Por supuesto como dije antes, para una determinada especificación funcional o restricción tecnológica, puede haber una clara y objetiva racionalidad en elegir un producto sobre el otro. Sin embargo, hay un universo de situaciones, donde la ventaja de la elección de una tecnología sobre otra es más difusa y ahí entra el conflicto. Ahí es donde se abre una ventana para la del tabú del programador inteligente, para lo que dificilmente pueda reconocer, para la subjetividad mas irracional posible: “el porque si”.

Y como se soluciona esto?
Mal que le pese a un peronista, la mejor opción para estos casos es el diálogo y consenso.

1 comentario »

  1. Este comentario escrito en Inglés, traducido por Google, a continuación, “arreglado un poco” por mí (pero no muy bien):

    Que desarrollo, dot Net y SQL Server, software corporativo para vender a los clientes (en Melbourne, Australia).

    Tengo sólo el número mínimo de almacenados procs, vistas y disparadores. La mayor acceso DB se realiza a través de consultas en código.

    Porque – flexibilidad. Puedo puerto que el software MySQL en un día. Oracle un poco más (bueno, una semana o más).

    El código de Net puede acceder a prácticamente cualquier base de datos. El código SQL sólo se puede acceder a bases de datos SQL Server.

    Puedo minimizar mi “lock-in” para SQL Server.

    Comentario por Roberto — agosto 17, 2014 @ 6:59 am


RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: