Negli ultimi 20 anni non c'è stata davvero nessuna cosa che abbia procurato enormi miglioramenti nello sviluppo del software? [chiuso]

Do developers in 2014 produce software at a rate less than 10x faster than their counterparts in 1986?

Immagino che da allora ci sia stato almeno un miglioramento della produttività in ordine di grandezza. Ma non facendo leva su un singolo sviluppo, sia nella tecnologia che nella tecnica di gestione.

L'aumento della produttività è dovuto a una combinazione di fattori. Nota: questo non è un elenco completo:

1. Migliori compilatori
2. Computer notevolmente più potenti
3. Intellisense
4. Orientamento oggetto
5. Orientamento funzionale
6. Migliori tecniche di gestione della memoria
7. Controlla i controlli
8. Analisi del codice statico
9. strong tipizzazione
10. Test unitario
11. Migliore progettazione del linguaggio di programmazione
12. Generazione codice
13. Sistemi di controllo del codice sorgente
14. Riutilizzo del codice

E così via. Tutte queste tecniche si combinano per produrre aumenti di produttività; non c'è un singolo proiettile d'argento che abbia mai prodotto un'accelerazione dell'ordine di grandezza.

Si noti che alcune di queste tecniche esistono dagli anni Sessanta, ma di recente hanno riscontrato solo un riconoscimento e un'adozione diffusi.

La risposta di Robert Harvey è buona, ma penso che abbia omesso quella che potrebbe essere la ragione principale per cui i programmatori sono più produttivi che mai: ampia disponibilità di librerie software.

Quando ho iniziato la mia carriera non esistevano STL, .NET, QT, ecc. Avevi il raw C o C ++, e questo era tutto.

Le cose che richiedevano giorni o settimane o lavoro (analisi XML, connessioni TCP / IP, comunicazione HTTP) ora possono essere eseguite con una manciata di righe di codice C #. È qui che abbiamo ottenuto ordini di grandezza migliori in termini di produttività generale degli sviluppatori.

Il nostro attuale prodotto utilizza un framework per finestra di ancoraggio che abbiamo acquistato da un fornitore. Questo mi permette di avere un'interfaccia utente della finestra docking completamente funzionale in pochi minuti. Rabbrividisco a pensare a cosa ci vorrebbe per farlo ai tempi dell'utilizzo dell'API win32.

Per ragioni, non sono d'accordo con l'affermazione di Fred Brooks .

C'è un miglioramento della tecnologia che ha permesso un miglioramento della produttività dell'ordine di grandezza: internet , e più precisamente la progressiva disponibilità di connessione Internet in ogni casa negli ultimi due decenni.

Essere in grado di trovare istantaneamente una risposta a quasi tutti i problemi che si possono incontrare come sviluppatori consente un enorme aumento della produttività. Non so come selezionare l'ennesimo elemento in JQuery? La ricerca di Google porta a una risposta di la domanda esatta su Stack Overflow . Non so come usare overflow in CSS? L'MDN di Mozilla è qui . Hai dimenticato quale parola chiave virtual significa in C #? Google aiuta , ancora.

Quando ho iniziato a programmare, non avevo Internet. Avevo libri e una documentazione in formato digitale archiviata localmente, ma la ricerca tra libri e documentazione era un processo lento, e non importa quanti libri avessi, c'erano problemi di molti che non erano menzionato lì.

Ancora più importante, quasi tutti i problemi che incontri sono già stati incontrati da qualcun altro prima. Internet aiuta a trovare persone che hanno avuto questo errore e lo ha risolto con successo. Questa non è una sorta di informazioni che trovi nei libri o nella documentazione ufficiale come MSDN. Invece, tali informazioni si trovano di solito:

• On Overflow dello stack, ovviamente. Ad esempio, non ho visto nessun libro che menzionasse questo problema .

• Nei blog. ho trovato molto di aiuto sui blog quando ho avuto problemi particolari, sarebbe con la configurazione WCF o con un server proxy che non funziona t iniziare o un bug criptico quando si utilizza un'API specifica su una macchina con cultura diversa da en-US.

• Nelle segnalazioni di bug riguardanti il software open source. Ad esempio, è stato di recente molto utile quando ho tentato di utilizzare il MAAS di Ubuntu e quando ho usato PXE. Neanche questo tipo di informazione è presente nei libri.

L'importanza della disponibilità immediata di una risposta alla maggior parte dei problemi che si possono incontrare è particolarmente evidente se consideriamo che la maggior parte delle volte che un team spende per un progetto viene speso per mantenerlo .

• Internet non aiuta molto durante le fasi di progettazione e architettura (Programmers.SE potrebbe essere d'aiuto, ma sarebbe molto più prezioso per un architetto leggere libri sull'architettura e sul design, apprendere modelli di progettazione, ecc.) .

• Inizia a essere utile durante i test e i passaggi di implementazione, quando sorgono problemi reali.

• Ma la maggior parte dei problemi che appaiono durante la manutenzione, è lì quando l'aiuto degli altri attraverso internet appare fondamentale . Esempio di base: un servizio WCF funziona perfettamente sulla mia macchina , ma fallisce senza eccezioni quando distribuito in produzione, mentre ha funzionato nelle ultime due settimane. Questo è successo a me, e sono grato agli scrittori di blog e alla community di Stack Overflow per avermi aiutato a risolvere il problema in poche ore anziché in settimane.

Giustificherebbe un aumento della produttività di x10? Difficile da dire.

• Da una parte, ci sono casi in cui trovi una risposta immediatamente, mentre potresti aver trascorso giorni a cercarla da sola (o essere costretta a riscrivere gran parte dell'applicazione).

• D'altra parte, la produttività generale migliorata in base a molteplici fattori, come una migliore gestione del progetto (Agile, TDD ecc., mi viene in mente), una migliore gestione del team ( Gestione radicale di Stephen Denning viene in mente), strumenti migliori (debugger, profiler, IDE, ecc.), hardware migliore (no, non sarò molto produttivo se obbligato a scrivere in Assembler per una CPU lenta e RAM molto limitata), ecc.

Direi che Internet è un buon candidato. StackOverflow e Google sono gli strumenti più potenti dello sviluppatore di oggi. Condivisione della conoscenza istantanea su base globale! In questi giorni non hai bisogno di conoscere le risposte, hai solo bisogno di sapere come conoscere le risposte - e questo è un sottotesto perfettamente adeguato che consente agli sviluppatori di dedicare meno tempo alla lettura e più tempo codifica e quindi essere produttivi. Significa che ogni programmatore al mondo ha accesso a tutte delle risposte e tutto ciò che devono fare è sapere come fare le domande giuste.

Suggerirei che le tendenze che ci spingono nell'altra direzione (cioè verso una minore produttività) sono almeno altrettanto forti delle tendenze che hai chiesto. L'esperienza di realizzare uno strumento di sviluppo client / server come VB6 o PowerBuilder si avvicinava molto all'ideale "Rapid Application Development" (RAD). Devi disegnare i tuoi moduli e c'erano ovvi riferimenti per il tuo codice procedurale o SQL.

Lo sviluppo Web, almeno inizialmente, ha distrutto molte delle tecniche e dell'infrastruttura che hanno reso possibili queste cose, e molti sviluppatori client / server hanno appena smesso di essere sviluppatori, o si sono attaccati disperatamente a, ad esempio, VB6.

La transizione verso uno sviluppo Web strongmente orientato al cliente è stata un'altra esperienza di slash-and-burn; Microsoft stava tornando all'ideale RAD con WebForms, e quindi è rapidamente caduto in disgrazia. Ci si aspettava invece che gli sviluppatori abusassero dell'infrastruttura (ad esempio XMLHttpRequest, che viene raramente utilizzato per XML) e altrimenti si aggirano a un basso livello di astrazione nel tentativo di rendere i propri siti più interattivi

Ci sono buone ragioni dietro tutte queste transizioni, e non è giusto confrontare un processo che ha prodotto un .EXE nativo (che richiede installazione e gestione sul singolo client) allo sviluppo Web, né è del tutto equo comparare un processo che fa molto affidamento sui postback con uno che produce un'esperienza più fluida. Ma dirò che le pratiche attualmente in voga si traducono in alcuni processi di pensiero sorprendentemente di basso livello tra le persone che hanno mancato a client / server, RAD e simili. I pulsanti client / server hanno funzionato, e certamente non ci si doveva preoccupare dei canali dati sottostanti che hanno dato i dati ai gestori di eventi che l'hanno fatto accadere.

Al contrario, gli sviluppatori più contemporanei tendono a pensare che quelli di noi che hanno fatto lo sviluppo client / server (o anche lo sviluppo Web basato sul postback) hanno la tendenza a ricorrere a scorciatoie (e ciò significa in modo negativo). Questo è comprensibile, ma continuo a pensare che il modo in cui lo sviluppo contemporaneo viene fatto sia sorprendentemente basso, e i giorni in cui si cerca un "proiettile d'argento" sembrano aver lasciato il posto all'epoca di prendere in giro quelli di noi che mettono in dubbio la saggezza del smelting il nostro vantaggio.

La tecnologia è avanzata molto e ora abbiamo tutte le cose elencate da Robert Harvey nella sua risposta, ma:

• Il problema sembra essere Modifica dei requisiti . Il cliente sa che non ci sarà spreco di materiali quando si cambiano i requisiti di un progetto software, quindi lo fanno. Questo tipo di requisito cambia quasi mai, una volta che un progetto del mondo fisico come un edificio è a metà.

• Un altro aspetto importante è che la programmazione continua ad essere altamente lavoro manuale . Raramente, se mai, il codice generato dalla RAD entra in produzione senza essere prima modificato manualmente.

• Il codice continua ad essere estremamente complesso e tale complessità non sembra diminuire con le nuove tecnologie.

• Il tasso di scadenze non rispettate o i budget superati continua ad essere maggiore rispetto a quelli in altre discipline, e spesso il debito tecnico è sostenuto al fine di soddisfarli, generando costi nascosti. / p>

• Qualcosa che è successo, senza dubbio, è che compartimentalizzazione è accaduto. L'enorme quantità di tecnologie che si devono conoscere è che i programmatori hanno dovuto specializzarsi in un piccolo numero di tecnologie per diventare veramente bravi con loro, richiedendo diversi tipi di esperti per completare un grande progetto.

• Una cosa che parla della complessità del software è che mentre ci sono letteralmente centinaia di produttori di automobili nel mondo, l'elenco di aziende in grado di creare e mantenere un sistema operativo , (desktop, mobile, incorporato o altro), può essere contato con le dita delle mani.

• Tutto quanto sopra ha creato una situazione in cui non ci sono abbastanza persone che studiano per diventare programmatori , in modo che i governi abbiano creato campagne per motivare più studenti a intraprendere quel percorso di carriera.

• Un assaggio della maturità dell'industria del software è che le licenze software continuano a dichiarare "< companyX > non rilascia alcuna dichiarazione sull'idoneità di questo software per qualsiasi scopo particolare Viene fornito "così com'è" senza garanzia espressa o implicita. " Immagina un produttore di hardware che dichiari che il loro prodotto non è adatto per uno scopo particolare. Questo è lo stato dell'arte al momento.

Mentre si potrebbe discutere con metriche specifiche (cioè, se le cose sono migliorate di un fattore di 9,98?), I (parlando come qualcosa di un veterano) deve essere d'accordo con il sentimento generale del commento di Brooks.

Prima di tutto, c'è stata pochissima tecnologia nuova inventata dal 1970. Sì, i circuiti integrati sono diventati più lunghi, più bassi, più larghi e la fibra di vetro ha migliorato le velocità di comunicazione, ma per ogni passo in avanti ce n'è uno indietro.

La tecnologia del compilatore ha permesso un miglioramento di 10 volte nella "produttività" del programmatore rispetto al 1970, quando una funzione di figure prodotta divisa per il tempo di codifica effettivo, ma la proliferazione di linguaggi e ambienti di programmazione nuovi o "revisionati" significa che il programmatore medio sta spendendo sempre più tempo in modalità "catch up" e meno in attività produttive. Apple, Google e Microsoft lanciano nuovi "aggiornamenti" sostanzialmente incompatibili ai loro ambienti a un ritmo appena inferiore a quello che provocherebbe una rivolta tra i loro servi ... er, programmando i clienti. Allo stesso modo, HTML / CSS / Javascript / tutto ciò diventa sempre più complesso.

Un tempo la velocità con cui la documentazione poteva essere prodotta e propagata avrebbe limitato e corrallato tutta questa "innovazione", ma, grazie a Internet, la documentazione rigorosa non è più realmente necessaria, basta sputare fuori le funzioni e fare affidamento sui blogger per carpire i dettagli e renderli disponibili.

Aggiunto: Ci stavo pensando da ieri, e in particolare pensando al progetto a cui ho lavorato dal 1978 al 2008. Questo progetto (IBM System / 38 e suoi successori) era un po 'unico in quanto fin dall'inizio furono fatti sforzi per controllare la complessità di esso (uno è la divisione del software in due parti approssimativamente uguali, con un'interfaccia "macchina" tra di loro). Nello specifico settore in cui lavoravo, molti dei miei colleghi si erano dedicati allo stesso modo al controllo della complessità (anche se in quel periodo non usavamo molto quel termine). Il risultato è stato un prodotto che (inizialmente) era abbastanza robusto e un "successo" con i clienti più o meno dal git-go. Ed è stato un piacere lavorare su, come suonare in un'orchestra ben addestrata.

Naturalmente, nel corso degli anni la complessità si è insinuata, di solito per volere di pianificatori e manager del mercato che non avevano alcun apprezzamento per il controllo della complessità (che è in qualche modo diverso dal semplice mantenimento della semplicità). Non ho la sensazione che fosse inevitabile, ma in questo caso era impossibile prevenire senza un manager (come originariamente aveva fatto Glenn Henry) spingendo indietro le forze della confusione.

Gran parte di ciò che abbiamo imparato nella pratica dell'ingegneria del software negli ultimi 30 anni è nella forma "la tecnologia X può accelerare lo sviluppo iniziale di un nuovo software, ma se non si spende tanto o più tempo a pensare su come e quando per usarlo come hai salvato usandolo, a lungo andare trasformerà la tua applicazione in una palude di debito tecnico, che ti costerà ordini di grandezza più tempo e impegno nella manutenzione. "

Le tecnologie che rientrano in questo rasoio includono: linguaggio assembly assemblato a mano, compilatori, interpreti, librerie di procedure, programmazione imperativa, programmazione funzionale, programmazione orientata agli oggetti, allocazione manuale della memoria, garbage collection, tipi statici, tipi dinamici, scope lessicale , ambito dinamico, puntatori "sicuri", puntatori "non sicuri", assenza di puntatori come concetto di linguaggio, formati di file binari, formati di file con markup strutturati, macro, modelli, elusione di macro e modelli, memoria condivisa, passaggio di messaggi, thread, coroutine, loop di eventi asincroni, servizi remoti centralizzati, servizi distribuiti, software installato localmente, matrici, liste collegate, tabelle hash e alberi.

Il fatto che molti degli elementi nell'elenco precedente siano raggruppati in gruppi che esauriscono lo spazio della soluzione noto è molto intenzionale e dovrebbe di per sé dirti qualcosa. Si potrebbe obiettare che i miglioramenti solo non ambigui e trasversali nella prassi che abbiamo avuto da quando hanno acceso la Z3 per la prima volta sono programmazione strutturata a blocchi (al contrario di spaghetti code) e protezione della memoria ( ragazzo, non dimentico mai non dei giorni in cui un errore di battitura potrebbe togliere tutto il mio computer).