Perché sacrificare le buone pratiche di ingegneria del software è tipicamente la prima scelta per i progetti di sviluppo software che presuppongono una qualità "abbastanza buona" [duplicato]

Questo dipende molto dalla reazione del cliente quando riceve software che non gli piace. Pochissimi diranno: "Accidenti, avevi ragione, avremmo dovuto fare dei test". ma la maggior parte si sentirà come se avresti dovuto essere in grado di apportare quelle modifiche "semplici" comunque.

Se continui a lottare con i clienti, devi smettere di chiedere loro se vogliono che tu crei dei test. Fornisci preventivi basati sul tuo parere di esperti per fare un lavoro di qualità. Chiedi loro se vogliono che tu usi e IDE che è più produttivo o se dovresti automatizzare la build?

I clienti devono capire che stanno assumendo i rischi quando creano restrizioni su un progetto. Invece di dire "te l'avevo detto". dovresti prendere l'abitudine di dire "No".

Non ho mai visto un cliente che chiedesse software di scarsa qualità. Tuttavia, quello che vogliono è il software più economico, e lo vogliono il prima possibile.

Il modo più economico e veloce per sviluppare software è quello di mettere insieme qualcosa nel più breve tempo possibile, quindi eseguirne il debug fino a quando non fa praticamente quello che volevi e non si arresta troppo spesso.

A quel punto lo sviluppatore può spedire il software e fatturare il cliente. Il venditore è felice perché viene pagato. L'acquirente è felice perché ha ottenuto ciò che ha ordinato molto rapidamente a un prezzo basso.

L'utente finale ha software bacato e inaffidabile. Ma l'utente finale non è colui che prende le decisioni di acquisto.

I costi di manutenzione a lungo termine non sono una considerazione in nessun punto del ciclo.

Da quello che ho incontrato, di solito, per costruire ciò che può essere considerato come un buon software , è necessario avere un insieme chiaro di requisiti, forse non tutti, ma almeno un insieme di regole fondamentali che non cambieranno. Da questo, scegli la tua architettura, i modelli di progettazione, le lingue e i framework.

Il problema con questo è che la maggior parte delle volte, i client stessi non veramente sanno quello che vogliono. Di solito conoscono ciò che vorrebbero ottenere, ma quando si iniziano a fare domande sul motivo per cui desiderano determinate funzionalità rispetto ad altre funzionalità, la maggior parte di esse di solito è vuota. Per aggiungere la beffa al danno, alcuni clienti potrebbero sentirsi offesi da tutte le tue domande dal momento che ritengono che siano scuse per non svolgere il lavoro e perdere tempo.

I clienti di solito vogliono soluzioni veloci e vogliono che siano a buon mercato (almeno nel breve periodo). A loro non interessa davvero quello che hai fatto fino a quando hai consegnato ciò che hanno chiesto. Dalla mia esperienza, i clienti cercheranno sempre la soluzione rapida anche se richiederà un sacco di manutenzione. Prendendo mesi per progettare correttamente un sistema che è facile da aggiornare è qualcosa che, almeno per esperienza, non accade.

Penso che il tuo ragionamento sia errato perché consideri le "best practice" come booleano.

Tuttavia, non si tratta di applicarli o meno. È "quanto" li applichi.

Ad esempio test : puoi fare un paio di test manuali, coprire automaticamente i test di base, creare una suite automatica estesa, testare anche tutte le tue librerie / dipendenze, ricontrollare da terze parti ...

Ad esempio la qualità del codice : codice man mano che procedi, prendi tempo per un design pulito, spesso refactoring, ricontrolla tutto, triplo controllo da parte di terzi, prove formali ...

Tutto ha un costo. Fondamentalmente, più si vuole garantire che il software sia privo di bug, più costa. Le suite di test e i frequenti refactoring possono essere rapidamente più che lo sviluppo stesso. Ora, qual è il costo di un bug? ... ogni client è da qualche parte su questa curva di prezzo / bug.

Alcune persone vogliono semplicemente qualcosa di semplice e preferiscono vivere con un bug ogni tanto piuttosto che pagare i soldi extra. Ci sono molti esempi per questo:

• le persone preferiscono uno strumento gratuito anche se è noto che ha molti svantaggi
• le persone vogliono solo un prototipo
• le persone vogliono software veloce / economico perché hanno bisogno di un rapido ritorno sull'investimento per rimanere a galla
• persone che non vogliono spendere molto per il software

ci sono anche altri estremi. Il software per aeromobili, applicazioni aerospaziali finanziarie e mediche sono testati in modo così accurato che anche le minuscole modifiche richiedono rapidamente milioni perché molte di cose devono essere accuratamente verificate. E non pensare nemmeno di aggiornare una libreria open source ... o addirittura di usare hardware "normale"! ;)

Anche qui è frequente che lo stesso modulo sia implementato in parallelo da team indipendenti. I moduli vengono quindi eseguiti in parallelo. Se a un certo punto la loro produzione differisce, si verifica una sorta di processo decisionale, come l'adozione di un approccio "maggioranza vittorie" se sono disponibili tre moduli. ... quindi, sei pronto a sviluppare lo stesso software da tre diversi team solo per assicurarti che sia affidabile? ;)

Ci sono già molte buone risposte.
Vorrei aggiungere che a volte il time-to-market è uno dei requisiti. Ad esempio, ci sono industrie in cui una grande percentuale di vendite sono generate nelle fiere commerciali; ciò significa una scadenza difficile, e se ti manca, hai perso opportunità e probabilmente quote di mercato. In tal caso, è tipicamente necessario avere il tuo prodotto pronto per "la grande fiera" - anche se ha qualche bug o hai dovuto sostenere qualche debito tecnico.

Delivery Quality can be expressed as a function of cost and time.

Future cost of software for maintenance and enhancements can only be expressed as function of current delivery quality.

"Abbastanza buono va bene" - > Posso convivere con gli occasionali arresti anomali, i costi di manutenzione, l'aumento delle funzionalità future con l'aggiunta di costi .. ciò di cui ho bisogno ADESSO è un software abbastanza buono .. una cattiva decisione commerciale in determinate circostanze (di costi e tempi) .. in tali casi va fuori dalla finestra sono extra (meno) linee di codici, refactoring, unit test in una certa misura, e così via ..

"Va bene va bene" e "Inoltre non vedo l'aumento dei costi futuri per manutenzione e miglioramento" - > Sono un idiota e tu sei un'anima sfortunata capita di lavorare per me.