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.

junio 10, 2011

Como obtener un listado de todos los packages de SSIS deployados dentro de la base msdb

Filed under: SQL Server, SSIS — grimpi @ 2:16 pm

SELECT sl.name As Owner, ISNULL(spf2.foldername,) + ‘/’ + spf.foldername as SSIS_Folder, sp.Name AS SSIS_Name, Description as SSIS_Description, verbuild, packagetype
FROM msdb.dbo.sysssispackages sp
inner join msdb.dbo.sysssispackagefolders spf on spf.folderid = sp.folderid
inner join msdb.sys.syslogins sl on sl.sid = sp.ownersid
left join msdb.dbo.sysssispackagefolders spf2 on spf2.folderid = spf.parentfolderid
ORDER BY sp.name

Importante: Esta consulta funciona para todos los packages instalados dentro de la base msdb, pero no para los que fueron deployados como archivos!

Importante 2: Esta consulta solo funciona en SQL Server 2008 en adelante. La vista msdb.dbo.sysssispackages no existe en SQL Server 2005.

Crea un blog o un sitio web gratuitos con WordPress.com.