Proviamo a pensare a cosa normalmente accade in un gruppo di lavoro che deve affrontare un progetto Web non banale: più persone si trovano a lavorare insieme e a mettere in comune le proprie esperienze, i propri metodi di lavoro e le proprie abitudini, anche per quello che riguarda la scrittura del codice; ciascun membro del team avrà il suo modus operandi, frutto di anni di lavoro e del sul modo di “pensare” una pagina in X-HTML, e magari ciascuno di essi avrà familiarità con diversi strumenti di editing e di authoring e cercherà di promuovere nel gruppo le proprie convinzioni ed abitudini, è normale che sia così.

Il rischio è che il “leader” di turno cerchi di imporre il proprio modo di lavorare, oppure che ogni sforzo del team venga concentrato unicamente sull’ottenimento di un certo format grafico a discapito di altri requisiti ugualmente importanti come l’usabilità e l’accessibilità; quante volte un sito bello da vedere si presenta con funzionalità e contenuti non accessibili e/o usabili? E quante volte con una maggiore attenzione anche sulla qualità del codice si potrebbero ottenere pagine più snelle e fruibili con qualsiasi tipo di client?

In presenza di gruppi di lavoro variegati e di finalità complesse, la validità del codice – vista come una strada da seguire e da mantenere – può rappresentare un’ottimo “collante” per le varie professionalità in gioco, ed un punto di riferimento continuo e “non soggettivo” per l’intero team durante tutto il ciclo di sviluppo, in grado di favorire un risultato finale qualitativamente equilibrato.

In assenza di “paletti” di questo genere, il progetto potrebbe trovarsi privo di riferimenti oggettivi   (dal punto di vista delle specifiche sul codice da adottare) e finire col dirigersi verso aleatori Tag Soup.