I sette peccati capitali dello sviluppo software

I team di sviluppo software non sono tutti uguali. Alcuni lavorano in modo eccellente, alcuni aspirano a lavorare in modo eccellete, altri invece non riescono e nemmeno provano a lavorare in modo funzionale. Non importa che si tratti di team di sviluppo "agili" o che seguano metodologie differenti, ci sono alcuni comportamenti che portano lavorare in modo non ottimale.
Provate a cercare nel vostro gruppo di lavoro i segni del peccato e fate il possibile per rimediare, la salvezza è dietro l'angolo.
Lussuria  In un team di sviluppo si manifesta sottoforma della continua corsa all'uso delle tecnologie all'ultima moda. Un nuovo linguaggio di programmazione, l'ultimo framework, nuove piattaforme... Un ingegnere è curioso per natura, alla continua ricerca dell'efficienza e con il desiderio che tutto sia ottimizzato. Il continuo desiderio di migliorarsi, di formarsi e di rimanere al passo con i tempi è lodevole, ma porta con sé un costo: la curva d'apprendimento. Passare ad una nuova tecnologia porta con sè problemi di retrocompatibilità, dipendenze non soddisfatte e non considerate inizialmente oltre a tutti i problemi che nemmeno si possono prevedere. Eliminando la distrazione del "sempre tutto ciò che è nuovo" è possibile concentrarsi maggiormente sul cercare soluzioni per problemi concreti e puntare solo sulle nuove tecnologie che realmente servono e portano vantaggi concreti.
Gola Questo è il peccato legato all'eccesso: si prova a fare troppo allontanandosi dal proprio obiettivo. Si introducono troppe funzionalità non necessarie, si scrivono pagine e pagine di codice senza che serva veramente e si perdono ore e ore di lavoro. Questo comportamento porta ad avere codice complesso, alti costi di manutenzione, l'introduzione di bug e spesso a non riuscire a rispettare le scadenze. Cercate di mantenere il vostro prodotto pulito individuando in tempo le funzionalità indispensabili e quelle non richieste evitando così l'aumento della complessità dell'architettura.
Avarizia
Eccessiva specializzazione e creazione di compartimenti chiusi ed individualisti: "il mio codice", "il mio modulo", "la mia area di competenza", nessuna condivisione e nessuna collaborazione.
Una forte dipendenza nei confronti di chi si definisce "Guru" o "Ninja" di una tecnologia può portare ad un ambiente di questo tipo.
Al contrario bisognerebbe favorire un ambiente in cui il codice è proprietà di tutti e spingere sulla collaborazione tra i membri del team grazie a tecniche di pair programming o peer review.
Pigrizia
Secondo Larry Wall, l'inventore del Perl, la pigrizia è una delle tre grandi virtù dei programmatori.
Ma la pigrizia non deve essere confusa con l'apatia. Lasciare un bug senza correzione troppo a lungo, dimenticare nei propri sorgenti codice scritto male, non ottimizzare le funzioni e scrivere codice duplicato sono solo alcuni esempi.
Bisognerebbe riuscire a sentire l'urgenza di risolvere questi tipi di problemi durante ogni fase del ciclo di sviluppo. Non sono futili dettagli, sono parte integrante di un buon metodo di sviluppo e dell'ingegneria del software.
Ira
In alcuni posti di lavoro ci sono persone, spesso  qualificate, che tutti rispettano e temono in eguale misura. 
Solitamente queste persone si gettano di peso usando qualunque mezzo possibile in modo da ottenere ciò che vogliono, mentre chi gli sta intorno cerca di evitare di tirare fuori argomenti controversi in loro presenza.
La loro rabbia è spesso fuorviante, umiliano ed accusano le altre persone "avvelenando" l'ambiente di lavoro.
Bisogna stare attenti a questo tipo di persone che prosperano sullo scontro ingiustificato. Rifiutare di essere soggetti a queste ire e sostituire queste persone è una delle cose migliori da fare per lavorare in un ambiente migliore.
Invidia
Al posto di essere contenti dei propri mezzi e dei sistemi con cui si lavora, alcuni team non fanno altro che continuare a guardare ciò che hanno gli altri. Si può quindi decidere di iniziare ad usare un nuovo sistema di wiki affiancandolo a quello corrente per verificare se il sistema di editing è migliore, duplicare i ticket su due sistemi di tracking per vedere se quello nuovo si integra meglio con il sistema di versionamento, iniziare ad usare una nuova chat e altro ancora.
È positivo adottare un nuovo prodotto se non si è soddisfatti di uno strumento che si sta usando e si pensa che quello nuovo possa incrementare la produttività, ma la cosa più importante è essere sicuri della propria scelta, migrare i dati ed iniziare ad utilizzare solo il nuovo prodotto abbandonando il vecchio. Rimanere bloccati in una situazione per cui metà dei compiti vengono eseguiti su una piattaforma e metà su un'altra genera solo confusione e rallenta il lavoro.
Superbia
Alcuni team con un livello troppo alto di esperienza e troppo confidenti nelle proprie capacità possono arrivare al punto di non chiedere mai aiuto o consiglio all'esterno finendo per diventare un problema al posto che una valida risorsa.
Ancora peggio se un gruppo arriva a pensare di poter portare a termine qualunque tipo di attività. Nonostante alcuni siano in grado di farlo, si corre il rischio che commettano errori o che non riescano a sopportare l'eccessivo carico di lavoro.
Questi gruppi possono arrivare a non capire quali sono le attività importanti da portare a termine e quali no: iniziano a montare i propri server al posto di utilizzare il cloud, reinventano i propri strumenti di sviluppo al posto di usare quelli conosciuti e funzionanti, sviluppano i propri framework duplicando quelli già esistenti... Certamente queste attività sono divertenti ed interessanti e a volte possono portare ad innovazioni, ma dal punto di vista di un'azienda significa maggior tempo necessario prima di poter vedere terminato il prodotto che realmente serve per il business e che genera profitti.