Qual é um bom exemplo de uma idéia ou técnica de desenvolvimento de software que falhou?

Especificamente, quais são alguns exemplos de onde as idéias das massas estavam erradas. Por que as pessoas se apegaram às idéias em primeiro lugar? E por que as idéias foram descartadas? Ou talvez as idéias ainda estejam vivas e bem, e se sim, por quê?

Por exemplo, eu poderia descrever o CORBA (e outras tecnologias similares) como algo que tentou resolver o problema de comunicação entre os componentes do software. Muitos acharam necessário definir contratos entre vários componentes. Por fim, o HTTP + JSON resolveu o problema para as massas e outros mecanismos de RPC, como Thrift e Proto-bufs, apareceram.

Basicamente, assim como no mundo fora dos computadores, idéias e tecnologias competem por atenção, alavancagem etc. Alguns vencem, outros perdem; e alguns podem parecer o vencedor por algum tempo, depois desaparecem na obscuridade com o advento de The Next Big Thing. Pode ou não ter algo a ver com o que foi realmente melhor. Testemunhe VHS vs Betamax, ou a guerra mais recente entre os vários formatos de DVD.

O CORBA era enorme, desajeitado e difícil de usar, mas era o melhor que algumas pessoas podiam inventar na época (observe que ele foi desenvolvido antes da World Wide Web - e HTTP, Java, XML, ... - se tornar amplamente conhecido). E também era um exemplo clássico de design por comitê , onde eles se apegam a todas as idéias para satisfazer a todos, no final tornando-a inchada inutilmente (pelo menos vista pelos olhos de hoje). Sem mencionar seu preço, que com o advento do FOSS logo se tornou proibitivo.

Por fim, HTTP + JSON resolveu o problema para as massas

Pelo menos para alguém que não viu duas "soluções finais" semelhantes surgirem e finalmente caírem ... É bom lembrar que havia um sentimento semelhante sobre o CORBA em seu tempo ;-)

Eu sinto que é adequado citar The Rise and Fall of CORBA :

A história da CORBA é uma que o setor de computação já viu muitas vezes e parece provável que os atuais esforços de middleware, especificamente serviços da Web, reconstituam uma história semelhante. [...]

No geral, o processo de adoção de tecnologia do OMG deve ser visto como a principal razão do declínio do CORBA. O processo incentiva o projeto por comitê e manobras políticas a ponto de ser difícil alcançar a mediocridade técnica, sem falar na excelência técnica. Além disso, a adição de características desconexas leva a uma erosão gradual da visão arquitetônica. [...]

Um processo democrático como o OMG é excepcionalmente inadequado para a criação de um bom software. Apesar dos problemas processuais conhecidos, no entanto, o setor prefere contar com grandes consórcios para produzir tecnologia. Os serviços da Web, a atual bala de prata do middleware, usam um processo muito parecido com os OMGs e, por muitas contas, também sofrem com brigas internas, fragmentação, falta de coerência arquitetônica, design por comitê e inchaço dos recursos. Parece inevitável que os serviços da Web tenham uma história bastante semelhante à do CORBA.

Agora, de um ângulo diferente: ao ler seu termo "idéias das massas", pensei em coisas muito diferentes do que o CORBA ou outros padrões; estes são tipicamente a ideia de uma pessoa ou um pequeno grupo. Pensei em práticas notórias / pontos de vista como "codificação de cowboy", "codificar e orar", "funciona na minha máquina" etc. Essas são "ideias das massas" da IMHO, pois é assim que quase qualquer iniciante O desenvolvedor instintivamente começa a escrever código. E eles estão errados, pois não escalam nem no espaço nem no tempo - não é possível criar programas grandes, sustentáveis ​​e extensíveis dessa maneira. No entanto, sinto que, infelizmente, ainda é a norma e não a exceção para as pessoas tentarem trabalhar dessa maneira em lojas profissionais em todo o mundo.

O outro extremo disso são as idéias de muitos gerentes e teóricos sobre a "abordagem correta" para o desenvolvimento de SW, manifestando-se em grandes metodologias M, como CMM, RUP, Waterfall etc. A idéia subjacente a tudo isso é que tudo o que você precisa é o processo certo e começará a produzir automaticamente software de qualidade de maneira determinística, independentemente de quem são os desenvolvedores. Observe que o mesmo jogo também pode ser jogado usando métodos ágeis - é apenas uma mudança de rótulo. Qualquer gerente que acredita que selecionar (e manter) os membros certos para sua equipe de desenvolvimento é menos importante que o processo de desenvolvimento está fadado ao fracasso, qualquer que seja o processo. No entanto, essa crença no Processo ainda parece prevalecer - talvez ainda seja ensinada nas escolas de administração?

Um exemplo frequente de pessoas que deram errado é o modelo em cascata. Este é um diagrama do modelo estereotipado em cascata, que também aparece no artigo de Winston Royce "Gerenciando o desenvolvimento de grandes sistemas de software" .

Esta imagem é seguida por este texto:

Acredito nesse conceito, mas a implementação descrita acima é arriscada e causa falhas ... A fase de teste que ocorre no final do ciclo de desenvolvimento é o primeiro evento para o qual o tempo, armazenamento, entrada / saída, transferências, etc., são experiências distintas das analisadas. Esses fenômenos não são precisamente analisáveis. Não são as soluções para as equações diferenciais parciais padrão da física matemática, por exemplo. No entanto, se esses fenômenos falharem em satisfazer as várias restrições externas, será invariável uma grande reformulação. Um simples patch octal ou refazer algum código isolado não corrigirá esse tipo de dificuldade. As alterações de design necessárias provavelmente são tão perturbadoras que os requisitos de software nos quais o design se baseia e que fornece a justificativa para tudo são violados. Os requisitos devem ser modificados ou é necessária uma alteração substancial no design. De fato, o processo de desenvolvimento retornou à origem e pode-se esperar uma superação de 100% no cronograma e / ou custos.

Posteriormente, Royce apresenta modelos de processos alternativos que envolvem a iteração entre a fase atual e a fase anterior e um ciclo entre requisitos-análise-design e outro ciclo entre design-code-test. Ele também identifica uma série de documentos e durante as fases em que eles devem ser concluídos, e defende o envolvimento do cliente e várias quedas de água em cada fase para incluir análise, teste e uso de todos os artefatos envolvidos. Na verdade, o que Royce discute pode ser considerado uma abordagem inicial dos métodos ágeis - ainda muito orientada a planos, porém, mas uma base para o movimento ágil.

Por que as pessoas se agarraram à primeira cachoeira, eu não sei. Eu acho que eles gostam de correr riscos e convidar fracassos.

Geração automática de código a partir de um nível mais alto de abstração ou programação automática .

O artigo da Wikipedia carece de informações históricas, mas esse é um sonho dos gerentes desde que os programadores se tornaram mais caros que os computadores.

Após o desenvolvimento de linguagens de nível superior, como Fortran e Cobol, surgiu o desenvolvimento de linguagens para domínios especiais, como a elaboração de relatórios. Easytrieve e SAS foram alguns exemplos.

Durante a década de 1980, as ferramentas CASE foram a raiva. CASE significa engenharia de software auxiliada por computador. Pensava-se que a aplicação rigorosa dos princípios de engenharia tornaria o desenvolvimento de software mais rápido. O principal motivo pelo qual essas ferramentas não pegaram, além da despesa, foi o alto nível de padronização de dados exigido para que as ferramentas funcionassem efetivamente.

A Internet ganhou destaque nos anos 90. Os tipos de programação que a Internet facilitou explodiram. Os programadores eram obrigados a lidar com ilustrações, mapas, fotografias e outras imagens, além de animação simples, a um ritmo nunca antes visto, com poucos métodos conhecidos. O número de tecnologias para produzir esses objetos multiplicado. Sonhos de programação automática desapareceram.

A terceirização da programação para locais mais baratos é um dos poucos métodos restantes para reduzir os custos do programador. Os problemas com a terceirização incluem problemas de comunicação e problemas de especificação.

Métodos formais

Era uma vez, foi proposto que o software pudesse ser provado correto. (A idéia é que o teste não pode mostrar que não há erros, mas as provas seriam capazes.) Infelizmente, a criação de uma prova para um programa tem algumas desvantagens:

• É mais difícil e demorado do que escrever o programa.
• Ele tem que cobrir todo o programa, o que significa que você precisa de provas para qualquer biblioteca, sistema operacional, etc ...
• Não prova a ausência de bugs, pois esses bugs podem ser causados ​​por acidente.

Este conceito foi muito popular nos anos 70.

Linkage: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods