Qual è un buon esempio di idea o tecnica di sviluppo software che è stata un fallimento?

Nello specifico, quali sono alcuni esempi di idee sbagliate sulle masse. Perché in primo luogo le persone si sono aggrappate alle idee? E perché le idee sono state respinte? O forse le idee sono ancora vive e vegete e se sì, perché?

Ad esempio, potrei descrivere CORBA (e altre tecnologie simili) come qualcosa che ha tentato di risolvere il problema della comunicazione tra i componenti del software. Molti hanno ritenuto necessario definire i contratti tra i vari componenti. Alla fine, HTTP + JSON ha risolto il problema per le masse e sono emersi altri vari meccanismi RPC come Thrift e Proto-bufs.

Fondamentalmente, proprio come nel mondo esterno ai computer, idee e tecnologie competono per attenzione, leva ecc. Alcuni vincono, altri perdono; e alcuni potrebbero sembrare The Winner da qualche tempo, per poi svanire nell'oscurità con l'avvento di The Next Big Thing. Potrebbe avere o non avere nulla a che fare con il meglio. Testimone VHS vs Betamax, o la guerra più recente tra i vari formati di DVD.

CORBA era enorme, imbarazzante e difficile da usare, ma era il migliore che alcune persone potessero inventare in quel momento (nota che era stato progettato prima che il World Wide Web - e HTTP, Java, XML, ... - diventassero ampiamente noti). Ed è stato anche un classico esempio di design per comitato , in cui si affollano in ogni idea per soddisfare tutti, alla fine rendendolo inutilmente gonfio (almeno visto dagli occhi di oggi). Per non parlare del suo prezzo, che con l'avvento di FOSS divenne presto proibitivo.

Alla fine, HTTP + JSON ha risolto il problema per le masse

Almeno per qualcuno che non ha visto un paio di "soluzioni finali" simili sorgere e alla fine cadere ... È bene tenere presente che ai suoi tempi c'era un sentimento simile su CORBA ;-)

Sento che è giusto citare da The Rise and Fall of CORBA :

La storia di CORBA è quella che l'industria informatica ha visto molte volte e sembra probabile che gli attuali sforzi del middleware, in particolare i servizi Web, possano ricostruire una storia simile. [...]

Nel complesso, il processo di adozione della tecnologia OMG deve essere visto come la ragione principale del declino di CORBA. Il processo incoraggia la progettazione da parte della commissione e le manovre politiche al punto in cui è difficile raggiungere la mediocrità tecnica, per non parlare dell'eccellenza tecnica. Inoltre, l'aggiunta di caratteristiche sconnesse porta a una graduale erosione della visione architettonica. [...]

Un processo democratico come quello dell'OMG è particolarmente inadatto alla creazione di un buon software. Nonostante i noti problemi procedurali, tuttavia, l'industria preferisce affidarsi a grandi consorzi per produrre tecnologia. I servizi Web, l'attuale proiettile d'argento del middleware, utilizzano un processo molto simile a quello dell'OMG e, a detta di molti, soffrono anche di lotte interne, frammentazione, mancanza di coerenza architettonica, progettazione per comitato e gonfia funzionalità. Sembra inevitabile che i servizi Web mettano in atto una storia abbastanza simile a quella di CORBA.

Ora da una prospettiva diversa: dopo aver letto il tuo termine "idee delle masse", ho pensato a cose molto diverse rispetto a CORBA o ad altri standard; questi sono in genere l'idea di una persona o di un piccolo gruppo. Ho pensato a pratiche / punti di vista noti come "codifica da cowboy", "codificare e pregare", "funziona sulla mia macchina", ecc. Queste sono le vere "idee delle masse" di IMHO, dato che questo è il modo in cui quasi tutti i principianti lo sviluppatore inizia istintivamente a scrivere codice. E hanno torto, poiché non si ridimensionano né nello spazio né nel tempo: non si possono creare programmi estensibili, mantenibili ed estensibili in questo modo. Eppure ritengo che purtroppo sia ancora la norma piuttosto che l'eccezione per le persone cercare di lavorare in questo modo nei negozi professionali di tutto il mondo.

L'altro estremo di ciò sono le idee di molti manager e teorici del "giusto approccio" allo sviluppo di SW, che si manifestano in metodologie big-M come CMM, RUP, Waterfall ecc. L'idea alla base di tutte queste è che tutto ciò di cui hai bisogno è il giusto processo, e inizierà a produrre automaticamente software di qualità in modo deterministico, indipendentemente da chi siano effettivamente gli sviluppatori. Nota che lo stesso gioco può essere giocato anche usando i metodi Agile: è solo un cambio di etichette. Qualsiasi manager che crede che la selezione (e il mantenimento) dei membri giusti per il proprio team di sviluppo sia meno importante del processo di sviluppo, è destinato a fallire, qualunque esso accada. Tuttavia, questa convinzione in Process sembra essere ancora prevalente - forse viene ancora insegnata nelle scuole di gestione?

Un esempio frequente di persone sbagliate è il modello a cascata. Questo è un diagramma del modello stereotipato a cascata, che appare anche nel documento di Winston Royce "Gestione dello sviluppo di grandi sistemi software" .

Questa immagine è seguita da questo testo:

Credo in questo concetto, ma l'implementazione sopra descritta è rischiosa e invita a fallire ... La fase di test che si verifica alla fine del ciclo di sviluppo è il primo evento per il quale tempistica, conservazione, input / output, trasferimenti, ecc., sono esperienze distinte da analizzate. Questi fenomeni non sono precisamente analizzabili. Ad esempio, non sono le soluzioni alle equazioni differenziali parziali standard standard della fisica matematica. Tuttavia, se questi fenomeni non riescono a soddisfare i vari vincoli esterni, allora è invariabile una riprogettazione importante. Una semplice patch ottale o ripetizione di un codice isolato non risolverà questo tipo di difficoltà. È probabile che le modifiche alla progettazione richieste siano così dirompenti da violare i requisiti software su cui si basa la progettazione e che fornisce la logica di tutto. O i requisiti devono essere modificati o è necessario un cambiamento sostanziale nella progettazione. In effetti il ​​processo di sviluppo è tornato all'origine e ci si può aspettare un sovraccarico fino al 100% nei tempi e / o nei costi.

Più avanti nel documento, Royce presenta modelli di processo alternativi che prevedono l'iterazione tra la fase corrente e la fase precedente e un ciclo tra progettazione-analisi-requisiti e un altro ciclo tra prova-codice-progettazione. Identifica anche una serie di documenti e durante quali fasi devono essere completati, e sostiene il coinvolgimento dei clienti e più cascate all'interno di ciascuna fase per includere analisi, prove e utilizzo di tutti i manufatti coinvolti. In tutta realtà, ciò di cui parla Royce potrebbe essere considerato un approccio iniziale ai metodi agili - comunque molto guidato dai piani, ma una base per il movimento agile.

Perché le persone si sono aggrappate alla prima cascata, non lo so. Immagino che a loro piace correre rischi e invitare al fallimento.

Generazione automatica di codice da un livello di astrazione più elevato o programmazione automatica .

L'articolo di Wikipedia è in qualche modo carente di informazioni storiche, ma questo è stato un sogno dei manager da quando i programmatori sono diventati più costosi dei computer.

Dopo lo sviluppo di lingue di livello superiore come Fortran e Cobol, è arrivato lo sviluppo di lingue per domini speciali come la stesura di report. Easytrieve e SAS erano un paio di esempi.

Durante gli anni '80 gli strumenti CASE erano di gran moda. CASE è sinonimo di ingegneria software assistita da computer. Si pensava che la rigorosa applicazione dei principi di ingegneria avrebbe accelerato lo sviluppo del software. Il motivo principale per cui questi strumenti non hanno funzionato, oltre alle spese, è stato l'elevato livello di standardizzazione dei dati richiesto per il funzionamento efficace degli strumenti.

Internet è diventato famoso negli anni '90. Sono esplosi i tipi di programmazione facilitati da Internet. I programmatori dovevano gestire illustrazioni, mappe, fotografie e altre immagini, oltre a semplici animazioni, ad un ritmo mai visto prima, con pochi metodi ben noti. Il numero di tecnologie per produrre questi oggetti si è moltiplicato. Sogni di programmazione automatica sbiaditi.

La programmazione in outsourcing in località più economiche è uno dei pochi metodi rimasti per ridurre i costi del programmatore. I problemi con l'outsourcing includono problemi di comunicazione e problemi di specifica.

Metodi formali

C'era una volta, è stato proposto che il software potesse essere dimostrato corretto. (L'idea è che i test non possono mostrare che non ci sono errori, ma le prove sarebbero in grado di farlo.) Sfortunatamente, escogitare una prova per un programma ha alcuni importanti svantaggi:

• È più difficile e richiede tempo rispetto alla scrittura del programma.
• Deve coprire l'intero programma, il che significa che hai bisogno di prove per qualsiasi libreria, sistema operativo, ecc ...
• Non dimostra l'assenza di bug, poiché tali bug possono essere causati per caso.

Questo concetto era molto popolare negli anni '70.

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