Quali sono le cause che portano a un software sovraccarico? [chiuso]

La mia ipotesi è che ci siano molte funzionalità che qualcuno ha pensato fosse una buona idea. Tuttavia, se molte persone hanno tutte idee separate che vengono messe insieme in un'unica applicazione, è così che può diventare così complicato. Non darei la colpa allo sviluppatore nel caso di grandi prodotti aziendali in cui dovrebbero esserci responsabili di prodotto che hanno una responsabilità per ciò che è nel prodotto e su come ottimizzarlo da diverse prospettive.

Un altro aspetto di questo potrebbe essere il debito tecnico che probabilmente non viene gestito bene nella maggior parte dei casi in quanto non è considerato un grande investimento di tempo. Sospetto che le nuove funzionalità e le correzioni di bug abbiano più senso dei refactoring o di altre attività di debito che potrebbero sembrare avere un valore commerciale immediato. Quante volte un team di sviluppatori impiegherebbe un paio di settimane per ripulire il codice legacy se la base del codice è piuttosto vecchia? La mia ipotesi non sarebbe spesso.

Per citare Joel in Strategia Lettera IV: Bloatware e il mito 80/20 :

[...] there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. [...] If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible. [...] But the loss to you of waiting an extra two months for the new version is perceptible, and the loss to the software company that has to give up two months of sales is even worse.

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. [...]

When you start marketing your "lite" product, and you tell people, "hey, it's lite, only 1MB," they tend to be very happy, then they ask you if it has their crucial feature, and it doesn't, so they don't buy your product.

Una buona parte di ciò riguarda le dipendenze di un prodotto. Il tuo sistema operativo viene fornito con molte librerie standard per tutti i tipi di cose. Tuttavia, queste librerie standard hanno versioni diverse durante l'evoluzione del sistema operativo e qualsiasi programma di installazione generico non può presumere che la versione specifica su cui è stato costruito sia effettivamente presente sul sistema operativo.

Quindi il programma di installazione completo dovrà includere la versione corretta di ogni dipendenza per assicurarsi che tutto funzioni definitivamente dopo l'installazione, indipendentemente dallo stato iniziale di ciascuna dipendenza sul computer di destinazione. Questo può essere abbastanza significativo per determinati tipi di applicazioni, ad esempio applicazioni basate su .NET che devono essere distribuite su sistemi Windows XP.

Fino a poco tempo fa, un sistema di installazione con cui ho lavorato richiedeva l'installazione di ogni singola versione .NET precedente per poter distribuire la versione più recente, quindi qualsiasi applicazione .NET 3.5 richiedeva i binari di installazione per .NET 1, 2, 2.5 e 3 IN ALTO a 3.5. In questo caso, solo il programma di installazione è gonfio.

Una soluzione alternativa è un programma di installazione web, che scarica solo quei componenti che non sono effettivamente presenti sul sistema di destinazione - e questo può essere un gigantesco vantaggio di dimensioni / ingombro. Ovviamente limita le tue installazioni a sistemi dotati di connettività Internet.

Penso che molto abbia a che fare con layer su layer del codice della libreria. Ovviamente quando usi una libreria non usi tutto ciò che contiene, in modo che l'eccesso si aggiunga man mano che includi sempre più biblioteche.

Combinando questo con il fatto che il costo di un'ora di lavoro da un programmatore sta diventando sempre più costoso mentre la potenza di elaborazione / archiviazione del computer tipico sta diventando più conveniente entro l'anno, si vede che in realtà è più economico modo.

• "Abbiamo bisogno di qualcosa da fare X. Usiamo la libreria $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, perché l'ho usata in un progetto diverso"
• "Penso che non abbiamo più bisogno di questa parte di codice, ma per essere sicuri che non si rompa nulla, tienilo semplicemente"
• Test di unità assenti o non sufficienti, che portano a
• Nessun refactoring
• Nessun monitoraggio, in cui le impostazioni sono state archiviate nel corso degli anni, quindi ora le impostazioni sono ovunque
• ...

È un circolo vizioso in cui tutti i cicli di disperazione possono essere biasimati . Un ciclo di disperazione consiste nei seguenti passaggi:

1. Gli uomini d'affari chiedono caratteristiche gonfiate.
2. Gli sviluppatori implementano le funzionalità gonfiate anche se sanno che non dovrebbero farlo.
3. I clienti pagano per le funzionalità gonfiate anche se vogliono solo il prodotto ma non la caratteristica stupida.
4. Gli uomini d'affari credono che i clienti desiderino le funzionalità gonfiate.
5. Vai al primo passaggio e ripeti.

Come lo fermi? Non c'è una risposta facile su come, ma è chiaro che per fermare il ciclo, uno dei passaggi deve essere rotto. Quindi può essere rotto solo da aziende, sviluppatori o consumatori che intraprendono un'azione rivoluzionaria.

1. Un ingegnere ha provato a ottimizzare un modulo ma ha introdotto diversi problemi con il cliente. Quindi, il suo manager ha detto no. Quindi, l'ingegnere ha deciso di non "creare problemi" fino a quando i problemi non lo turbano.
2. Per un sistema complesso, il fornitore ha già aggiunto molte patch e risolto migliaia di bug per renderlo stabile nell'ambiente del cliente. Non ha una buona qualità dal punto di vista del software, ma funziona. Nessuno vuole riscriverlo per correggere di nuovo la stessa quantità di bug.
3. per motivi di compatibilità con le versioni precedenti, anche se una funzione non è popolare nel mercato, dobbiamo tenerla lì.

La sua invariabilmente pigrizia, questo è ciò che causa il gonfiarsi. (o il fango come nell'articolo fondamentale su questo argomento, il Big Ball of Mud )

Ad esempio, dove lavoro abbiamo un'applicazione C ++ "legacy" che è tuttavia abbastanza ben progettata, i client parlano con un'API che parla con un server che funziona con DB. Tutto fatto sensibilmente. Recentemente abbiamo avuto bisogno di un modulo aggiuntivo, ma piuttosto che implementarlo correttamente lo sviluppatore ha deciso di implementarlo in .NET e, peggio, ha deciso che l'accesso ai dati tramite l'API era troppo difficile (non lo era ma ...) avrebbe effettuato connessioni DB direttamente. Quindi vedi come succede questo tipo di pasticcio. (e tutti con l'accordo dell'AT che ha messo "veloce" su "buono")

Ho già visto questo genere di cose prima - in un posto vecchio, una piccola parte della GUI era html, poiché alcuni sviluppatori pensavano che fosse una buona idea scrivere i dati in html e mostrare la GUI. Quindi una piccola parte fa qualcosa di diverso dal resto.

In breve, la pigrizia è cattiva e la coerenza è buona (indipendentemente dalla tecnologia utilizzata). Preferirei avere un'applicazione tutta MFC piuttosto che una che sia in parte MFC e parte Winforms e parte WebGL con molte diverse architetture di back-end che legano tutto insieme.