Risposte:
Anni fa, ero lo sviluppatore principale di un'applicazione centrata sul database che ha iniziato a generare errori. L'ho rintracciato al fatto che c'erano valori duplicati in un campo di database che non avrebbero dovuto consentirli.
Mi stavo dando da fare per dimenticare di impostare un vincolo unico 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 ...
Altro sviluppatore : "Oh, non hai dimenticato, c'era un vincolo unico in quel campo. L'ho appena rimosso."
Io : "Perché l'hai rimosso?"
Altro sviluppatore : "L'ho fatto qualche settimana fa. Stavo ottenendo file di dati dal cliente e non li avrei importati perché il vincolo univoco stava bloccando i nuovi dati. Quindi ho rimosso il vincolo in modo da poter finire di importarlo."
Io: "Ti sei fermato a considerare che forse c'era un problema se stessimo ottenendo nuovi dati che si sovrapponevano a quelli esistenti e pensavi di menzionarli a qualcuno prima di importarli?"
Altro sviluppatore : (sguardo vuoto)
Io : Facepalm.
Non sono sicuro che questo valga come una decisione tecnologica , ma sono stato responsabile di un sito Web di gestione dei documenti simile al CMS scritto in PHP per quattro anni. Nel corso di questi anni, ho tentato più volte di convincere le persone (manager, utenti, richiedenti funzionalità) a forse, forse, come, forse , a considerare la possibilità di stare insieme e pensare ai requisiti e alla direzione futura della cosa. Non è mai successo Era sempre "aggiungi questa funzione", "aggiungi quella funzione", e tutti erano beatamente inconsapevoli di tutti i diversi modi in cui tutti gli altri usavano il sito web. Quando me ne sono andato, è diventato un enorme casino di funzionalità interconnesse ma non correlate, ed ero l'unico in tutta l'azienda che conosceva tutte le funzionalità. 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 arrivò la tecnologia COM di Microsoft. Molti sviluppatori stavano lavorando su questo nuovo sistema basato su NT. Dopo molti sforzi, le sue prestazioni non erano ancora vicine a quelle del sistema Unix e un grande cliente che acquistò questo nuovo sistema era incazzato. La società doveva essere venduta e alcune persone dovevano lasciare la società.
E 'stato brutto. Tutto ciò è accaduto circa due anni prima che Joel scrivesse il suo articolo: Cose che non dovresti mai fare, parte I
Adozione di una libreria esterna (in questo caso Spring RCP ) prima della versione della prima versione, basata su un'istantanea SVN. È praticamente garantito che il progetto finirà più o meno morto e ti ritroverai legato al cadavere. Bene, nel nostro caso avrebbe potuto andare peggio. Ancora un grosso rischio.
Un esempio che ricordo riguardava l'impegno iniziale verso un particolare server di applicazioni Java, nonostante non avesse ancora le funzionalità richieste per il progetto, ma solo una tabella di marcia per quando sarebbero stati implementati. Naturalmente il venditore non ha consegnato tempestivamente come originariamente indicato, il che avrebbe dovuto essere un grosso problema, ma in realtà era solo uno dei tanti errori sulla strada lenta verso il fallimento.
La maggior parte dei casi di questo tipo di problema che ho riscontrato hanno comportato l'impegno per una tecnologia non provata / immatura, spesso perché qualcuno influente dal punto di vista tecnico è un sostenitore dello sviluppo guidato dal curriculum.
Tre anni fa, il nostro dipartimento BusDev ha dichiarato di dover costruire il proprio sistema di gestione dei contenuti su Documentum perché le aziende farmaceutiche che stavano cercando di raggiungere conoscono il nome e si sono sentite 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 si sarebbe basato su Sharepoint 2010. Vuoi indovinare il perché? Perché, all'improvviso, QUESTO era il nome conosciuto da Pharmas e uno con cui erano a loro agio!\\ uSlackr
Scrivere moderni sistemi operativi in C / C ++. Sappiamo da quando Morris Worm (fine anni '80) è un linguaggio completamente inadatto per la creazione di software di rete, ma ciò non ha impedito a nessuno di farlo, il che equivale sostanzialmente a negligenza criminale IMO.
std::string, ma funziona, e insieme ai modelli di classe container può eliminare una grande classe di potenziali errori.
Cosa ho visto....
Negli anni '80, c'era una società chiamata Prime che produceva computer con una versione del database Pick e BASIC. Il reparto utenti del luogo in cui lavoravo al momento dell'acquisto era assolutamente convinto che ciò avrebbe risparmiato loro una gran quantità di denaro, che avrebbero ottenuto l'elaborazione e i risultati desiderati con un analista aziendale alla volta di un quarto. Non passò molto tempo prima che ci fossero quattro analisti programmatori a tempo pieno e un arretrato di lavoro.
Grande errore nello stimare ciò che la tecnologia farebbe per loro.