Questo include decisioni di architettura, scelte di piattaforma o qualsiasi situazione in cui una scelta così cattiva ha portato a conseguenze negative.
Anni fa, ero lo sviluppatore principale di un'applicazione basata su database che ha iniziato a generare errori. Ho rintracciato il fatto che esistevano valori duplicati in un campo del database che non avrebbe dovuto consentirli.
Mi stavo riprendendo dal dimenticare di impostare un vincolo univoco sul database quando l'avevo spinto alla produzione perché era così ovvio che questo campo ne aveva bisogno. Ho commiserato con uno dei miei colleghi sviluppatori che mi ha corretto ...
Altri sviluppatori : "Oh non hai dimenticato, c'era un vincolo univoco su quel campo. L'ho appena rimosso."
Me : "Perché lo hai rimosso?"
Altri sviluppatori : "L'ho fatto poche settimane fa. Stavo ricevendo i file di dati dal cliente e non avrebbero importato perché il vincolo univoco stava bloccando i nuovi dati. vincolo in modo da poter terminare l'importazione. "
Io: "Hai smesso di considerare che forse c'era un problema se avessimo trovato nuovi dati che si sovrapponevano ai dati esistenti e pensavamo di menzionarli a qualcuno prima di importarli?"
Altri sviluppatori : (sguardo vuoto)
Me : Facepalm.
Non sono sicuro che ciò valga come una decisione della tecnologia , ma sono stato responsabile per un sito Web di gestione dei documenti simile a CMS scritto in PHP per quattro anni. Durante questi anni, ho tentato più volte di convincere le persone (manager, utenti, richiedenti funzionalità) a forse, forse, tipo forse , a prendere in considerazione la possibilità di stare insieme e pensare ai requisiti e al futuro direzione della cosa. Non è mai successo Era sempre "aggiungi questa funzionalità", "aggiungi questa funzionalità" e tutti erano beatamente inconsapevoli di tutti i diversi modi in cui tutti gli altro utilizzavano il sito web. Quando me ne sono andato, è diventato un enorme pasticcio di elementi interconnessi ma non correlati, e io ero l'unico in tutta la compagnia che conosceva ogni caratteristica. Ora, nessuno lo fa. Mwahaha.
Riscrivere un sistema di posta vocale di livello Telco.
Il sistema precedente era in esecuzione su Unix e verso la fine degli anni '90 la tecnologia COM di Microsoft è arrivata. Molti sviluppatori stavano lavorando su questo nuovo sistema basato su NT. Dopo un sacco di sforzi, le sue prestazioni non erano ancora vicine a quelle del sistema Unix e un grosso cliente che comprò questo nuovo sistema era incazzato. La compagnia doveva essere venduta e alcune persone dovevano lasciare la compagnia.
Era brutto. Tutto questo è accaduto circa due anni prima che Joel scrivesse il suo articolo: Cose che non dovresti mai fare, parte I
Adottare una libreria esterna (in questo caso essere Spring RCP ) prima della sua prima versione, basata su un SVN snapshot. È praticamente garantito che il progetto finirà più o meno morto e ti ritroverai legato al cadavere. Bene, nel nostro caso avrebbe potuto essere peggio. Ancora un grosso rischio.
Un esempio che ricordo riguardava il coinvolgimento tempestivo in un particolare server di applicazioni Java nonostante il fatto che non avesse ancora le funzionalità richieste per il progetto, solo una tabella di marcia per quando sarebbero state implementate. Naturalmente, il fornitore non ha consegnato il prontamente come originariamente indicato, il che avrebbe dovuto essere un grosso problema, ma in realtà era solo una delle tante chiacchiere sulla strada che porta al fallimento.
La maggior parte delle istanze di questo tipo di problemi che ho incontrato hanno comportato il coinvolgimento in una tecnologia non dimostrata / immatura, spesso perché qualcuno influente sul lato tecnico è un sostenitore dello sviluppo guidato dal curriculum.
Tre anni fa, il nostro dipartimento di BusDev ha dichiarato che dovevano costruire il loro sistema di gestione dei contenuti su Documentum perché le aziende farmaceutiche che stavano cercando di raggiungere conoscevano il nome e si sentivano a proprio agio con la tecnologia. Quindi abbiamo speso un sacco di soldi per costruirlo e poi lo abbiamo accantonato 12 mesi dopo.
A febbraio di quest'anno hanno annunciato che il nuovo sistema sarebbe basato su Sharepoint 2010. Vuoi indovinare perché? Perché, improvvisamente, QUESTO era il nome conosciuto da Pharmas e uno con cui stavano bene!\\ uSlackr
Scrittura di sistemi operativi moderni in C / C ++. Sappiamo da quando Morris Worm (alla fine degli anni '80) è un linguaggio completamente inadeguato per la creazione di software in rete, ma questo non ha impedito a nessuno di farlo, il che equivale sostanzialmente a una negligenza criminale IMO.
Quello che ho visto ....
Negli anni '80 esisteva una società chiamata Prime che produceva computer con una versione del database Pick e BASIC. Il reparto utenti del luogo in cui stavo lavorando nel momento in cui ne comprai uno era assolutamente convinto che ciò avrebbe risparmiato una gran quantità di denaro, che avrebbero ottenuto l'elaborazione e i risultati desiderati con un analista aziendale a un quarto di tempo. Non passò molto tempo prima che ci fossero quattro analisti programmatori a tempo pieno e un arretrato di lavoro.
Un grosso errore nella stima di ciò che la tecnologia farebbe per loro.
Leggi altre domande sui tag technology architect