Esistono standard di codifica per rendere i team più produttivi. In teoria, rendono il codice più facile da capire, modificare e testare. In pratica, possono creare una quantità pericolosa di meta-lavoro; i team riscrivono continuamente il codice esistente alla ricerca della soluzione più corretta ed elegante. Sfortunatamente, il problema del meta-lavoro sembra peggiore nei team in cui tutti sono impegnati, appassionati e ossessionati dal fare la cosa giusta.
Come consulente che passa da un progetto all'altro, ho trovato che l'eccellente disciplina con uno standard di codifica rigido contribuisce molto meno al successo di un progetto rispetto agli sviluppatori eccellenti che sono interessati ai risultati. Gli stili di codifica incoerenti sono un fastidio per gli sviluppatori incredibili. Sono produttivi con o senza coerenza. Certo, se incontrano codice incoerente, chiedono dello standard attuale e lo seguono. Tuttavia, non insistono nell'aggiornare ogni riga di codice del progetto allo standard corrente. Non insistono perché hanno visto le migliori pratiche andare e venire. Il modo corretto di fare qualcosa oggi non è lo stesso del modo corretto di fare qualcosa domani. Se lo fosse, i tuoi standard di codifica non si evolverebbero. Quindi, se il modo corretto di fare qualcosa cambia nel tempo, forse la nostra definizione di "corretto" è rotta.
Questo non vuol dire che gli standard non contano. Basta tenere a mente che l'obiettivo degli standard è la produttività. Se non è possibile garantire la riscrittura a un nuovo standard si ripagherà a lungo termine, quindi non perdere tempo. È molto più facile giustificare un nuovo standard nel codice nuovo o refactored. L'eleganza è bella ma non è la stessa cosa dei risultati.