Quando è OK sacrificare la "pulizia" del progetto per realizzare un progetto?

Quando si lavora su un prodotto che deve essere fatto presto e che funziona bene, quando è OK sacrificare la manutenibilità e la "pulizia" del design per portare a termine le cose e uscire rapidamente? E in che misura va bene, specialmente quando le tecniche utilizzate per renderlo "pulito" sono nuove per me?

Ricorda che sei impiegato per supportare un'azienda. In qualche modo, il tuo software sta influenzando i profitti dell'azienda. Devi trovare un equilibrio tra una soluzione tecnicamente perfetta, il time-to-market del tuo prodotto e quanti benefici ne trarrà l'azienda.

Nella mia esperienza, gli sviluppatori spesso si preoccupano della perfezione tecnica. Ma ci sono ragioni molto valide per sacrificare gli attributi di qualità come la manutenibilità o le prestazioni al fine di ottenere un prodotto più velocemente. Dipende dall'azienda e dal prodotto. Ma "cercare sempre un design perfetto" è un approccio troppo semplicistico.

Alla fine della giornata, l'unica cosa che conta è il valore per l'azienda. Scopri come massimizzarlo a breve e lungo termine e perseguire l'obiettivo.

Il termine "debito tecnico" è molto utile per aiutare a prendere decisioni commerciali come questa. Qualsiasi lavoro che non fai ora causerà una certa quantità di lavoro in seguito. Proprio come con le finanze, assumersi il debito è rischioso, ma può valere la pena fare leva se si sarà in grado di ripagare il debito in un secondo momento.

Detto questo, il debito tecnico non è un rapporto 1: 1 al momento del rimborso. I bug sono più costosi da correggere dopo il rilascio e l'impatto sulla produttività futura quando si sviluppa da un sistema legacy disordinato può essere scandaloso. Potresti dedicare il doppio del tempo a correggere i tuoi errori, o forse 1.000 volte più ore-uomo e risorse.

Il tuo compito in questa decisione è comprendere le ramificazioni dei particolari pezzi di taglio che stai prendendo in considerazione e quindi comunicare tali ramificazioni alle persone che prendono la decisione aziendale. Questa particolare capacità di stima potrebbe richiedere molta ricerca e lavoro da parte vostra per svilupparsi bene in questo momento, ma sarà preziosa durante la tua carriera.

Quando viene accettato e le conseguenze sono comprese dal proprietario / cliente / utente.

Un idraulico deve eliminare uno smaltimento dei rifiuti per la riparazione. Voglio usare il lavandino nel frattempo, ma dovrebbe farmi pagare per il tempo e i materiali da mettere in tubi temporanei usando del nastro che potrebbe rompersi. Anche questo ritarderà il rientro in officina. Se accetto la fatturazione aggiuntiva con la consapevolezza di rischiare un intasamento. Ci vorrà un giorno in più per riparare lo smaltimento e un ritardo ancora maggiore prima che possa rimetterlo, è accettabile.

Ora puoi essere puntuale e budget, ma sacrificare / rischiare un costo ancora più elevato nel lungo periodo. Questo può essere difficile da comprendere per le persone non tecniche, ma è a questo che serve il personale di vendita.

Molte persone rinunciano rapidamente a quando imparano qualcosa di nuovo e lo fanno come sempre. Se questo è uno schema, non solo il tuo codice subirà, ma le tue abilità di programmatore rimarranno limitate.

Tuttavia, alla fine della giornata, l'unico software di successo è quello fornito.

Trascorso il termine morbido. E anche allora è un livello molto basso di "OK". Dopo che la scadenza è scaduta, è ovvio. Perché questa è la natura delle scadenze rigide.

Inoltre, ciò comporta un debito tecnico. Per ogni ora / giorno che trascorri in avanti con la mentalità fatta in casa, ti costerà all'incirca il doppio del tempo quando il prossimo devi toccare questo progetto. Se è necessario, allora è meglio correre, spedire e quindi iniziare immediatamente a riparare tutto il nastro d'anatra. Tornare a un progetto dagli occhi incantati anni dopo è un incubo. Se non lo toccherai mai più, così sia, a nessuno importa. Ma l'unica volta che ho lasciato un progetto per sempre è quando ho cambiato lavoro.

Ricorda però che il tempismo di queste cose è compito del project manager. Se sei precipitato a rispettare una scadenza, è colpa del PM. Fallo nel modo giusto, fallo una volta e fallo con calma e in modo corretto. La vita è troppo breve per qualsiasi altra cosa.

Tutte le altre risposte pubblicate qui sono buone. Vorrei aggiungere che, in qualità di sviluppatore del progetto, sei l'amministratore (protettore) del design.

Se non difendi la soluzione tecnica adeguata, nessun altro te lo prometterò. Dovresti sempre discutere per fare le cose nel modo giusto per il tuo capo e il Primo Ministro dovrebbe sempre discutere a favore della scadenza.

Eventualmente, se si fa parte di un'organizzazione ragionevole, verrà raggiunto un compromesso che aiuta a rispettare le scadenze e allo stesso tempo non si allontana troppo dal progetto.

Detto questo, non dare per scontato che se la scadenza del PM non viene raggiunta, il mondo finirà e il progetto fallirà. Di solito non è così in bianco e nero e il più delle volte la scadenza del PM è morbida e ha spazio per la regolazione.

Quasi tutte le scadenze a cui sono mai stato sottoposta a un programma PM erano per lo più artificiali. Lo difenderanno con le unghie e con i denti e faranno finta altrimenti, perché se il PM dovesse rispettare la scadenza, allora il PM GUARDA MALE!

Solo perché il PM ha un bell'aspetto non significa che il progetto sia fallito. Se lo capisci, sarai sorpreso di quanto riesci a far piegare un PM.

Cita il cliente per il design accurato. Se quella citazione è inaccettabile per loro, allora analizza il costo di ciascun componente (di solito costa == tempo di sviluppo). Lasciateli togliere gli articoli "a la carte" se lo desiderano. Molti salteranno a rasare il tempo per cose "inutili" come test e progettazione. Spiegare i rischi di questo approccio, ma se accettano il rischio, procedere come indicato. Se avrò abbastanza soldi per una macchina del clunker, allora comprerò una macchina del clunker, anche se so che probabilmente si guasterà tra 8 mesi. Il cliente ha la responsabilità di soppesare questi rischi e di accettarne le conseguenze.

L'unica cosa che non vuoi fare è dire al cliente di pensare di avere un software ben progettato, quando hanno pagato (e ricevuto) solo un pezzo di spazzatura non testato. Se qualcosa va storto (cosa che probabilmente succederà), nel primo scenario sembreranno cattivi, ma nel secondo scenario sembrerai cattivo.

Non va mai bene, ma a volte devi scendere a compromessi per completare un progetto. La triste realtà è che la maggior parte degli uomini d'affari sono completamente ignoranti e sono più che disposti a sacrificare la manutenibilità in seguito per qualcosa in questo momento. Il trucco è saper trovare un equilibrio; forse il progetto non sarà pulito come potrebbe essere, ma fintanto che non è un porcile è un degno compromesso.

Dipende interamente dalla domanda "Probabilmente tu o qualcun altro vorrete modificarlo in seguito?" Se sì, dovresti provare ad avere un design "pulito", altrimenti rischi di dover buttare via tutto e ricominciare 6 mesi dopo.

Certo, puoi portare la pulizia troppo lontano, ma generalmente un po 'di pulizia ti salverà il lavoro in seguito.