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

9

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.

Evan
fuente
1
mira EXXXXXXXXXXXXXXXXXTREEEEEEEEEEEEEMEE programación ...
crasic
No hay "ideas de las masas", solo ideas que se vuelven populares, y no creo que ninguna idea sobre cómo hacer algo que esté en uso el tiempo suficiente para convertirse en popular pueda ser "simplemente errónea", ya que obviamente debe resolver algunos problemas o sería abandonado de inmediato por todos los que lo intenten.
Michael Borgwardt
2
CORBA no es un fracaso ... todavía está en uso
enone
@oenone, es un fracaso en el sentido de que no cumplió su promesa original de resolver problemas de interoperabilidad en general, y ahora es una tecnología de nicho.
Péter Török
¡HTTP JSON resolvió los problemas con WebServices pero no con la otra área de softwares!
sarat

Respuestas:

11

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?

Péter Török
fuente
Leyendo a través de ese enlace: querido Dios, CORBA debe haber sido horrible si los EJB V1 lo suplantaron porque eran más simples ...
Michael Borgwardt
El producto que Michi Henning desarrolló para rectificar muchas de las deficiencias de CORBA.
Blrfl
13

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" .

Modelo de cascada de Winston Royce

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.

Thomas Owens
fuente
66
La gente se aferró al primer método de la Cascada porque esto sería sorprendentemente similar a cómo sería un proyecto de ingeniería civil como la construcción de un rascacielos de 40 pisos. Cuando se construye un rascacielos, los requisitos y las limitaciones son demasiado dolorosos para pasar desapercibidos y nada importante cambiará a la mitad. El análisis y el diseño (arquitectura) deben ser completos y completos, sin dejar lugar para la interpretación. El edificio debe construirse según las especificaciones y finalmente los inspectores deben entrar y calificar el producto terminado. El software casi nunca es tan claro, por lo que el modelo Waterfall es un fracaso.
maple_shaft
2
@maple_shaft Me parece interesante, ya que Winston Royce fue la primera persona en discutir el uso de este modelo en un proyecto de software y crear el diagrama que es familiar para todos hoy, sin embargo, la gente no siguió leyendo para ver por qué dijo que no debería ser utilizado en un proyecto de software. Si la persona que primero escribe la idea dice que es mala y dice no solo por qué, sino también cómo hacerlo correctamente, ¿por qué la gente elegiría aferrarse a ella de todos modos? Me pregunto si tiene que ver con los primeros ingenieros de software que provienen de matemáticas e ingeniería eléctrica. En EE, ¿funciona este enfoque?
Thomas Owens
1
El modelo en cascada no está completamente equivocado: identifica correctamente las fases generales en el desarrollo de un proyecto de software y las ordena lógicamente. Lo que no reconoce es el hecho de que un proyecto de software se puede escribir de forma iterativa y modular, y como tal, los pasos que describe el modelo en cascada se pueden realizar en varias configuraciones para iteraciones individuales y / o componentes de todo el sistema.
tdammers
3
@Thomas Owens, "Si la persona que primero escribe la idea dice que es mala y dice no solo por qué, sino cómo hacerlo bien, ¿por qué la gente elegiría adherirse a ella de todos modos?" Adam Smith, el padre del capitalismo moderno, escribió su manifiesto sobre el mercado libre y puro, pero luego en su libro continúa hablando de cuán peligroso puede ser el concepto de corporaciones y cómo subvierten a los gobiernos para influir en los mercados a su favor. Convenientemente, las personas ignoran las partes de un concepto que no entienden o van en contra de sus nociones preconcebidas de lo que es correcto.
maple_shaft
2
"No sé por qué la gente se aferró a la primera cascada. Creo que les gusta asumir riesgos e invitar al fracaso". En mi humilde opinión es exactamente lo contrario. A las personas en general les gusta sentir que tienen el control de la situación, y los diagramas de proceso y las metodologías elaboradas les dan esa sensación de seguridad. Dado que esos procesos y gráficos los han ayudado antes en muchas otras áreas, asumen (erróneamente en este caso) que también funcionará de la misma manera en el desarrollo de SW ...
Péter Török
4

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.

Gilbert Le Blanc
fuente
1
Además, SQL y Visual Basic, que se anunciaron para permitir que los no programadores escriban programas.
Sean McMillan
2

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

Sean McMillan
fuente
3
Los métodos formales son más que simples pruebas. Se extiende desde los probadores de teoremas matemáticos y de uso que menciona hasta métodos más livianos que involucran modelar usando UML y OCL y crear una especificación formal en Z. Sí, la introducción de cualquier nivel de métodos formales agrega tiempo y costo, pero si está construyendo el software que está en algo que podría matar o herir a las personas (desde un marcapasos hasta un avión o un misil), gastar el tiempo y el esfuerzo adicionales para verificar y validar tanto como sea posible podría significar la diferencia entre la vida y la muerte.
Thomas Owens
@Thomas: Un buen punto. Y los métodos formales tienen cierta adopción en proyectos donde la muerte está en juego. Pero ciertamente no fueron la bala de plata para el software libre de errores.
Sean McMillan
Absolutamente. Tienen su lugar en la misión y el software vital, en diversos grados según el sistema. Después de todo, no hay balas de plata.
Thomas Owens