Il consiglio "scrivi un codice di qualità" si applica alle aziende di qualsiasi dimensione? [duplicare]

Bene, questa è una grande domanda forse troppo grande per il sito. Ma concentriamoci su alcuni dei punti chiave.

Is quality worth it?

Questa domanda di stackexchange contiene alcuni dettagli sul costo dei bug a seconda di quando sono stati trovati Per farla breve, i bug tendono a costare un ordine di grandezza in più da correggere ogni volta che passano dallo sviluppo al QA alla convalida dei clienti sul campo. Spendere un dollaro per correggere un bug durante la programmazione ti consente di risparmiare migliaia di dollari necessari per correggere il bug nel campo.

A tal proposito, ne vale sempre la pena. Il codice di alta qualità costa meno da fare rispetto a un codice di bassa qualità da creare e quindi correggere in un secondo momento.

Supponendo che intendi correggere i bug. Il livello di qualità necessario per un reattore nucleare è diverso dal livello di qualità necessario per il tuo clone di Angry Birds. Avere qui troppa qualità può essere un fardello e rendimenti decrescenti, naturalmente. Ma se hai intenzione di correggere i bug, costano quasi sempre meno problemi durante lo sviluppo.

Should we hire the best developers?

Probabilmente no. I soliti "risparmi sui costi" dei buoni sviluppatori provengono da due parti:

1. Meno bug : vedi sopra. Il numero minore di bug prodotto dallo sviluppo è un risparmio sui costi per l'azienda.
2. Funzioni straordinarie : gli sviluppatori di livello superiore possono fare cose straordinarie che gli sviluppatori "medi" semplicemente non possono. Google non sarebbe google senza fare in modo che un motore di ricerca salti davanti agli altri al momento.

Il problema deriva dal fatto che la maggior parte dei lavori di programmazione non sono con aziende tecnologiche. Stanno creando siti web di vaniglia o eseguendo operazioni di scarico dati da un punto a un altro. Gli sviluppatori mediocri sono perfettamente in grado di implementarlo.

Meno errori sono un po 'un problema relativo. Uno sviluppatore del 99 ° percentile può catturare tutti i bug, ma se stai facendo un lavoro piuttosto semplice, uno sviluppatore del 75 ° percentile può catturare tutti gli errori a metà del costo.

A tal proposito, non ne vale sempre la pena.

Small teams just can't make quality software.

I team di piccole dimensioni non possono creare software di qualità solo quando non sacrifica l'ambito o la pianificazione . Esistono tre leve per la gestione del software: costi, ambito e pianificazione. Se i tuoi costi devono essere piccoli e desideri una qualità elevata, hai bisogno di più tempo o di meno funzionalità. Se la tua azienda vuole sacrificare la qualità per più funzioni o una pianificazione più rapida ... Questa è la loro scelta, ma non c'è niente forzare piccoli team a creare codice errato .

Questa scelta è ragionevole in alcuni scenari? Sicuro. Ho visto scenari in un ambiente di avvio in cui il time to market è così importante / prezioso che ha senso tagliare gli angoli ora. In molti casi di avvio, essere il primo sul mercato è di valore pressoché infinito. La grande idea viene associata alla tua azienda e la seconda entrata sul mercato non ha alcuna possibilità, dal momento che tutti vogliono la nuova cosa sexy - non la copia.

Quindi, in sintesi, probabilmente non è sempre che valga la pena di assumere sviluppatori di alto livello e realizzare software di alta qualità. A volte il software di bassa qualità ora è più prezioso. E gli sviluppatori medi che assumono saranno un modo più economico di produrre software "abbastanza buono" a seconda del costo relativo e della produttività di quegli sviluppatori. Ma direi che per la maggior parte degli scenari, i software di qualità (e per estensione, buoni sviluppatori) sono il modo più economico per fare affari.

Penso che dovrebbero cercare di ottenere il meglio, ma ciò che è meglio in alcune situazioni non si applica agli altri. Dipende dalla gestione dell'azienda / gruppo di sviluppo, ma le aziende di dimensioni diverse possono tipicamente avere questi problemi per diversi motivi. Nel libro "Dreaming in Code", il loro progetto aveva talento, tempo, denaro e il desiderio di creare qualcosa di grande, ma avrebbero potuto essere migliori con un programmatore piuttosto buono invece del pacchetto di sviluppatori 10x che è riuscito a creare un gran casino che ci è voluto per sempre.

Prototype - Se dovessi ottenere i requisiti dal lato business di un avvio, probabilmente sembrerebbe più simile a un prototipo, ma cerca di convincere uno sviluppatore di ciò quando lo rilasci in libertà . Ciò non significa che non trarrà beneficio da un programmatore 10x. Penso che uno dei maggiori fattori in questo rapporto di sviluppo "10: 1" sia la capacità di costruire cose che i programmatori minori non possono fare (1000: 1?). Molte grandi aziende hanno progetti come startup e possono subire lo stesso destino.

Abbastanza buono da dire "No" I bravi programmatori si trovano in una posizione migliore per rifiutarsi di scrivere codice errato. Hanno sperimentato le conseguenze negative di prima mano e sono più bravi a persuadere i poteri che sono, ma non mi interessa quanto sei bravo, se il business ti spinge abbastanza, scriverai cazzate. Le scadenze arbitrarie sono il motivo per cui c'è abbastanza tempo per farlo invece di farlo "correttamente" la prima volta. Le aziende più grandi hanno molti manager che non hanno niente di meglio da fare che continuare a chiedere quando le cose stanno per finire.

Abitudini della migliore pratica I bravi programmatori sviluppano scioltezza e buone abitudini perché studiano, impiegano il tempo necessario per imparare, ma la maggior parte di tutti ci crede. Non perdono tempo a pisciare ea lamentarsi: test, documentazione, controllo del codice sorgente, bug tracking, revisione del codice e standard. Sanno come questo rende più facile il tuo lavoro. Potrebbero non conoscere molte lingue, ma non è perché si rifiutano di usarle. C'è una differenza. Migliaia di sviluppatori sono in grado di essere produttivi con Git, cosa ti rende così speciale? Le grandi aziende possono assumere sviluppatori di molti livelli e dovrebbero creare un programma di apprendistato, ma solo perché scrivi codice 10x non significa che hai la capacità di sfruttare il tuo talento e insegnare agli altri.

Assunzione

1. Attrazione del talento - Molte posizioni sono poco interessanti per i bravi programmatori. Parte di esso è salariale, ma considera anche il resto di questa lista. Alcuni preferiscono aziende stabili, altri vogliono una startup. Le società tecnologiche sono solitamente più attraenti di quelle di altri settori.
2. Capacità di riconoscere il talento. I bravi programmatori vogliono lavorare con altri bravi programmatori o almeno potenzialmente con ottimi programmatori. Una compagnia può fare una scoperta fortunata, ma raramente possono costruire una squadra completa. Le aziende più grandi costruiranno personale delle risorse umane che è bravo a ingaggiare talenti di base (non tecnici), ma non hanno alcuna idea di assumere programmatori. A volte si affidano a reclutatori.
3. Mantenere il talento - Perché assumere i migliori sviluppatori se non hanno il controllo? Chi sta prendendo queste cosiddette decisioni migliori? La gente creativa lotta sulla catena di montaggio. Non mentire e dire loro che è necessaria immediatamente una nuova funzione per chiudere la prossima vendita quando in realtà, è solo un piacere avere. Talento alla fine se ne andrà. Le aziende non tecniche / creative lottano perché cercano di far funzionare i programmatori come tutti gli altri.
4. Riconoscimento del codice buono - La maggior parte del codice scritto non è mai stato visto da nessun altro che scrive codice. I clienti vogliono risultati. A volte è possibile convincerli che una nuova funzionalità sarà difficile a causa del drastico cambiamento dei requisiti, quando in realtà il codice è mal progettato.

La maggior parte delle aziende si accontentano di talenti minori perché hanno solo tutti gli altri bagagli richiesti invece delle competenze necessarie per svolgere il lavoro. "Non vogliamo qualcuno che sieda in un angolo e scriva codice." Molti sviluppatori non brillano nel "Parlami di te stesso". domanda, ma semplicemente ama parlare delle cose che costruiscono. Ho visto un ragazzo seduto tranquillamente a una cena, ma quando ha iniziato a mostrare all'host come allungare le dimensioni dello schermo per utilizzare tutto lo spazio sul monitor, ho pensato che fosse in vendita. Era persino in grado di farlo con una maglietta nera - The Horror.

Il problema con molte aziende è che sono meno interessati a far scrivere alle persone codice di qualità che a scrivere "codice di qualità sufficientemente buono", ad es. codice che fa appena il lavoro. In questo contesto, avere due persone per controllare il lavoro a vicenda sembra una scommessa più sicura che assumerne uno.

Per convincere le persone a scegliere te, devi convincere i clienti che 1) solo il codice di alta qualità farà il lavoro e 2) sei un fornitore di tale codice di alta qualità. Il secondo è forse un "vendere" più facile del primo. Se ti capita di essere un sottocampo in cui "chiunque" può scrivere un codice "adeguato", potrebbe essere una sfortuna per te. Quindi dovresti trovare una nuova area in cui lo standard minimo è più alto e richiede il tuo livello di abilità.

La qualità del codice non riguarda se vale o no, è un modo di fare le cose. Il codice di qualità vale sempre la pena.

Se un'azienda non se ne preoccupa, questo ti dà un indicatore chiave del fatto che non è una buona società di sviluppo software, è semplicemente un'altra società di software. Le buone aziende cercano di refactoring ogni pezzo di codice che non è molto mantainable o architectured.

Non scriverai mai il codice perfetto, ma come facciamo in ogni aspetto della nostra vita, devi ricontrollarlo, refactarlo e utilizzare alcuni strumenti per aiutarti a seguire le migliori pratiche.