Barrapunto

En el kernel Linux, efectivamente, hay aportaciones de mucha gente, pero date cuenta de lo que pasó cuando se comprobó que "Linus Torvalds no es escalable": muchos parches (incluso correctamente escritos) se perdían incluso si se enviaban repetidamente. Esto llevó a la aparición de los "lugartenientes", Bitkeeper y git. Y el problema sigue sin estar resuelto. Yo opino que el problema 1 no es un problema de programación, sino de descripción: para poder "tareas de no más de 1 hora que puedan ser ejecutadas redundantemente por varios programadores geográficamente dispersos", como se pide en el artículo, es imprescindible tener una declaración sin ambigüedades de dichas tareas. No necesariamente de su implementación, pero sí de lo que se espera de la misma. Y probablemente hagan falta aún más cosas.

Cambiando de problema, no veo sentido al problema 3: no es un problema específico del modelo relacional (el modelo jerárquico o el modelo en red tienen los mismos problemas) y en la mayoría de SGBDs modernos hay soluciones parciales (como los trigger) bastante eficaces que no requieren estar haciendo el trabajo "a mano".

No sé que pensar del problema 4: ahora va a resultar que el sistema debe conocer todas las monedas del mundo. No, hijo, no. Las monedas que se gestionen en la base de datos estarán anotadas en algún sitio, con su cotización respecto a una moneda de referencia, y basta. ¿Cuántas aplicaciones requieren sumar euros y dólares y sacar el resultado en rublos? Que yo conozca, ninguna: lo que se hace es convertir las dos cantidades a rublos y se suman como tales, que para algo tenemos el punto flotante y/o la precisión arbitraria.

El problema 5, como ya se ha indicado, está resuelto con la reglas de integridad en cascada. Estoy de acuerdo con la conveniencia de tener mecanismos de baja, pero la variabilidad de este mismo concepto según necesidades (sí, se pueden considerar diferentes tipos de baja) dificulta sobremanera una solución general.

El problema 6 adolece de escasez de miras: ¿qué hacemos mañana cuando salga una alternativa a SQL o una revisión de XML? Es muy seductora la tentación de añadir características nuevas al lenguaje, pero esto hay que hacerlo como se ha hecho siempre, con librerías externas. Porque ¿qué versión de SQL metemos? ¿La de la norma? Ya podemos olvidarnos de los desarrolladores que quieren aprovechar (con razón o sin ella) características específicas de un SGBD (Oracle, Mysql, PostgreSQL, Firebird... todos tienen sus idiosincrasias).

De nuevo, el problema 8 busca generalizar algo que es excesivamente específico: ¿Manipular ficheros de texto? Yo pensaba que teníamos cosas como sed, awk o Perl [wikipedia.org], por citar tres opciones más o menos emparentadas. ¿Qué quiere decir "cambiar cosas en las bases de datos"? No sé si se refiere a actualizaciones en masa de registros, modificar las tablas, o qué, pero me da la impresión de que quiere un Haz Lo Que Quiero (y no lo que digo) [wikipedia.org].

Problema 9: si el problema son los modelos, no sirve demonizar a toda la documentación. Quizá al autor del artículo UML no le explica nada, o quizá es que no le han dado UML bien hecho. O BON o algún otro lenguaje/sistema de modelado. Una de las razones por las que los lenguajes de modelado no suelen ser capaces de representar bien la realidad es porque suelen tener reglas de representación, y la realidad no. Como dice la cita, "la realidad es más increíble que la ficción, porque la ficción tiene que tener sentido".

Como solución para el problema 10, soy partidario de la aplicación repetitiva del lart [wikipedia.org] ;-)

En mi opinión el problema 1 se resuelve con un buen análisis. El problema es que eso lo pueden realizar uno (máxime dos) analistas y lleva su tiempo. Para hacer un puente, dan ese tiempo (Nadie espera que el proyecto previo a la construcción este en menos de un año), pero para la informática, por algún motivo, no es así (Lo que enlaza con el 10).

Las escasas veces que he tenido el tiempo suficiente para hacer un análisis como dios manda, pudiendo hacer un DSI completo, no he tenido ningún problema en escalar el desarrollo en partes muy pequeñas (cosa que prefiero, soy partidario de usar clases muy pequeñas y autónomas).

El problema 5 me parece una chorrada. Con integridad referencial puedes dar de baja cosas *solo si realmente puedes*. De hecho, precisamente, es una de las cosas que mas ayuda al análisis, que con una buena integridad referencial el sistema te dice que puedes borrar y que puedes tan solo dar de baja.

Y los demás problemas los veo casi mas específicos de java, o pajas mentales del autor que, en sí, no representan ningún problema.