Per rispondere a questa domanda riporto il parere di Bram Moolenaar , un programmatore di computer olandese e membro attivo della comunità del software open source. Bram è l'autore originale, il manutentore, il responsabile dei rilasci e il "benevolo dittatore a vita" di Vim , un editor di testo molto popolare tra i programmatori e gli utenti esperti nonché l'editor che utilizziamo quotidianamente in Garda Informatica.
In una recente intervista pubblicata qui gli è stato chiesto "Secondo te, lo sviluppo del software è più vicino all'arte o alla scienza?" e lui ha risposto:
Non vedo molta scienza nello sviluppo del software. La scienza implica che c'è la prova che qualcosa sia vero. Nel software ci sono molte opinioni e c'è l'esperienza, ma c'è qualche prova che un linguaggio di programmazione sia migliore di un altro? Ci sono prove che la programmazione orientata agli oggetti (OOP NdA) si traduca in una migliore produttività? La maggior parte delle prove riguardano misurazioni delle prestazioni e ci sono statistiche, ma quasi nessuna relazione con il linguaggio in cui è stato scritto un programma o quali strumenti sono stati utilizzati. Non è nemmeno arte, dal momento che l'obiettivo principale è che il software funzioni bene, non che sia bello. È piuttosto un lavoro di artigianato. E un artigiano usa tutti gli strumenti che pensa gli faranno ottenere il miglior risultato, non importa se sono quelli che usano tutti gli altri o qualcosa di diverso. E un buon artigiano crea i suoi strumenti quando necessario.
In Garda Informatica la pensiamo esattamente come il buon Bram e riteniamo che molto spesso nel mondo dello sviluppo software si prendano per buone delle pratiche solo perché vanno di moda e non perché sia stato dimostrato scientificamente che sono la soluzione migliore.
Tenersi aggiornati è fondamentale, ma valutare le novità con pensiero critico è molto importante per non sottovalutare il dispendio di energie necessario per padroneggiare un nuovo paradigma di programmazione, un nuovo linguaggio o un nuovo framework.
Col tempo ci siamo infatti accorti che molto spesso le promesse di "ridurre la complessità" adottando questo o quel framework/metodologia/linguaggio sono vane.
Nei casi reali la complessità di fatto non può essere evitata e, come suggerisce Bram, molto spesso è più efficace crearsi i propri strumenti piuttosto che tuffarsi a capofitto nell'ultimo trend del settore.