Respostas:
Anos atrás, eu era o desenvolvedor líder de um aplicativo centrado no banco de dados que começou a gerar erros. Eu rastreei até o fato de que havia valores duplicados em um campo do banco de dados que não deveriam ter permitido.
Eu estava me esquecendo de esquecer de definir uma restrição exclusiva no banco de dados quando o coloquei em produção, porque era tão óbvio que esse campo precisava de um. Eu comiserava com um dos meus colegas desenvolvedores que me corrigiram ...
Outro desenvolvedor : "Ah, você não se esqueceu, havia uma restrição exclusiva nesse campo. Acabei de removê-lo."
Eu : "Por que você o removeu?"
Outro desenvolvedor : "Eu fiz isso algumas semanas atrás. Estava recebendo arquivos de dados do cliente e eles não foram importados porque a restrição exclusiva estava bloqueando os novos dados. Portanto, removi a restrição para poder concluir a importação".
Eu: "Você parou para considerar que talvez houvesse um problema se estávamos obtendo novos dados que se sobrepunham aos dados existentes e pensamos em mencioná-los a alguém antes de importá-los?"
Outro desenvolvedor : (blank stare)
Eu : Facepalm.
Não tenho certeza se isso conta como uma decisão de tecnologia , mas fui responsável por um site de gerenciamento de documentos semelhante ao CMS, escrito em PHP por quatro anos. Ao longo desses anos, tentei várias vezes levar as pessoas (gerentes, usuários, solicitantes de recursos) a talvez, possivelmente, como, talvez , considerar a possibilidade de sentar juntos e pensar nos requisitos e na direção futura da coisa. Isso nunca aconteceu. Sempre foi "adicionar esse recurso", "adicionar esse recurso", e todos sabiam alegremente todas as diferentes maneiras pelas quais todos os outros usavam o site. Quando saí, tornou-se uma enorme bagunça de recursos interconectados, mas não relacionados, e eu era o único em toda a empresa que conhecia todos os recursos. Agora, ninguém faz. Mwahaha.
Reescrevendo um sistema de correio de voz de qualidade Telco.
O sistema anterior estava rodando em Unix e por volta dos anos 90 surgiu a tecnologia COM da Microsoft. Muitos desenvolvedores estavam trabalhando neste novo sistema baseado em NT. Depois de muito esforço, seu desempenho ainda não era o mesmo do sistema Unix e um grande cliente que comprou esse novo sistema estava chateado. A empresa teve que ser vendida e algumas pessoas tiveram que deixar a empresa.
Foi feio. Tudo isso aconteceu cerca de dois anos antes de Joel escrever seu artigo: Coisas que você nunca deve fazer, parte I
Adotar uma biblioteca externa (neste caso, o Spring RCP ) antes de sua primeira versão, com base em um instantâneo SVN. É praticamente garantido que o projeto acabará mais ou menos morto e você se encontrará amarrado ao cadáver. Bem, no nosso caso, poderia ter sido pior. Ainda é um grande risco.
Um exemplo que me lembro envolveu o comprometimento com um servidor de aplicativos Java específico desde o início, apesar de ele ainda não possuir os recursos necessários para o projeto, apenas um roteiro para quando eles seriam implementados. Naturalmente, o fornecedor não entregou tão rapidamente quanto o indicado originalmente, o que deveria ter sido um grande problema, mas na realidade foi apenas uma das muitas trepadas no caminho lento para o fracasso.
A maioria dos casos desse tipo de problema que encontrei envolveu o comprometimento com uma tecnologia não comprovada / imatura, geralmente porque alguém influente no lado técnico é um proponente do desenvolvimento orientado pelo currículo.
Há três anos, nosso departamento BusDev disse que precisavam desenvolver seu sistema de gerenciamento de conteúdo no Documentum porque as empresas farmacêuticas que estavam tentando acessar conheciam o nome e estavam confortáveis com a tecnologia. Então gastamos muito dinheiro para construí-lo e arquivamos 12 meses depois.
Em fevereiro deste ano, eles anunciaram que o novo sistema seria baseado no Sharepoint 2010. Quer adivinhar por quê? Porque, de repente, ESTE era o nome conhecido pela Pharmas e com o qual eles estavam confortáveis!\\ uSlackr
Escrevendo sistemas operacionais modernos em C / C ++. Sabemos desde o Morris Worm (final dos anos 80) que é uma linguagem completamente inadequada para a criação de software em rede, mas isso não impediu ninguém de fazê-lo, o que basicamente significa IMO por negligência criminal.
std::string, mas funciona, e junto com os modelos de classe de contêiner pode eliminar uma grande classe de erros em potencial.
O que eu vi....
Na década de 1980, havia uma empresa chamada Prime que produzia computadores executando uma versão do banco de dados Pick e BASIC. O departamento de usuários do local em que eu trabalhava na época em que comprei um estava absolutamente convencido de que isso economizaria muito dinheiro, que eles obteriam o processamento e os resultados desejados com um analista de negócios em um quarto de tempo. Não demorou muito para que houvesse quatro analistas de programadores em tempo integral e um atraso no trabalho.
Grande erro ao estimar o que a tecnologia faria por eles.