Siguiendo en la línea belcantista del post 150, hay una profesora de canto, Mathilde Marchesi, discípulo de Manuel García, a quien se atribuye la invención del laringoscopio, que ha marcado mi modo de pensar.
No es porque cante (lo hago horrorosamente mal ;-)) sino por que una vez, preguntada por cual de las escuelas de canto (italiana, francesa, alemana) seguía, ella contestó que sólo conocía dos escuelas: la de cantar bien y la de cantar mal.
Desgraciadamente, en todos los sectores, existen estas dos escuelas.
En el campo del desarrollo de aplicaciones informáticas, también.
Hace unos días tuve el privilegio de desayunar con varios profesionales de una de las empresas de servicios del sector, y, entre otras cosas, uno de ellos nos explicaba los sistemas automatizados de auditoría de calidad del código generado: número de iteraciones, nivel máximo de anidamiento de query, excepciones máximas permitidas...
Y el otro nos narraba sus desventuras al hacerse cargo de un sistema, ya entrado en años, donde en el transcurso de su ciclo de desarrollo, las auditorías de calidad habían brillado por su ausencia.
Este profesional, angustiado, nos relataba el caso de una rutina concreta con más de 10 páginas de excepciones, de un diseño de base de datos espeluznante, de una ventana para ejecutar queries pass-through con auto commit...
Probablemente esta situación es debida a que, durante mucho tiempo, se han dedicado a solucionar problemas con mucho esfuerzo y nula reflexión, y a que "las prisas son malas consejeras".
El esfuerzo que dedican a mantener semejante sistema es enorme, y las consecuencias del desarrollo de un sistema "apedazado", como el descrito, en producción, en caso de cambio o malfunción, incalculables.
Un bonito ejemplo de cómo no hacer las cosas.
No es porque cante (lo hago horrorosamente mal ;-)) sino por que una vez, preguntada por cual de las escuelas de canto (italiana, francesa, alemana) seguía, ella contestó que sólo conocía dos escuelas: la de cantar bien y la de cantar mal.
Desgraciadamente, en todos los sectores, existen estas dos escuelas.
En el campo del desarrollo de aplicaciones informáticas, también.
Hace unos días tuve el privilegio de desayunar con varios profesionales de una de las empresas de servicios del sector, y, entre otras cosas, uno de ellos nos explicaba los sistemas automatizados de auditoría de calidad del código generado: número de iteraciones, nivel máximo de anidamiento de query, excepciones máximas permitidas...
Y el otro nos narraba sus desventuras al hacerse cargo de un sistema, ya entrado en años, donde en el transcurso de su ciclo de desarrollo, las auditorías de calidad habían brillado por su ausencia.
Este profesional, angustiado, nos relataba el caso de una rutina concreta con más de 10 páginas de excepciones, de un diseño de base de datos espeluznante, de una ventana para ejecutar queries pass-through con auto commit...
Probablemente esta situación es debida a que, durante mucho tiempo, se han dedicado a solucionar problemas con mucho esfuerzo y nula reflexión, y a que "las prisas son malas consejeras".
El esfuerzo que dedican a mantener semejante sistema es enorme, y las consecuencias del desarrollo de un sistema "apedazado", como el descrito, en producción, en caso de cambio o malfunción, incalculables.
Un bonito ejemplo de cómo no hacer las cosas.
