Março de Morte de Ed Yourdon toca um número dessas perguntas do tipo meta.
Em geral, a indústria de software não possui muitos dos seguintes itens, o que atrapalha grandes projetos.
-
Padronização e detalhamento do item de trabalho.
- Isso certamente melhorou, mas as construções de design ainda não estão lá para criar um grande sistema. De certa forma, o software nem chega a um acordo sobre o que é necessário para um determinado projeto, muito menos a capacidade de dividir as coisas em componentes.
- Aeroespacial, construção de edifícios, automóveis, etc. todos têm arquiteturas muito orientadas a componentes com interfaces razoavelmente justas para permitir um desenvolvimento totalmente paralelo. O software ainda permite que haja muita perda nas áreas correspondentes.
-
Uma grande quantidade de projetos semelhantes e bem-sucedidos. O A380 não foi o primeiro grande avião que Airbus construiu. Há muitos aplicativos de software grandes por aí, mas muitos deles sofreram dramaticamente em algum aspecto ou outro e não chegaram perto de serem chamados de "bem-sucedidos".
-
Um grande grupo de designers e construtores que trabalharam em vários projetos semelhantes e bem-sucedidos. Relacionado com a questão do projeto de sucesso, não ter o talento humano que esteve lá, o que torna as coisas muito difíceis do ponto de vista da repetibilidade.
-
"Nunca" construindo a mesma coisa duas vezes. De muitas maneiras, um avião é como qualquer outro avião. Tem asas, motores, assentos, etc. Os grandes projetos de software raramente se repetem. Cada kernel do SO é significativamente diferente. Veja a disparidade nos sistemas de arquivos. E, nesse caso, quantos SOs verdadeiramente únicos existem? Os grandes tornam-se clones de um item básico em algum momento. AIX , Solaris , HP-UX , ... o arauto de volta para AT&T System V . O Windows teve uma quantidade incrível de avanço em cada iteração. As variantes do Linux geralmente retornam ao mesmo núcleo que o Linus iniciou. Eu levanto, porque as variantes tendem a se propagar mais rápido do que os OSs verdadeiramente exclusivos e proprietários.
-
Estimativa de projeto muito ruim. Como o fator de repetibilidade é tão baixo, é difícil projetar o tamanho que ele vai ter e quanto tempo levará para construir. Dado que os gerentes de projeto e a Gerência não podem colocar as mãos no código e realmente ver o que está sendo feito, expectativas irreais em relação aos cronogramas são geradas.
-
O QA / QC não é enfatizado tanto quanto poderia ou deveria ser para projetos maiores. Isso remete a interfaces mais flexíveis entre os componentes e a não ter especificações rígidas de como os componentes devem funcionar. Essa frouxidão permite conseqüências não intencionais e erros se infiltram.
-
Qualificações consistentemente mensuráveis. Geralmente, as pessoas falam do número de anos em que trabalharam na linguagem X ou na programação. O tempo em está sendo usado como um substituto para o calibre ou a qualidade da habilidade. Como já foi mencionado muitas vezes, entrevistar e encontrar bons talentos de programação é difícil. Parte do problema é que a definição de "bom" permanece muito subjetiva.
Não pretendo ser negativo, e acho que a indústria de software fez avanços significativos de onde estivemos. Fóruns como este e outros realmente ajudaram a promover conversas e discussões sobre princípios de design. Existem organizações que trabalham para padronizar o conhecimento de "linha de base" para engenheiros de software. Certamente há espaço para melhorias, mas acho que a indústria percorreu um longo caminho em um período razoavelmente curto de tempo.