Non c'è davvero stata una cosa negli ultimi 20 anni che abbia fornito enormi guadagni nello sviluppo del software? [chiuso]

In No Silver Bullet , Fred Brooks fa una varietà di previsioni sul futuro dell'ingegneria del software, riassunte al meglio da:

Non esiste un singolo sviluppo, né nella tecnologia né nella tecnica di gestione, che da solo prometta un miglioramento di un ordine di grandezza in termini di produttività, affidabilità, semplicità.

Il suo argomento è molto convincente. Brooks scriveva nel 1986: aveva ragione? Gli sviluppatori nel 2014 producono software a una velocità inferiore di 10 volte rispetto alle loro controparti nel 1986? Secondo alcune metriche appropriate: quanto è stato effettivamente maggiore il guadagno in termini di produttività?

Gli sviluppatori nel 2014 producono software a una velocità inferiore di 10 volte rispetto alle loro controparti nel 1986?

Immagino che da allora ci sia stato almeno un ordine di miglioramento della magnitudo nella produttività. Ma non sfruttando un singolo sviluppo, sia nella tecnologia che nella tecnica di gestione.

Gli aumenti della produttività sono dovuti a una combinazione di fattori. Nota: questo non è un elenco completo:

1. Migliori compilatori
2. Computer notevolmente più potenti
3. Intellisense
4. Orientamento agli oggetti
5. Orientamento funzionale
6. Migliori tecniche di gestione della memoria
7. Verifica dei limiti
8. Analisi del codice statico
9. Digitazione forte
10. Test unitari
11. Migliore progettazione del linguaggio di programmazione
12. Generazione del codice
13. Sistemi di controllo del codice sorgente
14. Riutilizzo del codice

E così via. Tutte queste tecniche si combinano per produrre incrementi di produttività; non esiste un solo proiettile d'argento che abbia mai prodotto un ordine di accelerazione di grandezza.

Si noti che alcune di queste tecniche esistono dagli anni sessanta, ma hanno osservato recentemente un riconoscimento e un'adozione diffusi.

La risposta di Robert Harvey è buona, ma penso che abbia tralasciato quello che potrebbe essere il motivo principale per cui i programmatori sono più produttivi che mai: ampia disponibilità di librerie software.

Quando ho iniziato la mia carriera non c'erano STL, .NET, QT, ecc. Avevi C o C ++ grezzo, e questo era tutto.

Le cose che richiedevano giorni o settimane o lavoro (analisi XML, connessioni TCP / IP, comunicazione HTTP) ora possono essere fatte 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 prodotto attuale utilizza un framework per finestre docking che abbiamo acquistato da un fornitore. Questo mi permette di avere un'interfaccia utente della finestra di docking completamente funzionale in pochi minuti. Rabbrividisco nel pensare a cosa ci vorrebbe per farlo nei giorni in cui usavo l'API win32.

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

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

Essere in grado di trovare immediatamente una risposta a quasi tutti i problemi che puoi incontrare come sviluppatore consente un enorme aumento della produttività. Non sai come selezionare l'ennesimo elemento in JQuery? La ricerca di Google porta a una risposta alla domanda esatta su StackTranslate.it . Non sai come usare overflownei CSS? L'MDN di Mozilla è qui . virtualHai dimenticato cosa significa la parola chiave in C #? Google aiuta di nuovo.

Quando ho iniziato a programmare, non avevo Internet. Avevo libri, così come alcuni documenti in formato digitale archiviati localmente, ma la ricerca tra libri e documentazione era un processo lento, e non importa quanti libri avessi, c'erano molti problemi che non erano menzionati lì.

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

• Su Stack Overflow, ovviamente. Ad esempio, non ho visto nessun libro che menzionasse questo problema .

• Nei blog. Ho trovato molto aiuto sui blog quando ho avuto particolari problemi, sarebbe con la configurazione WCF o un server proxy che non si avvia 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 molto utile di recente quando ho tentato di utilizzare MAAS di Ubuntu e quando ho usato PXE. Non trovi questo tipo di informazioni neanche nei libri.

L'importanza della disponibilità immediata di una risposta alla maggior parte dei problemi che si possono incontrare è particolarmente evidente se si tiene conto del fatto che la maggior parte del tempo speso in un progetto viene speso per mantenerlo .

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

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

• Ma la maggior parte dei problemi che compaiono durante la manutenzione, è lì quando l'aiuto di altri attraverso Internet appare cruciale . Esempio di base: un servizio WCF funziona perfettamente sulla mia macchina , ma fallisce senza alcuna eccezione quando viene 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 un lato, ci sono casi in cui trovi immediatamente una risposta, mentre potresti aver trascorso giorni a cercarla da solo (o essere costretto a riscrivere gran parte dell'applicazione).

• D'altra parte, la produttività complessiva è migliorata sulla base di molteplici fattori, come ad esempio una migliore gestione dei progetti (mi viene in mente Agile, TDD ecc.), Una migliore gestione dei team (mi viene in mente la gestione radicale di Stephen Denning), strumenti migliori (debugger, profilatori , IDE, ecc.), Hardware migliore (no, non sarò molto produttivo se costretto 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 per gli sviluppatori di oggi. Condivisione istantanea della conoscenza su base globale! In questi giorni non hai bisogno di conoscere le risposte, devi solo sapere come conoscere le risposte - e questo è un abbonamento perfettamente adeguato che consente agli sviluppatori di dedicare meno tempo a leggere e più tempo a programmare, e quindi essere produttivi. Significa che ogni programmatore nel mondo ha accesso a tutte le risposte, e tutto ciò che devono fare è sapere come porre le domande giuste.

Suggerirei che le tendenze che ci spingono nella direzione opposta (cioè verso una minore produttività) siano almeno altrettanto forti delle tendenze che hai chiesto. L'esperienza di fare strumenti di sviluppo client / server come VB6 o PowerBuilder si avvicina molto all'ideale "Rapid Application Development" (RAD). Devi disegnare i tuoi moduli e c'erano ovvi hook 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 aggrappati disperatamente, per esempio, a VB6.

Il passaggio allo sviluppo Web fortemente guidato dal cliente è stata l'ennesima esperienza slash-and-burn; Microsoft stava tornando all'ideale RAD con WebForms, e poi è rapidamente caduto in disgrazia. Invece gli sviluppatori dovevano abusare dell'infrastruttura (ad es. XMLHttpRequest, che viene raramente utilizzato per XML) e altrimenti cercare un basso livello di astrazione nel tentativo di rendere i loro siti Web più interattivi

Esistono buoni motivi alla base di tutte queste transizioni e non è corretto confrontare un processo che ha prodotto un .EXE nativo (che richiede installazione e gestione sul singolo client) con lo sviluppo Web, né è del tutto corretto confrontare un processo che si basa fortemente sui postback con uno che offre un'esperienza più fluida. Ma dirò che le pratiche attualmente in voga provocano alcuni processi di pensiero sorprendentemente di basso livello tra le persone che hanno perso client / server, RAD e simili. I pulsanti client / server hanno appena funzionato e certamente non ci si deve preoccupare dei canali di dati sottostanti che hanno inviato i dati ai gestori di eventi che lo hanno reso possibile.

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) abbiano la tendenza a ricorrere a scorciatoie (e lo intendono in senso negativo). Questo è comprensibile, ma penso ancora che il modo in cui lo sviluppo contemporaneo è fatto sia di livello sorprendentemente basso, e i giorni della ricerca di un "proiettile d'argento" sembrano aver lasciato il posto all'era del deridere quelli di noi che mettono in dubbio la saggezza del mining e fondendo il nostro vantaggio.

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

• Il problema sembra cambiare i requisiti . Il cliente sa che non ci saranno sprechi di materiale quando si modificano i requisiti di un progetto software, quindi lo fanno. Quel tipo di modifica dei requisiti non si verifica quasi mai una volta che un progetto del mondo fisico come un edificio è fatto a metà.

• Un altro aspetto importante è che la programmazione continua ad essere altamente 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 di budget superati continua ad essere maggiore di quello di altre discipline, e spesso si verifica un debito tecnico per soddisfarle, generando costi nascosti.

• Qualcosa che è accaduto, senza dubbio, è che è avvenuta la compartimentazione . L'enorme quantità di tecnologie che uno deve sapere è che i programmatori hanno dovuto specializzare 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 case automobilistiche nel mondo, l'elenco delle aziende in grado di creare e mantenere un sistema operativo (desktop, mobile, incorporato o altro), può essere contato con le dita delle tue mani.

• Tutto quanto sopra ha creato una situazione in cui non ci sono abbastanza persone che studiano per essere 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 dichiarazioni sull'idoneità di questo software per scopi particolari. Viene fornito" così com'è "senza garanzia esplicita o implicita." Immagina un produttore di hardware che afferma che il suo prodotto non è adatto a nessuno scopo particolare. Questo è lo stato dell'arte in questo momento.

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

Prima di tutto, è stata inventata pochissima tecnologia davvero nuova dal forse 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 avanti ce n'è uno indietro.

La tecnologia del compilatore ha permesso un miglioramento di circa 10 volte della "produttività" del programmatore rispetto al 1970, quando una funzione di cifre veniva prodotta divisa per il tempo di programmazione effettivo, ma la proliferazione di linguaggi e ambienti di programmazione nuovi o "rivisti" significa che il programmatore medio sta spendendo sempre di più tempo in modalità "recupero" e meno in attività produttiva. Apple, Google e Microsoft emettono "aggiornamenti" nuovi e sostanzialmente incompatibili nei loro ambienti a un ritmo che è appena inferiore a quello che provocherebbe rivolta tra i loro servitori ... programmando i clienti. Allo stesso modo, HTML / CSS / Javascript / qualunque cosa diventa sempre più complessa.

Un tempo il ritmo con cui la documentazione poteva essere prodotta e propagata avrebbe limitato e annullato tutta questa "innovazione", ma, grazie a Internet, non è più necessaria una documentazione rigorosa - basta sputare le funzioni e fare affidamento sui blogger per scovare i dettagli e renderli disponibili.

Aggiunto: ci sto pensando da ieri, e in particolare pensando al progetto a cui ho lavorato dal 1978 al 2008. Questo progetto (IBM System / 38 e i suoi successori) è stato in qualche modo unico in quanto fin dall'inizio gli sforzi sono stati fatto per controllarne la complessità (uno è la divisione del software in due parti approssimativamente uguali, con un'interfaccia "macchina" tra di loro). Nella particolare area in cui ho lavorato, molti dei miei colleghi si dedicarono allo stesso modo al controllo della complessità (anche se al momento non usavamo molto questo termine). Il risultato è stato un prodotto che (all'inizio) era abbastanza robusto e un "successo" con i clienti praticamente da subito. Ed è stato un piacere lavorare - come suonare in un'orchestra ben addestrata.

Certo, nel corso degli anni si è insinuata la complessità, di solito per volere di pianificatori e manager di mercato che non avevano apprezzamento per il controllo della complessità (che è in qualche modo diverso dal semplice mantenimento della semplicità). Non ho la sensazione che ciò fosse inevitabile, ma in questo caso era impossibile impedire a un manager (come Glenn Henry in origine) di respingere le forze della confusione.

Gran parte di ciò che abbiamo appreso nella pratica dell'ingegneria del software negli ultimi 30 anni è nella forma "la tecnologia X può accelerare lo sviluppo iniziale di nuovi software, ma se non passi troppo o più tempo a pensare a come e quando usarlo come hai salvato usando, a lungo termine trasformerà la tua applicazione in una palude risucchiata di debito tecnico, costandoti ordini di grandezza più tempo e fatica nella manutenzione. "

Le tecnologie che rientrano in questo rasoio includono: linguaggio assembly codificato 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, ambito lessicale, ambito dinamico , puntatori "sicuri", puntatori "non sicuri", assenza di puntatori come concetto di linguaggio, formati di file binari, formati di file con marcatura strutturata, macro, modelli, prevenzione di macro e modelli, memoria condivisa, passaggio di messaggi, thread, coroutine, loop di eventi asincroni, servizi remoti centralizzati, servizi distribuiti, software installato localmente, array, elenchi collegati, tabelle hash e alberi.

Il fatto che molti degli elementi dell'elenco precedente appartengano a gruppi che insieme esauriscono lo spazio di soluzione noto è molto intenzionale e dovrebbe di per sé dirti qualcosa. Si potrebbe sostenere che l' unica inequivocabile, across-the-board miglioramenti nella prassi che abbiamo avuto da quando prima acceso il Z3 sono strutturato a blocchi di programmazione (al contrario di spaghetti code) e la protezione della memoria (ragazzo, faccio mai non perdere i giorni in cui un errore di battitura potrebbe distruggere il mio intero computer).