¡Buen artículo! Repecto al quinto problema, en Oracle (y en otros como MySql ahora que busco) existe hace tiempo la opción de crear una FOREIGN KEY en la creación de una tabla con “ON DELETE CACADE” que resulta en que al borrar una fila de la tabla Padre borra todos los registros de la tabla Hija. Es un TRIGGER encubierto, digo yo.

Hola , una vez mas Sergio Montoro Ten
Sacas articulos medulares
picantes y provocativos

y la verdad es esa que planteas la cual solo deja pie a una pregunta intersante ¿HASTA CUANDO?
si, eso, hasta cuando seguiremos complicandonos la vida cuando en la realidad necesitamos la sencillez para la creacion de nuestra labor diaria por eso !Hasta cuando seguiran aparenciendo modelos SUPER complicados! para la “solucion” de situaciones

tema aparte Joselu eso que mencionas de la integridad referencia y la eliminacion en cascada existe desde que tenia pelos y mira que haaaaaace mucho

Saludos, por cierto Sergio Montoro Ten hoy me imprimi el libro de El Principio de Peter al cual hace alusion en uno de tus articulos el de Minglanillas
a ver si me lo leo ya que me dejo algo por dentro a ver la forma en que lo abordan los autores

estaba desconectado desde hace tiempo ya que cambie mi residencia y pais , antes cuba ahora españa al fin junto a mi mujer y niños

Saludos para ti y para todos los que nos consideramos asiduos o no de tus articulos

Es curioso hasta qué punto es posible tener una visión distinta de un mismo trabajo. Supongo que nuestra experiencia ha sido radicalmente distinta. Me he encontrado alguno vez con cada uno de los puntos que citas y nunca han supuesto obstáculos insalvables. En cada caso aplicamos lo siguiente:

1. La ley de Deméter.
2. Poner sólo lo imprescindible en el cliente.
3. Ã?ndices por fecha.
4. Librería de procedimientos en base de datos.
5. Históricos.
6. Componentizar el acceso.
7. Disciplina y contratar profesionales capaces.
8. Hay herramientas a punta pala para eso.
9. La instrucción técnica.
10. Un buen jefe de proyecto.

No siempre tenemos todo a mano, claro :-)

Desarrollar la mayoría de los puntos daría para un libro, aunque para eso mejor leer el “Pragmatic Programmer”, donde vienen reflejadas varias recetas que vienen al caso.

Otro problema (quizá integrado en el 2):

11.- Paginación en web sin complicaciones (para todas las bbdd y para datasets grandes)

Antes me faltó poner cuáles son los problemas que a mí me salen.

10. Pues eso, que cuando no hay liderazgo, pasan todo tipo de cosas malas.

12. Falta de infraestructura: programas y equipos desactualizados, red no funcional, oficinas pequeñas, ruidosas o estar sujeto a interrupciones, no tener permisos de acceso redes, o no tener permisos en la propia máquina para instalaciones.
13. Burocracia: solucionar lo anterior pasa por una infranqueable barrera en la que todos se quitan el muerto de encima.
14. Falta de técnicas elementales de construcción: no se hace control de versiones, no hay librerías, no se sabe cómo instalar, probar o incluso compilar.
15. Y sin embargo sobra papeleo para aplacar al proceso de calidad.
16. Decisiones que tienen más que ver con sacar dinero a los clientes que con hacer un buen trabajo.

En general: se cuida mucho menos la calidad intrínseca de los programas que la externa, impuesta desde arriba por meros motivos de control. ¿Qué hay de la exigencia de trabajar con corbata en una oficina en la que nunca pone un pie ningún cliente?

La paginación nosotros la solucionamos con un wrapper propietario alrededor de un RecordSet, que tiene un método para saltar N filas.
Aunque la mayoría de las bases de datos tienen algún mecanismo para saltar N registros en una query SQL, el procedimiento es bastante chapucero, porque hay que re-lanzar la consulta SQL con el coste de ejecución que ello supone y, además, la BB.DD. no garantiza que los resultados sean coherentes al moverse, a menos que pongas un ORDER BY lo cual ralentiza aún más la operación.

Sobre las soluciones de Nico, a mi se suenan mucho a pico y pala. Claro que puedes meter todas las cantidades dinerarias como VARCHAR en la BB.DD. y luego escribir una función PL/SQL (o lo que sea) así como MONEY_ADD(‘34.5EUR’,‘22USD’)
Lo que yo me pregunto es porqué no puedes definir directamente en la BB.DD. una columna de tipo moneda y que sea la BB.DD. quien se encarge de las operaciones de conversión transparentemente.

En cuanto a la infraestructura, una de las cosas que se suele olvidar al inicio de un proyecto es un plan de recursos hardware comprometidos ¡y que no te los roben! porque es típico que a mitad del proyecto algún listillo hable con el jefe para intentarle convencer de que tu servidor de desarrollo lo necesita para alguna otra cosa más perentoria.

El tema de la burocracia merecería todo un artículo aparte. Porque si bien casi todo el mundo aboga siempre porque haya más papelitos de por medio, después nadie quiere firmar nunca ninguno de ellos.

3, 4 y 5 son de pico y pala (una vez, después ya lo tienes). 1, 9 y 10 son trucos del oficio de JP y el resto lo damos por hecho con Delphi. En Java he trabajado con bastante menos medios, pero no sé si es porque no los hay o porque la empresa pasa de comprarlos.

Ese problema de la paginación en web por ejemplo está “componentizado”.

Para la paginación web existen cuatro estrategias:

1.- Ejecución de la consulta completa y paginar sobre la lista resultante en memoria (cacheada entre peticiones), quizá en la sesión. bueno para pequeños ResultSets.
2.- Ejecución de la consulta completa almacenando temporalmente las claves de los resultados en una tabla con un código de búsqueda. ResultSets de tamaño moderado.
3.- Paginar sobre el ResultSet. Bueno si hay pocos usuarios y ojo con las transacciones.
4.- ejecutar la consulta en cada petición de paginación obteniendo sólo los resultados de la página requerida (Algunos RDBMS permiten optimizaciones tipo FIRST_ROWS y tal). Bueno para resultados de gran tamaño aunque hay que tener cuidado con lecturas inconsistentes (una actualización después de paginar).

Creo que esto está más que resuelto elegantemente, sólo hay que poner un poco de atención.

Por otro lado, interesante artículo que empieza bien y termina con estereotipos facilones como la documentación y lo de ‘el jefe es tonto’ o ‘como el chorizo de mi pueblo no hay nada igual’.

Para la documentación, sin entrar en temas de metodología (ver punto 1 del artículo) tienes el documento de requisitos con sus casos de uso, el documento de diseño y arquitectura con sus dibujos y explicaciones y el javadoc. Creo que par aun proyecto de hasta 12 meses es más que suficiente.

Saludos.

Yo creo que no son problemas tan insalvables, para la mayoría de ellos hay ya soluciones muy conocidas:

1) Programación distribuida. No creo que cualquier problema pueda resolverse de esta forma, pero la metodología que siguen para desarrollar el kernel de Linux es un buen ejemplo de algo grande, distribuido geográficamente, y con redundancias en su desarrollo (diferentes schedulers, gestores de energia, implementaciones de acpi, etc…). Luego llega alguien con autoridad y se queda con lo que más le conviene. Es como la programación distribuida con un “maestro” y varios “esclavos”... más o menos :P

2) Hay infinidad de frameworks de AJAX, muy buenos y con buen soporte de la comunidad. Un ejemplo es GWT (Google), que funciona como si fuera Java y desde el Eclipse. Es muy rápido hacer interfaces con eso. No creo que éste te deje tirado a medio plazo, pero si tienes dudas utiliza algo púramente opensource para asegurarte que el código sigue siendo mantenido (por ti mismo en el peor caso!)

3) Este problema es una chorrada. Añade a cada tabla un campo timestamp e inclúyelo en todas tus consultas en el where…

4) Este problema no tiene solución trivial y no creo que tenga sentido dársela, porque habría que mantener un histórico de las operaciones que te han llevado a obtener un determinado resultado en un registro. Ejemplo: hoy sumas 3€ + 1$ y el resultado depende del tipo de cambio de cada momento, por lo que mañana puede valer otra cosa… Creo que dar un resultado hoy hace que se pierda transparencia de cara al futuro si no mantienes ese histórico.

5) A mi me enseñaron en las clases de BBDD que habia algo asi como un DELETE CASCADE pero nunca me funcionó en Oracle ;-) ... nah, en serio, este sí es un problema interesante … pero no veo diferencia entre permitir el borrado lógico (saltándose la integridad referencial) o directamente… ¡deshabilitar estas restricciones! ... a todos los efectos sería lo mismo no?

6) El SQL embebido existe para la mayoría de los lenguajes desde hace muuuuchos años. Yo lo uso todos los días (Pro*C) y no es nada novedoso. Para Java también hay SQL embebido, el usar JDBC es una decisión del programador para conseguir más flexibilidad, pero nadie le obliga a usarlo. El tema de empotrar XML dentro del lenguaje… ¿qué quieres decir exactamente? Para parsear XML hay librerías y clases muy sencillitas, que con un par de llamadas te resuelven problemas de lo más variado.

7) Hay muy buenas librerías para detectar errores de alocación de memoria. Alguna de ellas se puede linkar directamente a tu programa para asegurarte que esos errores son controlados en el momento (electric fence, memcheck, etc…) produciendo una excepción controlada.

8) Para mis tareas cotidianas uso la herramienta más potente para manipular ficheros de texto / cambios en base de datos… ¡shell scripting! tienes para elegir: bash, awk, perl… todas ellas son soluciones que vienen del mundo de Unix, pero que se pueden usar sin problemas en Windows… Si quieres hacer scripts rápidos que trabajen con texto y alteren una base de datos, Perl es para ti.

9) El principal problema de documentar un modelo subyacente, es cuando no hay modelo alguno. Hay muchos programas sin diseño que han crecido según lo han ido manteniendo cientos de manos diferentes… creo que a lo más que se puede aspirar en este caso es a algo tipo javadoc o un análisis (traza) de la ejecución del mismo para ver su estructura interna…

10) Supongo que “el de arriba” olvida fácilmente sus comienzos… pero no pondría la mano en el fuego porque a todos nos puede pasar!

Sergio creo que es valido tu punto de vista, pero estoy mas de acuerdo con Nico y AlienMind.

Saludos, interesante blog.

Creo que un problema también (más importante que algunos de los mostrados) es el uso de Unicode. char * ya no es suficiente por estos días.

Un algoritmo funciona y ya!! el programador se va tan pancho a hacer otras labores, olvida optimizar y la respuesta es: compre mejor CPU y mas memoria.

Las generaciones de programadores pasadas que trabajaban con DOS y tenían esa limitante de los 640Kb o menos porque el DOS + Antivirus residente (TSR) dejaban menos de 500Kb haciamos maravillas optimizando cada registro, cada uso de variable y los programas eran de poco consumo y rápidos. Hoy veo programadores novatos que hacen programas devoradores de recursos e implementan herejías como:

1. Control de ciclos con variables tipo float o double (deben usar variables tipo int).

2. Uso del char en algunas variables (use fanáticamente int porque son nativas del procesador).

3. El manejo de estructuras de datos como arboles, listas, pilas, etc.. con las APIs mas abstractas y estratosféricas que encuentran con la pobre excusa de que así abstraen el problema cuando en realidad esconden el “ser tontos ignorantes que les da miedo usar directamente las estructuras”. Obteniendo código muy lento.

4. Hiperabuso de funciones, he visto funciones que se usan solo una vez con dos líneas de código, ¿por que no la colocaron directamente en el grueso del código?

5. Funciones recursivas: el pecado original de la programación… ¿no saben que este tipo de programación consume demasiados recursos y es lenta?

6. Usar el lenguaje de moda o el que solo aprendieron en la Universidad sin importar que es mas lento que funcionario público.

7. La falsa autocomplacencia de “si señor cliente, el programa es muy lento pero es muy seguro, es poderoso, es flexible, es escalable, ...” y con las palabritas: “poderoso”, “flexible”, “escalable” disculpan un código mas lento que placa tectónica en movimiento…. y lo peor es que lo “poderoso”, “flexible” y “escalable” jamás lo volverán a usar.

8. El “safe code” significa que “un hilo estará supervisando que el estúpido programador no haya cometido idioteces en manejo de punteros y manejo de memoria que bloqueen la aplicación avisándole donde cometió errores, pero este hilo y esa forma de protección traga recursos y hace el programa mas lento que la entrega de ayudas humanitarias en Africa”, claro que suena mas guay “safe code”.

9. No consultar practicas de optimización o mejorar el código en velocidad.

La verdad es que no creo que estés en condiciones de enumerar estos problemas. Alguien que piensa que “ya teníamos VisualBASIC 4.0 con el cual te picabas una aplicación operativa en 3 días” como el fin de la historia y que menciona UltraEdit como LA alternativa para editar código de marcas… Lo cierto es que te pareces bastante al “de arriba” del punto 10 más que a un programador experimentado.

Respuesta al #12 (Otros problemas):

en la universidad mi dijeron algo que a lo largo de los años descubrí que es una verdad como un templo, la optimización debe hacerse en la idea, no en el código (está claro que si el código es un horror la cosa no irá ni para atrás, pero no hablo de eso).

Cuando se habla de desarrollar software, el tema se puede abordar desde varias perspectivas, ahora se me ocurren dos:

- Desarrollar software como profesión, bien seas programador, diseñador, analista, jefe de proyecto… En este caso, a parte de todo lo ya comentado arriba, yo destacaría aspectos como la reutilización de código y el aprovechamiento del tiempo en los puntos identificados como críticos ya que perder el tiempo supone perder una oportunidad de negocio (para que desarrollar y probar un algoritmo de ordenación supereficaz, cuando la api de nuestro entorno de desarrollo nos proporciona uno lo suficientemente rápido para cumplir los requerimientos del cliente… no reinventemos la rueda).

- Desarrollar sofware como entusiasta o investigación… aquí nos debemos romper los cuernos, reinventar la rueda y hacerla cuadrada si es necesario y sobre todo divertirnos (almenos a los que nos apasiona este mundo).

Se me quedan muchas cosas por decir y también me gustaría contestar a algunas de las opiniones expresadas arriba, pero no me quiero enrollar mas de la cuenta…

salu2

Sobre SQL en el Lenguaje echale un vistazo a LinQ de Microsoft, disponible con el .NET Framework 3.5

En respuesta a #12

Parece que tu posición es la de “Los hombres de pelo
en pecho que programabamos en DOS sí que sabíamos, los
niñatos de hoy que programais en Java no teneis ni idea
y malgastais recursos.”

Bueno, sólo comentarte que una máquina nueva, con recursos por un
tubo vale 2000€ más o menos, en España. Y que la hora de
consultor se paga de tal manera (no digo que el consultor vea
ni un 10% de eso, sólo digo que al cliente le cuesta eso)
que en día y medio te has pulido los 2000€. Ahora dime, qué
es mejor, que el consultor esté poco y use hashtables y
árboles B+ ya implementados o que se los pique él a pelo.

Además, existen otras dos razones más “filosóficas” y menos
“económicas” para no optimizar como tú dices:

1a Si te dedicas a implementar algo que ya está implementado
por un equipo (es decir, muchos más ojos de los que tu tienes,
y muchas más horas de las que tú podrás emplear en el desarrollo
de lo mismo), lo más probable es que lo hagas peor que
la implementación de esos otros. Te aseguro que las tablas
de Hash de Java difícilmente las vas a mejorar en rendimiento
implementándotelas tú, ya se ha encargado Sun de refinarlas
al máximo. Además, puedes introducir una cantidad de bugs
que la implementación “estratosférica” de la que hablas, ya
ha corregido antes.

2a Mantenimiento. Como desarrollador prefiero encontrarme un
código que, escrito en Java, C o Perl sea prácticamente igual,
que encontrarme con el típico código super optimizado que
usa suposiciones como que los enteros en arquitectura ultra Sparc
de segunda generación son de 16 bits big endian. Por qué? Por
que ese código me puede resultar muy difícil de interpretar
y de modificar. Por otro lado, si me das código estándar, no
optimizado, me dará igual el lenguaje, te lo modifico, siguiendo
la misma filosofía en un plis plas y acabo el trabajo más
rápido. El mantenimiento de código de otros es un infierno
siempre, pero si esos otros son los mega frikis de la
optimización, pongamos como ejemplo, en Perl, puedes
acabar encontrándote un programa mega rápido totalmente ininteligible, que, su código mirado desde cierta distancia
parezca el Drago milenario de Gran Canaria ( y este ejemplo
no es ninguna exageración, existe). Con este último código,
el mantenimiento será tan jodido que preferirás estar en el
infierno de verdad.

Se me ocurren muchas más razones para no ir de “hombre de
pelo en pecho” programando, y todas ellas me llevan a lo
mismo: trabajaré menos, introduciré menos errores en el código,
y podré hacer programas más grandes con menos esfuerzo.
O sino, ponte a programar el “eclipse” en código binario
de cada una de las arquitecturas en las que se puede ejecutar,
y dentro de un mes me cuentas las sensaciones que tienes al
respecto y el progreso que has conseguido.

Punteros nulos e índices fuera de rango… je je, eso les pasaba a los que usaban lenguajes que no imlementaban controles. Pero cuando se empesó a usar freepascal extensivamente esos problemas desaparecieron. Con un lenguaje tan potente y rápido como C, que genera binarios tan chicos que ni siquiera haría falta usar linkeo dinámico, y a demás que se encarga de controlar los punteros internamente y hasta provee la posibilidad de compilarlo con control de rangos para detectar desbordamientos muy fácilmente, ¿quién se preocupa?

Ejem… ah, no, cierto que los programadores de C se niegan a usar Pascal porque no lo conocen, de la misma manera que los usuarios de windows se niegan a probar linux.

sinceramente… exceptuando una o dos de las opciones el resto me parece que son planteamientos bastante torpes e incocentes, ya que existen multitud de problemas inherentes a la creación de un sistema de información que están muy por encima de los que planteas…

Muy buen artículo, actualmente en referencia a SQL integrado al lenguaje de programación solo he visto C Omega, una versión pre-alpha de Microsoft donde se busca integrar C# con SQL.
En cuanto a la paginación automática (si no mal entiendo a extraer información) existe una herramienta propietaria llamada IT Pilot que se encarga de automatización web, y para construir aplicaciones de transacciones contra bases de datos, existen herramientas de automatización de código una es GeneXus que permite generar aplicaciones en: Java, Visual Basic.NET, C#, COBOL, ASP.NET, VisualFox Pro. También crea la base de datos necesaria para la aplicación en los siguientes DBM : Oracle, DB2, Informix, Microsoft SQL Server, PostgreSQL, MySQL.
Una aplicación similar es CodeCharge Studio que genera aplicaciones web en : Java, .NET, ASP, PHP, ColdFusion y Perl.
Esas son algunas de las soluciones que se me ocurren a los diarios dolores de cabeza. Si bien no nos brindan toda la flexibilidad que nos puede brindar un lenguaje, nos brindan máxima productividad, lo que significa un dolor de cabeza en un corto tiempo. De todas formas, a veces con lograr los trabajos no nos interesa la flexibilidad sino el logro en sí mismo, porque si nos interesase la flexibilidad, estaríamos programando en Assembler…

Totalmente de acuerdo con el comentario #18 con respecto a que no hay que primar la optimización frente a otros puntos. Siempre hay que pensar en el mantenimiento posterior de los proyectos que se desarrollan y sus posibles migraciones a otras plataformas.

Para el comentario #12, cada desarrollador debería conocer bien el lenguaje con el que programa y utilizar aquellas optimizaciones sobre dicho lenguaje. Comentabas usar “int” en lugar de “char”; en Java, por ejemplo, utilizar ArrayList o HashMap en lugar de Vector o Hashtable.. eso lo da el conocimiento y no es necesario complicarse la vida reimplementando cosas que ya están hechas.

Habrá determinados proyectos / desarrollos en los cuales sí tengas que estrujarte el coco para optimizar el código (sistemas en tiempo real, SS.OO.,...) y que serán dependientes de la plataforma pero, en la mayoría de las ocasiones, con lo disponible es suficiente y puede implicar mayor rapidez en el desarrollo y mejor mantenibilidad.

es increible tus opiniones

Problema 2. Si un retroceso, pero al punto donde se tenian que tener codigos depurados y con bajo impacto en la maquina, sin necesidad de librerias al por mayor que para correr un boton y el famoso “Hola Mundo!” necesiten una Pentium 4, trabajando a todo cañon!

Problema Nº7: Punteros nulos e índices fuera de rango.

Este es un problema casi tan antiguo como la informática, y de hecho ya hay soluciones satisfactorias. Yo me dedico a los sistemas empotrados, y te aseguro que en un sistema safety-critical (sistema médico, aviónica…) nadie se puede permitir un puntero nulo.

El lenguaje de programación de Ada lo utilizamos muchísimo en este tipo de sistemas precisamente por eso, porque muchas veces el compilador detecta ambos problemas en tiempo de compilación. Cuando no es posible detectarlo de forma estática, saltará una excepción como en Java (que se inspiró en Ada para hacer esto), pero por la propia naturaleza de Java muy pocas veces se puede detectar en tiempo de compilación y siempre hay que estar generando comprobaciones dinámicas.

Aparte de los que nos encargamos de programar sistemas críticos, he oído que ya hay ISV que están volviendo a Ada por este tipo de ventajas pero que lo mantienen en secreto como ventaja competitiva. Seguro que tiene que ver por este tipo de soluciones.

Un saludo

tocayo
muy buen articulo
felicidades

Al #12, amigo la velocidad no lo es todo, de hecho esa fijación que tienes de que todo debe ser ultraoptimizado, espero que tu lenguaje de programación sea ensamblador, en cuyo caso no hay nada de esas “estupideces” de char, float, etc. Lo que hay son bytes, registros enteros y de punto flotante, lo que dices es sencillamente tonto.

Hay lenguajes sumamente seguros y cuyo rendimiento es solo 50% del de C, te recomiendo que verifiques OCaml, SBCl (Lisp), GambitC (Scheme), y bueno hay cosas como Stalin (compilador de Scheme a C), cuyos programas corren más rápido que los equivalentes hechos a manos en C, sin punteros, sin errores de rango en los arreglos y con manejo de memoria automática.

Toda esta discusión se basa en una falta de conocimiento notable en la que se asume que solo existen tecnologías como Java/.Net y Oracle, algunos de los problemas del artículo original se pueden resolver con facilidad utilizando el modelo Objeto-Relacional de PostgreSQL en vez de bases de datos mas limitadas, o mejores lenguajes que tienen bibliotecas que manejan las cosas de manera muy natural como Perl.

Ahora si quieren todo en un solo lenguaje, pueden usar Scheme con SXML (XML integrado con Scheme con sintaxis de Scheme: http://okmij.org/ftp/Scheme/SXML.html) y Scheme-PG (SQL integrado en Scheme, con sintáxis de Scheme: http://planet.plt-scheme.org/package-source/sweeney/sqlid-helper.plt/1/0/htmldocs/scheme-pg.html), ahora solo usan un lenguaje para todo.

100 % 100 de acuerdo con tus planteamientos.

Tengo un poquito de experiencia en lo que comentas y me hacen cierta gracia algunos comentarios supertécnicos que aqui se apuntan.

Señores, donde vamos, nos empeñamos en ir hacia atrás con una y mil siglas y conceptos de escaso valor. De hecho cada 5 años mas o menos se renuevan en su totalidad.

Pero todo o mejor dicho casi todo, sigue funcionando como los modelos relacionales de hace 30 años, cuando integrar web con una base de datos sigue siendo engorroso, cuando un programador todavía se tiene que preocupar de la integridad de una base de datos o la integridad referencial de los borrados.

¿Que demonios? La revolución a este mundo tiene que llegar tarde o temprano. Soy informatico de formación, pero cada vez aborrezco mas el galimatias tecnico en que nos queremos envolver. EN cualquier otro sector esto sería de locos, me imagino con nuestros coches y la caja de herramientas a mano para hacer ajustes cada vez.

Para ciertos montajes, evidentemente haran falta productos especificos, pero para desarrollar un erp, un control de produccion, o cualquier otro software, con 200 o 300 usuarios, pasarela web, etc es decir lo normal es increible que no exista un producto de desarrollo, que me despreocupe de optimizaciones, etc.

Para desarrollar lo que miles de usuarios en este mundo, ya han desarrollado una y mil veces, no creo que haga falta mucha tecnica, sino herramientas y productos que lo faciliten y sin demasiados requerimientos tecnicos. A fin de cuenta en informatica las soluciones se repiten hasta la saciedad y lo que es peor, la mayoria van MAL, hasta que pasan dos o tres años de problemas y entonces vuelta a cambiar.

Afortunadamente empiezan a aparecer herramientas en la linea que comentas y cada vez seran más.

Conozco por lo menos un producto , y supongo que habra otros muchos, pero yo los desconozco, que ya se estan planteando este tipo de problemas y los conceptos relacionales. Hacer practica y rentable el desarrollo del Soft como único objetivo.

En cuanto al primer punto, no es posible mientras seamos medio monos, XD.
Las discusiones, las trabas, los manejos del asunto por convicciones mas que por eficiencia, seguirán reinando por mucho tiempo.
Pero yo creo que aún así, el desarrollo más eficiente se va a dar de forma colaborativa, ....es más, creo que es la única manera de que el desarrollo sea eficiente.