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

Ricorda che sei impiegato per supportare un'azienda. In qualche modo, il tuo software sta influenzando la linea di fondo del business. È necessario trovare un equilibrio tra una soluzione tecnicamente perfetta, il time to market del prodotto e i benefici che ne deriveranno.

Nella mia esperienza, gli sviluppatori spesso rimangono bloccati dal preoccuparsi della perfezione tecnica. Ma ci sono motivi molto validi per sacrificare attributi di qualità come la manutenibilità o le prestazioni al fine di ottenere un prodotto fuori dalla porta più veloce. Dipende dal business 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 mirare a quel target.

Il termine "debito tecnico" è molto utile per aiutare a prendere decisioni aziendali come questa. Qualsiasi lavoro che non fai ora causerà un po 'di lavoro in seguito. Proprio come con le finanze, assumere debiti è rischioso, ma potrebbe valere la pena di fare leva se si sarà in grado di rimborsare 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 risolvere dopo il rilascio e l'impatto sulla produttività futura durante lo sviluppo da un sistema legacy disordinato può essere eccessivo. Potresti pensare di dedicare il doppio del tempo a correggere i tuoi errori, o forse 1.000 volte il numero di ore / uomo e risorse.

Il tuo lavoro in questa decisione è capire le ramificazioni dei particolari pezzi di taglio che stai prendendo in considerazione e quindi comunicare quelle ramificazioni alle persone che prendono la decisione aziendale. Questa particolare abilità di stima potrebbe richiedere un sacco di ricerche e di lavoro da parte tua per svilupparsi bene in questo momento, ma sarà prezioso durante la tua carriera.

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

Un idraulico deve prelevare un tritarifiuti per la riparazione. Voglio usare il lavandino nel frattempo, ma avrebbe dovuto fatturarmi per il tempo e i materiali da inserire in tubi temporanei usando del nastro che potrebbe rompersi. Questo ritarderà anche il ritiro dello smaltimento all'officina. Se accetto la fatturazione aggiuntiva con la consapevolezza che rischio uno zoccolo. Ci vorrà un giorno in più per ottenere lo smaltimento riparato e un ritardo ancora maggiore prima che possa rimetterlo, è accettabile.

Ora puoi avere tempo e denaro, ma sacrificare / rischiare un costo ancora più elevato nel lungo periodo. Questo può essere difficile da capire per le persone non tecniche, ma è quello che serve lo staff di vendita.

Molte persone abbandonano rapidamente il modo di imparare qualcosa di nuovo e lo fanno semplicemente nel modo in cui lo hanno sempre fatto. Se questo è uno schema, non solo il tuo codice subirà ma le tue capacità di programmatore rimarranno limitate.

Eppure, alla fine della giornata, l'unico software di successo è quello che spedisce.

Dopo il termine morbido passa. E anche allora è un grado molto basso di "OK". Dopo che la dura scadenza è passata è, ovviamente, discutibile. Perché questa è la natura delle scadenze difficili.

Inoltre, ciò comporta un debito tecnico. Per ogni ora / giorno che passi a tagliare gli angoli nella mentalità git-er-made, ti costerà all'incirca il doppio del tempo in cui dovresti toccare questo progetto. Se è necessario, allora è meglio precipitarsi, spedire e subito iniziare a sistemare tutto il nastro anatra. Ritornare a un progetto incantato anni dopo è un incubo. Se non lo toccherai mai più, così sia, a nessuno importa. Ma l'unica volta in cui ho lasciato un progetto per sempre è quando ho cambiato lavoro.

Ricorda però che la tempistica di queste cose è compito del project manager. Se ti affretti a rispettare una scadenza, è colpa del PM. Fallo bene, fallo una volta e fallo in modo calmo e corretto. La vita è troppo breve per qualcos'altro.

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

Se non ti schieri dalla soluzione tecnica adeguata, nessun altro te lo garantirò. Dovresti sempre argomentare per fare le cose nel modo giusto al tuo capo e il PM dovrebbe sempre discutere a favore della scadenza.

Speriamo che se ti trovi in una organizzazione ragionevole, verrà raggiunto un compromesso che ti aiuterà a rispettare le scadenze e non allontanarti troppo dal design allo stesso tempo.

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 è in bianco e nero e la maggior parte delle volte la scadenza del PM è morbida e ha spazio per la regolazione.

Quasi tutte le scadenze per le quali ero mai stato coinvolto in un programma pomeridiano erano per lo più artificiali. Lo difenderanno con le unghie e con le mani e fingranno il contrario, tuttavia, perché se il PM spinge la scadenza, allora il PM sembra CATTIVO!

Solo perché il PM sembra cattivo non significa che il progetto abbia fallito. Se lo capisci, rimarrai sorpreso di quanto puoi far piegare un PM.

Cita il cliente per il design pulito. Se quella citazione è inaccettabile per loro, allora vai nella ripartizione di ciò che ogni componente avrà un costo (di solito costo == tempo di sviluppo). Lascia che prendano gli oggetti "a la carte", se lo desiderano. Molti salteranno a tempo di radere per cose "inutili" come test e design. Spiega i rischi di questo approccio, ma se accettano il rischio, procedi come indicato. Se ho solo abbastanza soldi per una macchina da clunker, allora comprerò una macchina da clunker, anche se so che probabilmente si romperà in 8 mesi. Il tuo cliente ha la responsabilità di soppesare questi rischi e accettarne le conseguenze.

L'unica cosa che non vuoi fare è dire di lasciare che il cliente pensi di avere un pezzo di software ben progettato, quando ha pagato (e ricevuto) un pezzo di spazzatura non testato. Se qualcosa va storto (cosa che probabilmente succederà), nel primo scenario avranno un bell'aspetto, ma nel secondo scenario sembrerai cattivo.

È mai okay, ma a volte devi scendere a compromessi per il completamento di un progetto. La triste realtà è che la maggior parte degli uomini d'affari sono completamente ignoranti e sono più che disposti a sacrificare in seguito la manutenibilità per qualcosa in questo momento. Il trucco è sapere come raggiungere un equilibrio; forse il progetto non sarà così pulito come potrebbe essere, ma finché non è un porcile è un compromesso degno.

Questo dipende interamente dalla domanda "Preferirai o meno a qualcun altro volerlo modificare in seguito?" Se sì, dovresti provare ad avere un design "pulito", altrimenti rischi di dover buttare tutto fuori e ricominciare 6 mesi dopo.

Ovviamente, puoi essere troppo preciso, ma in generale un po 'di pulizia ti farà risparmiare tempo dopo.