¿Cuál es un buen ejemplo de una idea o técnica de desarrollo de software que fue un fracaso?

Específicamente, ¿cuáles son algunos ejemplos de dónde las ideas de las masas estaban mal? ¿Por qué la gente se aferró a las ideas en primer lugar? ¿Y por qué se descartaron las ideas? O tal vez las ideas todavía están vivas y bien y, de ser así, ¿por qué?

Por ejemplo, podría describir CORBA (y otras tecnologías similares) como algo que intentó resolver el problema de la comunicación entre los componentes del software. Muchos consideraron que era necesario definir contratos entre varios componentes. Finalmente, HTTP + JSON resolvió el problema para las masas y han aparecido otros diversos mecanismos RPC como Thrift y Proto-bufs.

Básicamente, al igual que en el mundo fuera de las computadoras, las ideas y las tecnologías compiten por la atención, el apalancamiento, etc. Algunos ganan, otros pierden; y algunos pueden parecer The Winner por algún tiempo, luego se desvanecen en la oscuridad con el advenimiento de The Next Big Thing. Puede o no tener algo que ver con lo que en realidad fue mejor. Testigo VHS vs Betamax, o la guerra más reciente entre los diversos formatos de DVD.

CORBA era enorme, incómodo y difícil de usar, pero era lo mejor que algunas personas podían inventar en ese momento (tenga en cuenta que fue diseñado antes de que la World Wide Web - y HTTP, Java, XML, ... - se hicieran ampliamente conocidos). Y también fue un ejemplo clásico de diseño por comité , donde se amontonan en cada idea para satisfacer a todos, al final haciéndola hinchada inútilmente (al menos visto por los ojos de hoy). Sin mencionar su precio, que con el advenimiento de FOSS pronto se volvió prohibitivo.

Finalmente, HTTP + JSON resolvió el problema para las masas

Al menos para alguien que no ha visto un par de "soluciones finales" similares subir y finalmente caer ... Es bueno tener en cuenta que hubo un sentimiento similar sobre CORBA en su momento ;-)

Siento que es apto para citar The Rise and Fall of CORBA :

La historia de CORBA es una que la industria de la computación ha visto muchas veces, y parece probable que los esfuerzos actuales de middleware, específicamente los servicios web, recrearán una historia similar. [...]

En general, el proceso de adopción de tecnología de OMG debe verse como la razón principal del declive de CORBA. El proceso fomenta el diseño por comités y maniobras políticas hasta el punto en que es difícil lograr la mediocridad técnica, y mucho menos la excelencia técnica. Además, la adición de características desunidas conduce a una erosión gradual de la visión arquitectónica. [...]

Un proceso democrático como el OMG's es excepcionalmente inadecuado para crear un buen software. A pesar de los problemas de procedimiento conocidos, sin embargo, la industria prefiere depender de grandes consorcios para producir tecnología. Los servicios web, la bala de plata actual del middleware, utilizan un proceso muy similar al de los OMG y, según muchos informes, también sufren luchas internas, fragmentación, falta de coherencia arquitectónica, diseño por comité e hinchazón de características. Parece inevitable que los servicios web promulguen una historia bastante similar a la de CORBA.

Ahora desde un ángulo diferente: al leer su término "ideas de las masas", pensé en cosas muy diferentes que CORBA u otros estándares; Estos son típicamente la idea de una persona o un grupo pequeño. Pensé en prácticas / puntos de vista notorios como "codificación de vaquero", "codificar y orar", "funciona en mi máquina", etc. Estas son, en mi humilde opinión, "ideas de las masas", ya que esta es la forma en que casi cualquier principiante El desarrollador comienza instintivamente a escribir código. Y están equivocados, ya que no se escalan ni en el espacio ni en el tiempo; de esta manera no se pueden crear programas grandes, mantenibles y extensibles. Sin embargo, siento que desafortunadamente sigue siendo la norma, más que la excepción, que las personas intenten trabajar de esta manera en tiendas profesionales en todo el mundo.

El otro extremo de esto son las ideas de muchos gerentes y teóricos sobre el "enfoque correcto" para el desarrollo de SW, que se manifiesta en metodologías big-M como CMM, RUP, Waterfall, etc. La idea detrás de todo esto es que todo lo que necesita es el proceso correcto, y comenzará a producir automáticamente software de calidad de manera determinista, independientemente de quiénes sean realmente los desarrolladores. Tenga en cuenta que el mismo juego también se puede jugar usando métodos ágiles: es solo un cambio de etiquetas. Cualquier gerente que crea que seleccionar (y mantener) a los miembros correctos para su equipo de desarrollo es menos importante que el proceso de desarrollo, seguramente fracasará, sea cual sea el proceso. Sin embargo, esta creencia en el Proceso todavía parece prevalecer, ¿tal vez todavía se enseña en las escuelas de administración?

Un ejemplo frecuente de personas que salieron mal es el modelo de cascada. Este es un diagrama del modelo de cascada estereotípica, que también aparece en el documento de Winston Royce "Gestión del desarrollo de grandes sistemas de software" .

Esta imagen es seguida por este texto:

Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso ... La fase de prueba que ocurre al final del ciclo de desarrollo es el primer evento para el cual el tiempo, el almacenamiento, la entrada / salida, las transferencias, etc. son experiencias distinguidas de las analizadas. Estos fenómenos no son precisamente analizables. No son las soluciones a las ecuaciones diferenciales parciales estándar de la física matemática, por ejemplo. Sin embargo, si estos fenómenos no satisfacen las diversas restricciones externas, entonces se requiere un rediseño importante. Un simple parche octal o rehacer algún código aislado no solucionará este tipo de dificultades. Es probable que los cambios de diseño requeridos sean tan perjudiciales que se violen los requisitos de software en los que se basa el diseño y que proporciona la justificación de todo. Se deben modificar los requisitos o se requiere un cambio sustancial en el diseño. En efecto, el proceso de desarrollo ha regresado al origen y uno puede esperar un exceso del 100 por ciento en el cronograma y / o los costos.

Más adelante en el documento, Royce presenta modelos de procesos alternativos que implican iterar entre la fase actual y la fase anterior y un ciclo entre el diseño de análisis de requisitos y otro ciclo entre la prueba de código de diseño. También identifica una serie de documentos y durante qué fases deben completarse, y aboga por la participación del cliente y las múltiples cascadas dentro de cada fase para incluir el análisis, las pruebas y el uso de todos los artefactos involucrados. En realidad, lo que discute Royce podría considerarse un enfoque temprano de los métodos ágiles, aunque todavía está muy basado en el plan, pero es una base para el movimiento ágil.

No sé por qué la gente se aferró a la primera cascada. Supongo que les gusta asumir riesgos e invitar al fracaso.

Generación automática de código desde un nivel de abstracción más alto, o programación automática .

El artículo de Wikipedia carece de información histórica, pero esto ha sido un sueño para los gerentes desde que los programadores se volvieron más caros que las computadoras.

Después del desarrollo de idiomas de nivel superior como Fortran y Cobol, surgió el desarrollo de idiomas para dominios especiales como la redacción de informes. Easytrieve y SAS fueron un par de ejemplos.

Durante la década de 1980, las herramientas CASE estaban de moda. CASE significa ingeniería de software asistida por computadora. Se pensó que la aplicación rigurosa de los principios de ingeniería aceleraría el desarrollo de software. La razón principal por la que estas herramientas no se dieron cuenta, además del gasto, fue el alto nivel de estandarización de datos requerido para que las herramientas funcionen de manera efectiva.

Internet se hizo prominente en la década de 1990. Los tipos de programación que facilitó Internet explotaron. Se requirió que los programadores manejaran ilustraciones, mapas, fotografías y otras imágenes, además de animaciones simples, a un ritmo nunca antes visto, con pocos métodos bien conocidos. El número de tecnologías para producir estos objetos se multiplicó. Los sueños de programación automática se desvanecieron.

La programación de outsourcing a ubicaciones más baratas es uno de los pocos métodos que quedan para reducir los costos del programador. Los problemas con la contratación externa incluyen problemas de comunicación y problemas de especificación.

Métodos formales

Érase una vez, se propuso que el software podría probarse correcto. (La idea es que las pruebas no pueden mostrar que no hay errores, pero las pruebas podrían hacerlo). Desafortunadamente, diseñar una prueba para un programa tiene algunos inconvenientes importantes:

• Es más difícil y requiere más tiempo que escribir el programa.
• Tiene que cubrir todo el programa, lo que significa que necesita pruebas para cualquier biblioteca, sistema operativo, etc.
• No prueba la ausencia de errores, ya que esos errores pueden ser causados ​​por accidente.

Este concepto fue muy popular en los años 70.

Enlace: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods