Alcuni anni fa, ho lavorato per una piccola azienda che è andata così avanti nello sviluppo di strutture interne che hanno dedicato il loro sviluppatore più anziano e il loro architetto allo sviluppo di un framework MVC personalizzato e di un ORM da zero. Queste due cose erano ortogonali al loro prodotto principale. Sfortunatamente il supporto per questo approccio guidato dal framework è arrivato dall'alto e ha ritardato l'erogazione di software che genera reddito, e le strutture prodotte erano notevolmente inferiori rispetto alle alternative standard, il che ha aggravato i ritardi. La compagnia ha bruciato rapidamente denaro e, alla fine, tutti sono stati licenziati.
Un successivo datore di lavoro ha commesso un errore simile - hanno uno sviluppatore altamente qualificato - un perfezionista, con una solida base nei modelli di progettazione aziendale per sovraintendere grossolanamente una soluzione di consulenza per uno dei loro clienti, consapevolmente con una perdita, in la speranza che la soluzione possa essere adattata ed estesa per altri clienti. Il progetto è stato superato in modo significativo. Ma nessun altro potenziale cliente ha morso. Un errore strategico placcato in oro che costa una piccola fortuna.
In entrambi i casi si è verificato un significativo grado di overengineering. In entrambi i casi, la società e la gestione del progetto erano persone con background di dominio o analisi, piuttosto che un background di programmazione. In entrambi i casi gli architetti del software hanno creato soluzioni troppo complesse per grattarsi i loro pruriti e migliorare i loro curriculum, con qualche complicità da una gestione non tecnica. In entrambi i casi gli architetti non avevano alcun interesse a contenere i costi (a parte il rischio di perdere il posto di lavoro in caso di bancarotta delle aziende, il che non rappresentava un grosso rischio, considerando la loro elevata occupabilità).
La mia esperienza suggerisce che non è una trappola insolita per i negozi di sviluppo.
C'è posto nei progetti software per un formale formale avversario interno o esterno - un "Quantity Surveyor" - per usare un'architettura analogica - che può richiamare, o prevenire una eccessiva ingegneria eccessiva? Chi è il più adatto a ricoprire questo ruolo?